Hi Mark, On Tuesday 30 August 2011 17:46:42 Mark Brown wrote: > 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. The exact same idea crossed my mind after hitting the "Send" button :-) Would such a device be included in the DT ? My understanding is that the DT should only describe the hardware. -- Regards, Laurent Pinchart -- 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
