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?) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
