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

[Michael Hunold]

Hi,

On 22.09.2004 20:32, Adrian Cox wrote:
> > 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?

> I've been rereading the code, and it could be even simpler. How about
> this:
>
> 1) The card driver defines an i2c_adapter structure, but never calls
> i2c_add_adapter(). The only extra thing it needs to do is to initialise
> the semaphores in the structure.
> 2) The frontend calls i2c_transfer() directly.
> 3) The i2c core never gets involved, and there is never any i2c_client
> structure.
>
> This gives us the required reuse of the I2C algo-bit code, without any
> of the list walking or device probing being required.

This is the way the linux-dvb guys are currently favouring.

In some cases there should be an adapter that has been registered with 
i2c_add_adapter() because there can always be other drivers (audio/video 
multiplexes and the like) that you cannot get your hands on because they 
are provided by the manufacturer of some embedded platform.

For some cards (mostly bt8x8 based, ie. the core parts are driven by the 
"bttv" driver) and hybrid cards (ie. dvb cards that have a separate 
analog video input) the common i2c bus cannot go away, but it should be 
protected by proper .class entries in both the clients and adapters.

We think about splitting the frontend drivers into library parts, ie. 
library functions for demodulators (the current frontend drivers) and 
h/w dependent plls (or tuners).

Because of the fact the pci device knows which devices are present on 
the bus, it can register and configure the demod, pll and other specific 
dvb devices with direct i2c_transfer()s directly. If there are multiple 
combinations possible, it can use the library to probe as well.

The question we are currently facing is: are the frontend or demod i2c 
drivers real and independent i2c clients like thermal sensors or are 
they part of a h/w dependent design that should better be configured on 
a library basis?

If they are independend, then we need i2c bus types and type-safe 
client<=>adapter communication to exchange configuration and control 
informations, because the ioctl interface currently works from the 
adapter to the client and is not type safe.
Another question is, if this is probably too bloated. Think of simple 
matrix switch chipsets: the only "interface" they have is "set input a 
to output b".

> - Adrian Cox
> Humboldt Solutions Ltd.

CU
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/