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:

quoted

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).

quoted

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