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

[Michael Hunold <hunold@linuxtv.org>]

Hi,

On 22.09.2004 13:54, Adrian Cox wrote:
> Not in the current Linux DVB code. A frontend driver registers itself
> onto a list, and whenever a DVB card registers its I2C adapter the
> available frontends are probed. My solution would throw away all the
> list handling in dvb_i2c.c entirely.

Kernels including 2.6.9-rc2-mm1 have the proprietary dvb_i2c 
implementation inside, ie. no kernel i2c at all. I have recently sent a 
patch to Andrew that converts all dvb drivers and frontends to fully use 
kernel i2c. The current discussion is completely about the 
not-yet-officially-released dvb subsystem using kernel-i2c.

>>All in all I don't see how we can solve the problem without either a "do not
>>probe" flag in the adapter structure or a class bitfield in both the adapter
>>and the client structures. I would be fine with either option unless someone
>>explains how one is better than the other in any particular case.

> 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.

We're having a similar discussion on the linux-dvb mailing list and I 
have made a similar suggestion. There shouldn't be such a thing as a 
generic i2c bus at all - at least not for specific PCI or AGP cards 
having an i2c bus, because you really now what's there.

The adapters should be able to create a specific i2c bus. This bus then 
should have a well-defined client<->adapter interface. The adapter 
provides an interface clients can use for example to query h/w dependent 
informations, like "Is it possible to have chipset XY on your bus?". For 
DVB this question can be answered using pci subvendor/subdevice 
informations. This avoids the need to add a command() function to struct 
i2c_adapter.

If the adapter wants a client to join the bus and the client is really 
found, then the client must provide a well-defined set of functions as 
well. The adapter can then control the device in a type-safe manner and 
doesn't have to control it using the current ioctl interface.

> - Adrian Cox
> Humboldt Solutions Ltd.

We need to keep in mind, that the adapter interface must be a per-client 
interface. On PCI devices it's simple: you have a i2c bus bound to a dvb 
card and know which chipsets can be there. The bus is dvb specific.

On embedded platforms, however, you usually have one one i2c bus, where 
everything is present: dvb frontends, audio/video multiplexers, 
digital/analog audio converters, stuff like that.

So if you create *the* i2c bus and invite i2c client to participate at 
the party, you need to provide different interfaces to the different 
chipsets.

CU
Michael.