lkml.org 
[lkml]   [2004]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][2.6] Add command function to struct i2c_adapter
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:4.188 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site