Re: [ANN] Meeting minutes of the Cambourne meeting

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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