Re: [PATCH 05/14] media: add a V4L2 OF parser

[Guennadi Liakhovetski <g.liakhovetski@gmx.de>]

Hi Sylwester

On Fri, 5 Oct 2012, Sylwester Nawrocki wrote:

> On 10/05/2012 12:58 PM, Guennadi Liakhovetski wrote:
> >> One area that I do not yet completely understand is the i2c bus notifications
> >> (or asynchronous loading of i2c modules).
> >>
> >> I would have expected that using OF the i2c devices are still initialized
> >> before the host/bridge driver is initialized. But I gather that's not the
> >> case?
> > 
> > No, it's not. I'm not sure, whether it depends on the order of devices in
> > the .dts, but, I think, it's better to not have to mandate a certain order
> > and I also seem to have seen devices being registered in different order
> > with the same DT, but I'm not 100% sure about that.
> 
> The device instantiation (and initialization) order is not something that
> is supposed to be ensured by a specific device tree source layout, IIUC.
> The initialization sequence is probably something that is specific to a
> particular operating system. I checked the device tree compiler but couldn't
> find if it is free to reorder anything when converting from the human 
> readable device tree to its binary representation.
> 
> The deferred probing was introduced in Linux to resolve resource 
> inter-dependencies in case of FDT based booting AFAIK.
> 
> >> If this deferred probing is a general problem, then I think we need a general
> >> solution as well that's part of the v4l2 core.
> > 
> > That can be done, perhaps. But we can do it as a next step. As soon as
> > we're happy with the OF implementation as such, we can commit that,
> > possibly leaving soc-camera patches out for now, then we can think where
> > to put async I2C handling.
> 
> I would really like to see more than one user until we add any core code.
> No that it couldn't be changed afterwards, but it would be nice to ensure 
> the concepts are right and proven in real life.

Unfortunately I don't have any more systems on which I could easily enough 
try this. I've got a beagleboard with a camera, but I don't think I'm a 
particularly good candidate for implementing DT support for OMAP3 camera 
drivers;-) Apart from that I've only got soc-camera based systems, of 
which none are _really_ DT-ready... At best I could try an i.MX31 based 
board, but that doesn't have a very well developed .dts and that would be 
soc-camera too anyway.

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