Re: soc_camera Client Driver with Multiple I2C Addresses

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 28 Dec 2010 08:55:41 +0100 (CET), Guennadi Liakhovetski wrote:
> Hi Charles
> 
> (linux-i2c added to cc)
> 
> On Mon, 27 Dec 2010, Charles D. Krebs wrote:
> 
> > Guennadi,
> > 
> > I'm developing a driver for a video receiver chip that has register 
> > banks on multiple I2C addresses on the same bus.  The data output is 
> > parallel and I will be connecting it to the sh host interface.  
> > Overall, the device appears to be suitable as a client driver to 
> > soc_camera.
> > 
> > I'm following the model for the MT9T112 driver, and this works just fine 
> > for communicating to any one of the device's I2C addresses.
> > 
> > How would you recommend registering more than one I2C address to an 
> > soc_camera client driver?
> 
> Honestly - don't know. The soc-camera model for now is pretty simple and 
> in some senses restrictive. But in principle, it should be possible to 
> code your case within its scope too. One of the possibilities would be to 
> register your platform data with one "main" i2c unit / address, and then 
> let the sensor register the rest in its probe. Is your chip configuration 
> fixed? Always the same number of i2c units with the same addresses? Or can 
> it vary? Maybe something like a multi-function device (drivers/mfd) would 
> suit your purpose well?
> 
> In fact, I think, it shouldn't be too complicated. As suggested above, 
> provide (but don't register, just follow other soc-camera platforms) one 
> main i2c device in the platform data, register the rest in your main 
> probe(), which will call your further probe()s. The easiest would be to 
> keep just one soc-camera instance and one v4l2-subdeice, but if you want, 
> you can explore the possibility of creating several v4l2-subdevices.

If you simply need to handle a device which several I2C addresses, you
can consider one the main address, and register the secondary addresses
in your probe() function using i2c_new_dummy(). See
drivers/misc/eeprom/at24.c for an example of how this is done.

I'm not sure I understand the problem at hand exactly though, so my
advice might be inappropriate.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux