Complex I2C device

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?

Hi Rodolfo,

Quoted 21 lines · Rodolfo Giometti

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.

Quoted 7 lines

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 [email protected] list. In my case this other chip is a CMOS camera.

Quoted 33 lines · Guennadi Liakhovetski

Hi Rodolfo,

Quoted 21 lines · Rodolfo Giometti

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.

Quoted 7 lines

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?

Quoted 8 lines

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 [email protected] 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?

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

Quoted 14 lines

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

Quoted 5 lines

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...

Quoted 3 lines · Jean Delvare

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.

Quoted 14 lines

Quoted 14 lines

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

Quoted 5 lines

Quoted 5 lines

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. :)