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. -- Regards, Sylwester -- 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
