On Tue, Aug 30, 2011 at 05:42:55PM +0200, Laurent Pinchart wrote: > A dependency system is tempting but will be very complex to implement > properly, especially when faced with cyclic dependencies. For instance the > OMAP3 ISP driver requires the camera sensor device to be present to proceed, > and the camera sensor requires a clock provided by the OMAP3 ISP. To solve > this we need to probe the OMAP3 ISP first, have it register its clock devices, > and then wait until all sensors become available. With composite devices like that where the borad has sufficient interesting stuff on it representing the board itself as a device (this is what ASoC does). > A probe deferral system is probably simpler, but it will have its share of > problems as well. In the above example, if the sensor is probed first, the > driver can return -EAGAIN in the probe() method as the clock isn't available > yet (I'm not sure how to differentiate between "not available yet" and "not > present in the system" though). However, if the OMAP3 ISP is probed first, > returning -EAGAIN in its probe() method won't really help, as we need to > register the clock before waiting for the sensor. Having a device for the camera subsystem as a whole breaks this loop as the probe of that device triggers the overall system probe. -- 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
