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 > [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
--
GNU/Linux Solutions e-mail: [EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems [EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
signature.asc
Description: Digital signature
_______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
