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 > > [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:
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 [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
