Complex I2C device
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
Signature · 9 lines
GNU/Linux Solutions e-mail: giometti-AVVDYK/kqiJWk0Htik3J/[email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127 _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
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 underdrivers/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.
Thanks
Guennadi
---
Guennadi Liakhovetski
_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
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/gpioand 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?
Thanks for your help,
Rodolfo
Signature · 4 lines
GNU/Linux Solutions e-mail: giometti-AVVDYK/kqiJWk0Htik3J/[email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127
_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
Hi Rodolfo,
Quoted 43 lines · Rodolfo Giometti
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/gpioand 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 3 lines
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.
Quoted 24 lines
+---------+ --+---+ 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:
Quoted 7 lines
struct i2c_client *i2c_find_client(int busnum, unsigned short addr);which can return the
i2c_clientstruct 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.
Signature · 6 lines
Jean Delvare _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
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. :)
Rodolfo
Signature · 4 lines
GNU/Linux Solutions e-mail: giometti-AVVDYK/kqiJWk0Htik3J/[email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127
_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
Quoted 28 lines · Rodolfo Giometti
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...
Quoted 3 lines
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.
Quoted 1 line
It looks *really* good. :)
Credit go to David Brownell.
Signature · 6 lines
Jean Delvare _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c