Re: [ANN] Meeting minutes of the Cambourne meeting

[Grant Likely <grant.likely@secretlab.ca>]

On Tue, Aug 30, 2011 at 02:41:48PM +0100, Mark Brown wrote:
> On Tue, Aug 30, 2011 at 12:20:09AM +0200, Guennadi Liakhovetski wrote:
> > On Mon, 29 Aug 2011, Laurent Pinchart wrote:
> 
> > > My idea was to let the kernel register all devices based on the DT or board 
> > > code. When the V4L2 host/bridge driver gets registered, it will then call a 
> > > V4L2 core function with a list of subdevs it needs. The V4L2 core would store 
> > > that information and react to bus notifier events to notify the V4L2 
> > > host/bridge driver when all subdevs are present. At that point the host/bridge 

Sounds a lot like what ASoC is currently doing.

> > > driver will get hold of all the subdevs and call (probably through the V4L2 
> > > core) their .registered operation. That's where the subdevs will get access to 
> > > their clock using clk_get().
> 
> > Correct me, if I'm wrong, but this seems to be the case of sensor (and 
> > other i2c-client) drivers having to succeed their probe() methods without 
> > being able to actually access the hardware?

It indeed sounds like that, which also concerns me.  ASoC and other
subsystems have exactly the same problem where the 'device' is
actually an aggregate of multiple devices attached to different
busses.  My personal opinion is that the best way to handle this is to
support deferred probing so that a driver can fail with -EAGAIN if all
the resources that it requires are not available immediately, and have
the driver core retry the probe after other devices have successfully
probed.

I've got prototype code for this, but it needs some more work before
being mainlined.

> The events should only be generated after the probe() has succeeded so
> if the driver talks to the hardware then it can fail probe() if need be.

I'm a bit confused here.  Which events are you referring to, and which
.probe call? (the i2c/spi/whatever probe, or the aggregate v4l2 probe?)