[i2c] Identifying I2C busses

[Jean Delvare]

Hi David,

On Mon, 5 Mar 2007 19:22:36 -0800, David Brownell wrote:
[Lots of things]

I'm skipping the context so that we can focus again on the important
points. Quite a challenge when replying to a 28 kB message... So I'm
starting a new thread and I'll attempt to summarize the situation.

* You seem to consider as important that Linux numbers the I2C busses
the exact same way as your board schematics do. I didn't realize that
before. I thought that bus numbering was just a way for you to
connect chip declarations to their respective busses, but now I seem to
understand that the possibility to "request" an I2C bus number from
i2c-core is a feature you are interested in per se. Right?

* I have to admit that platform data associated with the I2C busses is
not the natural place to store I2C chip definitions. I guess I was
using the platform data as a kind of transport means, but it would
probably be more of a hack than anything else. So my solution doesn't
actually fly - or at least it wasn't as nice as I thought it was.

* You mostly convinced me that your approach was correct. One thing
which worries me though: is there any other subsystem in the whole
Linux tree which works that way (mixing requested identification
numbers with dynamically assigned ones)? What makes I2C different?

* I'm very curious about how the stacked-board designs you mentioned
don't have problems with I2C address collisions if they work the way
you described.

* You seem to agree that bus_num could be moved out of struct
i2c_board_info. Good. The sole fact that its value is ignored in a
number of cases is IMHO a good indication that it indeed doesn't
belong there. Which means that we then need a way to associate such a
structure with a bus number, for the early I2C device declaration case.

On a related topic, I am not fond of your "list of arrays of variable
size" approach to store the I2C device declarations. This seems to be
more complex than needed. Can't we simply go with a list of individual
records? Here's what I have in mind (beware, I changed the struct
names):

struct i2c_device_info {
	char		driver[KOBJ_NAME_LEN];
	char		type[I2C_NAME_SIZE];
	unsigned short	dev_addr;
	void		*platform_data;
	int		irq;
};

struct i2c_board_info {
	struct list_head	list;
	short			bus_num;
	struct			i2c_device_info;
};

And __i2c_board_list would be a list of struct i2c_board_info. This
should make your code somewhat more simple, at the price of additional
calls to i2c_register_board_info() and maybe some more memory
fragmentation, but I don't think this is a major problem. What do you
think?

A different approach is one list per bus number, that would scale
better (no common pool), but that makes things a bit more complex
again, and as you underlined, we don't expect thousands of devices to
be declared anyway so scalability probably doesn't matter. I guess
real-world scenarii have a max of 2 I2C busses?

* I am not happy with the idea of having one function named
i2c_add_adapter, and one named i2c_register_adapter (i.e. almost the
same name) doing something similar but different, without this
difference being visible in their name. We need to come up with
something better than that. Either we can have a single function, or we
need to rename i2c_register_adapter to something which expresses its
difference to i2c_add_adapter. i2c_add_numbered_adapter or something.

* With regards to i2c-mainboard, wouldn't it be more simple to just
make it mandatory to build i2c-core into the kernel when you need the
early device declaration process? I seem to remember that this is a
common practice in the embedded world anyway, because you need I2C
early in the boot process.

* 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?

Thanks,
-- 
Jean Delvare