On Mon, 27 Apr 2009, Eric Miao wrote: > It looks to me the change to the platform code is to move the I2C board > info registration into 'struct soc_camera_link'. Are there any specific > reason to do so? I'm assuming the original code works equally well, > and lists all the i2c devices in a central place is straight forward. Yes, there are reasons. The first one is, that many i2c camera sensor chips switch on their I2C interface only when the camera interface master clock is running. Therefore you cannot even probe the chip before the host video part has been initialised. So if you load the sensor driver before the host camera driver you cannot probe. The current mainline framework makes the "first-stage" sensor probe a NOP, in it the sensor driver just registers itself with the soc-camera framework and returns success. And only when the soc-camera finds a match of a sensor and a host driver it requests the host to activate the interface (switch on the master clock) and then the second stage sensor probing is called, which now can actually read chip version registers etc. The second reason is that this is also how v4l2-subdev framework works - there your camera host driver (in our case soc-camera core) uses its internal knowledge about present I2C devices (in our case it uses platform devices with referenced there i2c board info) to register new I2C devices dynamically and load their drivers, at which point we have already switched the master clock on so the sensor driver can just probe the chip normally. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
