On Wed, 10 Apr 2013, Barry Song wrote: > Hi Guennadia, There's a typo above. > Thanks! > > 2013/4/10 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: > > Hi Barry > > > > On Wed, 10 Apr 2013, Barry Song wrote: > > > >> Hi Guennadia, > >> > >> 2012/9/27 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>: > >> > Currently soc-camera doesn't work with independently registered I2C client > >> > devices, it has to register them itself. This patch adds support for such > >> > configurations, in which case client drivers have to request deferred > >> > probing until their host becomes available and enables the data interface. > >> > > >> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@xxxxxx> > >> > --- > >> > >> it seems deferred probing for i2c camera sensors is a more workaround > >> than a solution. > >> currently, soc-camera-pdrv is the manager of the whole initilization > >> flow. it all requires the host/client registerred and initilized > >> synchronously. so that results in strange things like that we fill a > >> i2c_board_info structure in arch/arm/mach-xxx but we never call > >> anything like i2c_new_device() to add the i2c client in mach. because > >> we need to do that in the soc-camera-pdrv driver to make all things > >> happen orderly. > >> > >> but now after we move to DT, all i2c device will be registerred > >> automatically by of_i2c_register_devices() in i2c_host 's probe, that > >> makes the problem much worse and very urgent to get fixed. > >> > >> returning DEFERRED_PROBE error until getting the private data filled > >> by the manager, > > > > This hasn't been the case since several versions of these patches. We no > > longer use private data to decide whether subdevices can probe > > successfully or have to defer probing. > > sorry for missing. i will refer to your newer versions. > > > > >> indirectly, makes the things seem to be asynchronous, > >> but essentially it is still synchronous because the overall timing > >> line is still controller by soc-camera-pdrv. > > > > It isn't. If your subdevice driver doesn't have any dependencies, like > > e.g. sh_mobile_csi2.c, it will probe asynchronously whenever it's loaded. > > It is the task of a bridge driver, in our case of the soc-camera core, to > > register notifiers and a list of expected subdevices with the v4l2-async > > subsystem. As subdevices complete their probing they signal that to the > > v4l2-async too, which then calls bridge's notifiers, which then can build > > the pipeline. > > it seems we didn't describle my idea clearly in the last mail. i > actually mean we don't need that if we put the pipeline building to > the last stage after all things have been placed there. > > > > >> what about another possible way: > >> we let all host and i2c client driver probed in any order, > > > > This cannot work, because some I2C devices, e.g. sensors, need a clock > > signal from the camera interface to probe. Before the bridge driver has > > completed its probing and registered a suitable clock source with the > > v4l2-clk framework, sensors cannot be probed. And no, we don't want to > > fake successful probing without actually being able to talk to the > > hardware. > > i'd say same dependency also exists on ASoC. a "fake" successful > probing doesn't mean it should really begin to work if there is no > external trigger source. ASoC has successfully done that by a machine > driver to connect all DAI. > a way is we put all things ready in their places, finally we connect > them together and launch the whole hardware flow. > > anyway, if you have maken the things work by some simple hacking and > that means minimial changes to current soc-camera, i think we can > follow. If you want to volunteer to step up as a new soc-camera maintainer to replace my simple hacking with your comprehencive and advanced designs - feel free, I'll ack straight away. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
