[i2c] i2c device attached to a SoC bus

[Jorge Luis Zapata Muga]

On 6/12/07, Jean Delvare <khali at linux-fr.org> wrote:
> Hi Jorge Luis,

Hi Jean, thanks for answering

>
> On Mon, 11 Jun 2007 12:22:51 +0200, Jorge Luis Zapata Muga wrote:
> > Hi all, ive already posted a message to the v4l ml without luck. I'll
> > explain first what im trying to do:
> > I have a tvp5150 device attached to a SoC i2c bus and would like to
> > use a v4l interface for it, so basically my driver would be an i2c
> > driver wrapper. The tvp5150 is already on the kernel with an
> > i2c_client interface, and i already coded the SoC bus driver under
> > drivers/i2c/busses.
> >
> > Now, in order to send commands to the i2c client, i need the
> > i2c_client struct, which is stored on the client_register callback of
> > the adapter. This approach fits well when the i2c bus is part of the
> > device driver i want to code (like in other v4l drivers), but as my
> > i2c bus code is generic (i.e there can be any type of i2c client
> > attached, not a static list) there's no way to retrieve what clients
> > are attached to an adapter from kernel space, but it is possible from
> > user space using the i2c-dev interface.
>
> This statement is not correct. You can do more in kernel space than
> through i2c-dev, not less.

Yes that's true, you can do more on kernel space, but without a clean
interface you end up with a very awful code, specially when you have
to deal between two drivers.

> And i2c-dev certainly doesn't give you
> access to the attached i2c_clients; it only lets you create new
> i2c_clients.

looking on Documents/i2c/dev-interface seems that from user space i
can access an adapter and read/write to/from a client device attached
to it. But there's no point (at least on my machine) to define a video
API from user space, where there's the v4l one.

>
> > There is a possible solution i could use: code my v4l driver as an i2c
> > adapter,  and reuse my generic i2c bus algo. I would need to export
> > some symbols, but still it don't like this approach because some arch
> > specific code (like setting up the gpios, clocks, etc) are also
> > duplicated and may cause errors.
>
> This sounds like a bad idea, agreed.
>
> > Is some other way? someone with experience on a similar problem?
>
> Admittedly, this isn't a case which is properly supported at the
> moment. Multimedia chips are supposed to be on multimedia adapters, not
> random I2C adapters.
>
> Getting a reference to the i2c_client is only one of your problems.
> Once you have it, you'll need to send commands to it. The commands are
> supposed to come through /dev/videoN, right? So you'll need some code
> to register a video device and route the requests to the i2c_client.
> The question is, where do you plan to put this code? In your i2c bus
> driver? Or in another driver?

That's the point, the i2c bus driver is a generic driver for this
platform, but on a specific machine there might be different i2c
devices attached to it. The logic idea would be to keep the generic
i2c bus driver under i2c/busses/ and for a specific machine's i2c
client adapter define it under the driver's class directory
(media/video, sound, etc). Then would have the device class interface,
and only redirect the commands to the i2c client. In my machine's case
i would code a v4l driver under media/video, and route the v4l command
to the i2c driver, the problem, as you have already noted, is where to
place the i2c adapter code, because the i2c_client struct is a must.
If i place it under my v4l device, then the code of the bus driver is
duplicated.

>
> I would also like to see your bus driver. How is the i2c adapter
> instantiated? Based on a platform device declaration?

Yes, it is a platform device declaration, you can check it under:
https://svn.neurostechnology.com/hackers/turran/kernel/drivers/i2c/busses/i2c-dm320.c


Thanks in advance.

>
> --
> Jean Delvare
>