Re: [PATCH][2.6] Add command function to struct i2c_adapter

["Jean Delvare" <khali@linux-fr.org>]

On Wed, 22 Sep 2004 12:54:08 +0100, Adrian Cox wrote
> On Wed, 2004-09-22 at 13:08, Jean Delvare wrote:
> > Well, I don't quite follow you here. On the one hand you agree that
> > sensors and video/embedded stuff should be handled differently, but
> > then you don't want us to tag them according to their function in order
> > to actually behave differently.
> 
> I don't want them tagged because I don't want them to ever appear on 
> a system-wide list. They're an internal detail of a particular card, 
> and don't even need to be in sysfs. The only reason to have any 
> shared I2C code at all for these cards is to avoid duplicating the
> implementation of bit-banging.
> (...)
> What I want is a way for a card driver to create a private I2C 
> adapter, and private instances of I2C clients, for purposes of code 
> reuse. The card driver would be responsible for attaching those 
> clients to the bus and cleaning up the objects on removal. The bus 
> wouldn't be visible in sysfs, or accessible from user-mode.

Aha, this is an interesting point (which was missing from your previous
explanation). The base of your proposal would be to have several small i2c
"trees" (where a tree is a list of adapters and a list of clients) instead of
a larger, unique one. This would indeed solve a number of problems, and I
admit that it is somehow equivalent to Michael's classes in that it
efficiently prevents the hardware monitoring clients from probing the video
stuff. The rest is just details internal to each "tree". As I understand it,
each video device would be a tree on itself, while the whole hardware
monitoring stuff would constitute one (bigger) tree. Correct?

> Some USB webcams have internal I2C busses to connect the sensor to 
> the USB chip. The drivers for these ignore the I2C core completely, and
> invent their own system for reading and writing the sensor registers.
> Maybe that's actually the best way of dealing with this.

With your proposal, these drivers could use the common code again while still
being completely separated from the other i2c busses, right?

Thanks.

-- 
Jean Delvare
http://khali.linux-fr.org/