Complex I2C device

Complex I2C device

[Rodolfo Giometti]

Hello,

my custom board has a «complex» device... let me explain better: it's
formed by a custom I2C device and an I/O extender PCA9539.

Ascii art:


                +---------+
          --+---+         |
            |   | PCA9539 |
            |   +---------+
Bus I2C ->> |      | | |
            |      | | | <<--- GPIOs
            |      | | |
            |   +---------+
            +---+         |
                |   CHIP  |
                +---------+  

Some input GPIOs of CHIP are managed by the PCA9539. So fisically I
have two devices but logically they are merged together into one.

I can send commands to CHIP by both I2C bus and the GPIOs, which in
turn are controlled by the PCA9539.

Can you please suggest me the best way to manage this problem? My
solution was to provide PCA9539's driver of some exported symbols and
using them into the CHIP's driver. Is that right? Or, can I "call" (in
any way) PCA9539 driver's methods from CHIP's driver?

Thanks,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti-AVVDYK/kqiJWk0Htik3J/w@public.gmane.org
Linux Device Driver                             giometti-kaDoWcXyVrEAvxtiuMwx3w@public.gmane.org
Embedded Systems                     		giometti-k2GhghHVRtY@public.gmane.org
UNIX programming                     phone:     +39 349 2432127

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Complex I2C device

[Guennadi Liakhovetski]

Hi Rodolfo,

On Wed, 30 Jan 2008, Rodolfo Giometti wrote:

> my custom board has a «complex» device... let me explain better: it's
> formed by a custom I2C device and an I/O extender PCA9539.
> 
> Ascii art:
> 
> 
>                 +---------+
>           --+---+         |
>             |   | PCA9539 |
>             |   +---------+
> Bus I2C ->> |      | | |
>             |      | | | <<--- GPIOs
>             |      | | |
>             |   +---------+
>             +---+         |
>                 |   CHIP  |
>                 +---------+  
> 
> Some input GPIOs of CHIP are managed by the PCA9539. So fisically I
> have two devices but logically they are merged together into one.
> 
> I can send commands to CHIP by both I2C bus and the GPIOs, which in
> turn are controlled by the PCA9539.
> 
> Can you please suggest me the best way to manage this problem? My
> solution was to provide PCA9539's driver of some exported symbols and
> using them into the CHIP's driver. Is that right? Or, can I "call" (in
> any way) PCA9539 driver's methods from CHIP's driver?

First, you want to use gpiolib, which in -mm tree now lives under 
drivers/gpio and includes a driver for pca9539. With it the pca9539 driver 
registers a gpio controller with the system, and then your driver for the 
other part can just request respective GPIOs as if they were normal CPU 
GPIOs or whatever else. And toggle them using the standard API. I will 
(hopefully tomorrow) post an example of exactly this to the 
video4linux-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org list. In my case this other chip is a CMOS 
camera.

Thanks
Guennadi
---
Guennadi Liakhovetski

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Complex I2C device

[Rodolfo Giometti]

[-- Attachment #1.1: Type: text/plain, Size: 3387 bytes --]

On Wed, Jan 30, 2008 at 09:32:38PM +0100, Guennadi Liakhovetski wrote:
> Hi Rodolfo,
> 
> On Wed, 30 Jan 2008, Rodolfo Giometti wrote:
> 
> > my custom board has a «complex» device... let me explain better: it's
> > formed by a custom I2C device and an I/O extender PCA9539.
> > 
> > Ascii art:
> > 
> > 
> >                 +---------+
> >           --+---+         |
> >             |   | PCA9539 |
> >             |   +---------+
> > Bus I2C ->> |      | | |
> >             |      | | | <<--- GPIOs
> >             |      | | |
> >             |   +---------+
> >             +---+         |
> >                 |   CHIP  |
> >                 +---------+  
> > 
> > Some input GPIOs of CHIP are managed by the PCA9539. So fisically I
> > have two devices but logically they are merged together into one.
> > 
> > I can send commands to CHIP by both I2C bus and the GPIOs, which in
> > turn are controlled by the PCA9539.
> > 
> > Can you please suggest me the best way to manage this problem? My
> > solution was to provide PCA9539's driver of some exported symbols and
> > using them into the CHIP's driver. Is that right? Or, can I "call" (in
> > any way) PCA9539 driver's methods from CHIP's driver?
> 
> First, you want to use gpiolib, which in -mm tree now lives under 
> drivers/gpio and includes a driver for pca9539. With it the pca9539 driver 
> registers a gpio controller with the system, and then your driver for the 
> other part can just request respective GPIOs as if they were normal CPU 
> GPIOs or whatever else. And toggle them using the standard API. I will 
> (hopefully tomorrow) post an example of exactly this to the 
> video4linux-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org list. In my case this other chip is a CMOS 
> camera.

Great, this would be a good solution for this scenario... but I'm
looking something more "general". A related problem of mine is on
another custom board which has the following:


                 +---------+
           --+---+ Battery |
             |   | Manager |
             |   +---------+
 Bus I2C ->> |
             |
             |
             |   +---------+
             +---+         |
                 |  CHIP   |
                 +---------+

A (complex) battery pack are managed by a "battery manager" and a
custom chip connected by the I2C bus (my hardware designer _loves_ I2C
bus :). Even these devices can be logically considered as only one
(big) battery...

Looking at I2C code, which uses the new style driver model, I see the
function i2c_register_board_info() where we can specify the bus number
and the devices list attached on that I2C bus, so I suppose we can add
a function as:

	struct i2c_client *i2c_find_client(int busnum, unsigned short addr);

which can return the i2c_client struct associated to the given bus
number and i2c address.

This should resolve any possible problem related to every I2C
"complex" device. Shouldn't it?

Thanks for your help,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti-AVVDYK/kqiJWk0Htik3J/w@public.gmane.org
Linux Device Driver                             giometti-kaDoWcXyVrEAvxtiuMwx3w@public.gmane.org
Embedded Systems                     		giometti-k2GhghHVRtY@public.gmane.org
UNIX programming                     phone:     +39 349 2432127

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Complex I2C device

[Jean Delvare]

Hi Rodolfo,

On Thu, 31 Jan 2008 10:16:19 +0100, Rodolfo Giometti wrote:
> On Wed, Jan 30, 2008 at 09:32:38PM +0100, Guennadi Liakhovetski wrote:
> > Hi Rodolfo,
> > 
> > On Wed, 30 Jan 2008, Rodolfo Giometti wrote:
> > 
> > > my custom board has a «complex» device... let me explain better: it's
> > > formed by a custom I2C device and an I/O extender PCA9539.
> > > 
> > > Ascii art:
> > > 
> > > 
> > >                 +---------+
> > >           --+---+         |
> > >             |   | PCA9539 |
> > >             |   +---------+
> > > Bus I2C ->> |      | | |
> > >             |      | | | <<--- GPIOs
> > >             |      | | |
> > >             |   +---------+
> > >             +---+         |
> > >                 |   CHIP  |
> > >                 +---------+  
> > > 
> > > Some input GPIOs of CHIP are managed by the PCA9539. So fisically I
> > > have two devices but logically they are merged together into one.
> > > 
> > > I can send commands to CHIP by both I2C bus and the GPIOs, which in
> > > turn are controlled by the PCA9539.
> > > 
> > > Can you please suggest me the best way to manage this problem? My
> > > solution was to provide PCA9539's driver of some exported symbols and
> > > using them into the CHIP's driver. Is that right? Or, can I "call" (in
> > > any way) PCA9539 driver's methods from CHIP's driver?
> > 
> > First, you want to use gpiolib, which in -mm tree now lives under 
> > drivers/gpio and includes a driver for pca9539. With it the pca9539 driver 
> > registers a gpio controller with the system, and then your driver for the 
> > other part can just request respective GPIOs as if they were normal CPU 
> > GPIOs or whatever else. And toggle them using the standard API. I will 
> > (hopefully tomorrow) post an example of exactly this to the 
> > video4linux-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org list. In my case this other chip is a CMOS 
> > camera.
> 
> Great, this would be a good solution for this scenario... but I'm
> looking something more "general". A related problem of mine is on
> another custom board which has the following:

Guennadi's solution (based on David Brownell's work) is actually pretty
generic as far as GPIOs are concerned. I like it.

> 
> 
>                  +---------+
>            --+---+ Battery |
>              |   | Manager |
>              |   +---------+
>  Bus I2C ->> |
>              |
>              |
>              |   +---------+
>              +---+         |
>                  |  CHIP   |
>                  +---------+
> 
> A (complex) battery pack are managed by a "battery manager" and a
> custom chip connected by the I2C bus (my hardware designer _loves_ I2C
> bus :). Even these devices can be logically considered as only one
> (big) battery...
> 
> Looking at I2C code, which uses the new style driver model, I see the
> function i2c_register_board_info() where we can specify the bus number
> and the devices list attached on that I2C bus, so I suppose we can add
> a function as:
> 
> 	struct i2c_client *i2c_find_client(int busnum, unsigned short addr);
> 
> which can return the i2c_client struct associated to the given bus
> number and i2c address.
> 
> This should resolve any possible problem related to every I2C
> "complex" device. Shouldn't it?

This would be doing things the wrong way around IMHO. Assuming that
there is no clean interface between both physical components of your
complex logical device, that would make a GPIO-like solution possible,
what you really have is a single device with 2 I2C addresses. We
support this already thanks to the i2c_new_dummy() function, so I see
no need for an additional interface.

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Complex I2C device

[Rodolfo Giometti]

[-- Attachment #1.1: Type: text/plain, Size: 1466 bytes --]

On Tue, Feb 19, 2008 at 02:21:33PM +0100, Jean Delvare wrote:
> 
> Guennadi's solution (based on David Brownell's work) is actually pretty
> generic as far as GPIOs are concerned. I like it.

If I well understand it I should use i2c_new_dummy() to simply create
an handler for the alternate address.

> > 
> > 
> >                  +---------+
> >            --+---+ Battery |
> >              |   | Manager |
> >              |   +---------+
> >  Bus I2C ->> |
> >              |
> >              |
> >              |   +---------+
> >              +---+         |
> >                  |  CHIP   |
> >                  +---------+
> > 
> > A (complex) battery pack are managed by a "battery manager" and a
> > custom chip connected by the I2C bus (my hardware designer _loves_ I2C
> > bus :). Even these devices can be logically considered as only one
> > (big) battery...
> > 

In this situation into the driver of the «main» device (the battery
manager) I can use i2c_new_dummy() to get an handler to manage the
other I2C chip. Is that right?

It looks *really* good. :)

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti-AVVDYK/kqiJWk0Htik3J/w@public.gmane.org
Linux Device Driver                             giometti-kaDoWcXyVrEAvxtiuMwx3w@public.gmane.org
Embedded Systems                     		giometti-k2GhghHVRtY@public.gmane.org
UNIX programming                     phone:     +39 349 2432127

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Complex I2C device

[Jean Delvare]

On Tue, 19 Feb 2008 15:10:49 +0100, Rodolfo Giometti wrote:
> On Tue, Feb 19, 2008 at 02:21:33PM +0100, Jean Delvare wrote:
> > 
> > Guennadi's solution (based on David Brownell's work) is actually pretty
> > generic as far as GPIOs are concerned. I like it.
> 
> If I well understand it I should use i2c_new_dummy() to simply create
> an handler for the alternate address.
> 
> > > 
> > > 
> > >                  +---------+
> > >            --+---+ Battery |
> > >              |   | Manager |
> > >              |   +---------+
> > >  Bus I2C ->> |
> > >              |
> > >              |
> > >              |   +---------+
> > >              +---+         |
> > >                  |  CHIP   |
> > >                  +---------+
> > > 
> > > A (complex) battery pack are managed by a "battery manager" and a
> > > custom chip connected by the I2C bus (my hardware designer _loves_ I2C
> > > bus :). Even these devices can be logically considered as only one
> > > (big) battery...
> > > 
> 
> In this situation into the driver of the «main» device (the battery
> manager) I can use i2c_new_dummy() to get an handler to manage the
> other I2C chip. Is that right?

Yep, that's exactly the idea.

> It looks *really* good. :)

Credit go to David Brownell.

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c