[ANN] Meeting minutes of the Cambourne meeting

[Grant Likely]

On Tue, Aug 30, 2011 at 8:03 AM, Guennadi Liakhovetski
<g.liakhovetski at gmx.de> 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.