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 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.
-
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:2.140 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site