On Sat, 21 Feb 2009 13:45:40 +0100, Hans Verkuil wrote: > On Saturday 21 February 2009 12:58:01 Mauro Carvalho Chehab wrote: > > On Sat, 21 Feb 2009 08:28:50 +0100 > > Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > > OK, once more: there are two types of legacy code: one is that drivers > > > have to be switched to use the new i2c API. That's what I've been > > > working on all these months since Plumbers 2008. When all drivers that > > > use i2c modules have been converted, then we can drop > > > v4l2-i2c-drv-legacy.h and Jean can drop the autoprobing code in the i2c > > > core. > > > > This will be great, provided that we can do the autoprobing for the audio > > modules as required by a few drivers like bttv. > > You cannot expect that a user can modprobe an i2c driver and it will > magically appear. That's going away. You can change the driver so that it > will load the module and let it probe for a series of i2c addresses. There > is also an option to let the i2c driver do additional checks (Jean knows > more about the details). Actually with the new I2C binding model, you have quite a few options depending of what you know and what you need. * If you know that a given chip is at a given address, you call i2c_new_device() from the adapter driver's code. * If you know a given chip is there but don't know the exact address, or if the chip may or may not be there, you call i2c_new_probed_device() from the adapter driver's code. * If you know a given chip is there but don't know the address, or if the chip may or may not be there, and the device in question can be detected (ID registers you can read), you implement the detect() method in the I2C chip driver, which will test a number of addresses to find out if a supported chip is there or not. In the adapter driver, you define an I2C bus class (e.g. I2C_CLASS_TV_ANALOG) to allow the I2C chip driver to probe that specific bus. * An alternative approach, if letting the I2C chip driver probe for the device is too dangerous, is to add custom detection code to the adapter driver. Imagine that different versions of the adapter have either I2C chip A or chip B at a given address, and the only way to differentiate is to write to a given register and read a value back from the chip. You can't do that on all I2C buses (writing to arbitrary registers is bad) but you can do it on your specific adapter. Depending on the result you then call i2c_new_device(A) or i2c_new_device(B). The 3rd method is very similar to the legacy i2c binding model. -- 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
