Hi Grant

On Tue, 30 Aug 2011, Grant Likely wrote:

On Tue, Aug 30, 2011 at 02:41:48PM +0100, Mark Brown wrote:

quoted

On Tue, Aug 30, 2011 at 12:20:09AM +0200, Guennadi Liakhovetski wrote:

quoted

On Mon, 29 Aug 2011, Laurent Pinchart wrote:

quoted

quoted

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.

quoted

quoted

quoted

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

quoted

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.

quoted

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/