On Tue, Aug 30, 2011 at 8:03 AM, Guennadi Liakhovetski <g.liakhovetski@xxxxxx> wrote: > 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. Yes, a dependency system would be lovely... but it gets really complex in a hurry, especially when faced with heterogeneous device registrations. A deferral system ends up being really simple to implement and probably work just as well. g. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
