[i2c] Identifying I2C busses

[David Brownell]

On Wednesday 07 March 2007 12:17 pm, Jean Delvare wrote:

> Yeah, now that I look at the spi core, I see the common parts with what
> you proposed for i2c. I cannot find an equivalent of
> __i2c_first_dynamic_bus_num though.

There's no "fence"; the dynamic numbers count down from "big".
Kind of a hack, but nobody else was particularly helping to
sort out the problems... the old "first solution" problem.


> > (Related:  how do DRAM cards avoid collisions on their I2C EEPROMS?
> > I'm guessing three pins in each slot get hooked up to the EEPROM
> > address select pins, and they're wired on the baseboard so each slot
> > has a unique number.  Similar approaches can work for other kinds
> > of board stack, when an EEPROM is used to identify each card and
> > maybe record factory-tested calibration data.)
> 
> You're right, 24C02 EEPROMs have 3 pins to select the address from 0x50
> to 0x57 and each DRAM slot uses a different combination. Something
> similar could work for your stack of cards, except that not all I2C
> devices have a selectable address. And you may want to have more than
> one chip of a kind on a given board. This is way more complex than DRAM
> modules which are all the same I2C-bus-wise.

Right, but remember again that it's not a case of expecting _arbitrary_
boards to be stackable.  They're designed as part of a family, often with
the connectors set up so the boards only fit together in a particular way.

(Another example:  cell phones.  Space constraints can mean you don't have
enough flat space on one board to fit everything.  So you stack another
board, and they're custom designed to work only with each other ... and to
fit some quirky size/shape constrints.  Maybe I2C is used between the cards,
maybe it isn't, but it's the same "stack cards" model, and at least the
system developers and upgraders need to work with partial stacks.)


> > I guess I still don't see a real advantage.  It hits the malloc heap more
> > often at board init time; a handful of loop instructions move from scanning
> > that list into setting it up.  If it bothers you deeply, I can change
> > that to provide a list of singletons.
> 
> Now that we decided to move bus_num out of struct i2c_device_info, will
> it make a big difference fragmentation-wise? I assumed not. I guess
> that you'll have one or two I2C devices to declare on each card for
> each bus, hardly more, right?

Right.

> The code that sets the list up is __init anyway, if I followed your
> explanations properly, so adding some more instructions there shouldn't
> be worrisome.
> 
> So, yes, I believe that a list of singletons if prefered. 

OK.


> > Your notion of using the device handle as the (relatively) stable
> > bus ID would let there be only one function...
> 
> It's up to you, I'm not insisting. I _am_ fine with two functions, as
> long as the name of the new one is meaningful.

That is, more distinct.  I'll change the name for sure, even if I
don't switch to using device as a handle (rather than number).


> > So despite the minor mess, I don't see an easy way around that being
> > a separate file.  Moving it out of i2c-core.c was a cleanup.  :)
> 
> This forces you to export some new symbols, and exports aren't free. I
> wanted to avoid that. But if you see no other solution, so be it.

It's not a case of "no other solution", so much as "best alternative".


> > > * Your implementation doesn't seem to support I2C bus number
> > > reservation if there is no chip on that bus. Isn't it going to be
> > > confusing? Don't we want a function in i2c-core that lets the platform
> > > code explicitly bump __i2c_first_dynamic_bus_num, rather that deducing
> > > it from the i2c devices definitions?
> > 
> > Good point, but a simpler fix is just to let i2c_register_boardinfo()
> > do that bumping even when there are no devices to register.  That falls
> > out easily from making the bus number be a parameter to that function
> > rather than a member of the i2c_board_info structure.
> 
> I didn't expect people to call i2c_register_boardinfo() if there is no
> device to register. But you can argue that they now have to and it's
> their bug if they don't. So again, up to you.

If they want to reserve a number they've got to do _something_ and that
might as well be what they do.  But again, I may decide I like your
notion of device struct as handle, at which point this issue vanishes too.

- Dave