[ANN] Meeting minutes of the Cambourne meeting

[Guennadi Liakhovetski]

Hi Grant

On Tue, 30 Aug 2011, Grant Likely wrote:

> 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

Yes, that's also what I think should be done. But I was thinking about a 
slightly different approach - a dependency-based probing. I.e., you should 
be able to register a device, depending on another one (parent?), and only 
after the latter one has successfully probed, the driver core should be 
allowed to probe the child. Of course, devices can depend on multiple 
other devices, so, a single parent might not be enough.

Thanks
Guennadi

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

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/