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-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
