| Message ID | 1348754853-28619-8-git-send-email-g.liakhovetski@gmx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Guennadia, 2012/9/27 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > 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@gmx.de> > --- 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, 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. what about another possible way: we let all host and i2c client driver probed in any order, but let the final soc-camera-pdrv is the connection of all things. the situation of soc_camera is very similar with ALSA SoC. it turns out ASoC has done that very well. -barry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Barry On Wed, 10 Apr 2013, Barry Song wrote: > Hi Guennadia, > > 2012/9/27 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > > 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@gmx.de> > > --- > > 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. > 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. > 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. Thanks Guennadi > but let the > final soc-camera-pdrv is the connection of all things. the situation > of soc_camera is very similar with ALSA SoC. it turns out ASoC has > done that very well. > > -barry > --- 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Guennadia, Thanks! 2013/4/10 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > Hi Barry > > On Wed, 10 Apr 2013, Barry Song wrote: > >> Hi Guennadia, >> >> 2012/9/27 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: >> > 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@gmx.de> >> > --- >> >> 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. > > Thanks > Guennadi > >> but let the >> final soc-camera-pdrv is the connection of all things. the situation >> of soc_camera is very similar with ALSA SoC. it turns out ASoC has >> done that very well. >> -barry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 10, 2013 at 09:53:20PM +0800, Barry Song wrote: > 2013/4/10 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > >> 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. In the ASoC case the idea is that drivers should probe as far as they can with just the chip and then register with the core. The machine driver defers probing until all components have probed and then runs through second stage initialisaton which pulls everything together.
2013/4/10 Mark Brown <broonie@opensource.wolfsonmicro.com>: > On Wed, Apr 10, 2013 at 09:53:20PM +0800, Barry Song wrote: >> 2013/4/10 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > >> >> 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. > > In the ASoC case the idea is that drivers should probe as far as they > can with just the chip and then register with the core. The machine > driver defers probing until all components have probed and then runs > through second stage initialisaton which pulls everything together. yes. thanks for clarification, Mark. that is really what i want in soc-camera too. put all things in their places, and the final connector wait for everyone and put them in the initialized status. -barry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 10 Apr 2013, Barry Song wrote: > Hi Guennadia, There's a typo above. > Thanks! > > 2013/4/10 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > > Hi Barry > > > > On Wed, 10 Apr 2013, Barry Song wrote: > > > >> Hi Guennadia, > >> > >> 2012/9/27 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > >> > 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@gmx.de> > >> > --- > >> > >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2013/4/10 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > On Wed, 10 Apr 2013, Barry Song wrote: > >> Hi Guennadi, > > There's a typo above. sorry for the typo. > >> Thanks! >> >> 2013/4/10 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: >> > Hi Barry >> > >> > On Wed, 10 Apr 2013, Barry Song wrote: >> > >> >> Hi Guennadia, >> >> >> >> 2012/9/27 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: >> >> > 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@gmx.de> >> >> > --- >> >> >> >> 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. i am not sure whether you agree the new way or not. if you also agree this is a better way, i think we can do something to move ahead. i need sync and get input from you expert :-) > > Thanks > Guennadi -barry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 10 Apr 2013, Barry Song wrote: > 2013/4/10 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > > On Wed, 10 Apr 2013, Barry Song wrote: [snip] > >> > 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. > > i am not sure whether you agree the new way or not. if you also agree > this is a better way, In fact I don't. > i think we can do something to move ahead. i > need sync and get input from you expert :-) I suggest you read all the mailing list discussions of these topics over last months / years, conference discussion protocols instead of restarting a beaten to death topic at the v8 time-frame. 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2013/4/10 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: > On Wed, 10 Apr 2013, Barry Song wrote: > >> 2013/4/10 Guennadi Liakhovetski <g.liakhovetski@gmx.de>: >> > On Wed, 10 Apr 2013, Barry Song wrote: > > [snip] > >> >> > 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. >> >> i am not sure whether you agree the new way or not. if you also agree >> this is a better way, > > In fact I don't. > >> i think we can do something to move ahead. i >> need sync and get input from you expert :-) > > I suggest you read all the mailing list discussions of these topics over > last months / years, conference discussion protocols instead of restarting > a beaten to death topic at the v8 time-frame. you think it has been dead but i think it is still alive since there are still sombody like me starting a beaten for that. anyway, it doesn't really matter too much. i can definitely follow what you like as you have succefully built a good soc-camera system. > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ -barry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index b98e602..997be15 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -50,6 +50,9 @@ static LIST_HEAD(hosts); static LIST_HEAD(devices); static DEFINE_MUTEX(list_lock); /* Protects the list of hosts */ +static int soc_camera_video_start(struct soc_camera_device *icd); +static int video_dev_create(struct soc_camera_device *icd); + static struct soc_camera_device *soc_camera_device_find(struct soc_camera_link *icl) { struct soc_camera_device *icd; @@ -1110,15 +1113,168 @@ static void scan_add_host(struct soc_camera_host *ici) mutex_unlock(&ici->host_lock); } +/* + * FIXME: with internally created (I2C) clients the whole host scanning process + * is happening synchronously, i.e. we return from the scanning routine and + * complete host probing only after all clients have been enumerated. This + * allows us to lock the ->host_lock for the whole scan duration and thus + * prevent the user-space from interfering with the probing between single + * clients. This locking is necessary, because otherwise on a host with multiple + * clients, after a video device node has been registered for one of them, a + * user-space process, triggered by hotplug can try to access the first client + * and thereby occupy the host, which will disturb probing of further clients. + * With externally registered clients (host_wait == true) we use (I2C) bus + * notifications to complete client probing. Those notifications are called + * asynchronously after the host probing routine has returned. Besides, it can + * happen, that the notification is called much later or never at all. In this + * case we cannot keep the host locked until all client notifications have been + * called. + */ +static int soc_camera_probe_finish(struct soc_camera_device *icd) +{ + struct soc_camera_host *ici = to_soc_camera_host(icd->parent); + struct v4l2_subdev *sd; + struct v4l2_mbus_framefmt mf; + int ret; + + sd = soc_camera_to_subdev(icd); + sd->grp_id = soc_camera_grp_id(icd); + v4l2_set_subdev_hostdata(sd, icd); + + ret = v4l2_ctrl_add_handler(&icd->ctrl_handler, sd->ctrl_handler); + if (ret < 0) + return ret; + + /* At this point client .probe() should have run already */ + ret = soc_camera_init_user_formats(icd); + if (ret < 0) + return ret; + + icd->field = V4L2_FIELD_ANY; + + /* + * ..._video_start() will create a device node, video_register_device() + * itself is protected against concurrent open() calls, but we also have + * to protect our data. + */ + mutex_lock(&icd->video_lock); + + ret = soc_camera_video_start(icd); + if (ret < 0) + goto evidstart; + + /* Try to improve our guess of a reasonable window format */ + ret = ici->ops->add(icd); + if (ret < 0) + goto eadd; + if (!v4l2_subdev_call(sd, video, g_mbus_fmt, &mf)) { + icd->user_width = mf.width; + icd->user_height = mf.height; + icd->colorspace = mf.colorspace; + icd->field = mf.field; + } + + ici->ops->remove(icd); + + mutex_unlock(&icd->video_lock); + + return 0; + +eadd: + video_unregister_device(icd->vdev); + icd->vdev = NULL; +evidstart: + mutex_unlock(&icd->video_lock); + soc_camera_free_user_formats(icd); + + return ret; +} + #ifdef CONFIG_I2C_BOARDINFO -static int soc_camera_init_i2c(struct soc_camera_device *icd, +static int soc_camera_i2c_notify(struct notifier_block *nb, + unsigned long action, void *data) +{ + struct device *dev = data; + struct i2c_client *client = to_i2c_client(dev); + struct soc_camera_device *icd = container_of(nb, struct soc_camera_device, notifier); + struct soc_camera_host *ici = to_soc_camera_host(icd->parent); + struct soc_camera_link *icl = to_soc_camera_link(icd); + struct i2c_adapter *adap = NULL; + struct v4l2_subdev *subdev; + int ret; + + if (client->addr != icl->board_info->addr || + client->adapter->nr != icl->i2c_adapter_id) + return NOTIFY_DONE; + + switch (action) { + case BUS_NOTIFY_BIND_DRIVER: + client->dev.platform_data = icl; + + return NOTIFY_OK; + case BUS_NOTIFY_BOUND_DRIVER: + adap = i2c_get_adapter(icl->i2c_adapter_id); + if (!adap) + break; + + if (!try_module_get(dev->driver->owner)) + /* clean up */ + break; + + subdev = i2c_get_clientdata(client); + + if (v4l2_device_register_subdev(&ici->v4l2_dev, subdev)) + subdev = NULL; + + module_put(client->driver->driver.owner); + + if (!subdev) + break; + client = v4l2_get_subdevdata(subdev); + icd->control = &client->dev; + mutex_lock(&ici->host_lock); + ret = soc_camera_probe_finish(icd); + mutex_unlock(&ici->host_lock); + if (ret < 0) + break; + + return NOTIFY_OK; + default: + return NOTIFY_DONE; + } + + if (adap) + i2c_put_adapter(adap); + if (icd->vdev) { + video_device_release(icd->vdev); + icd->vdev = NULL; + } + regulator_bulk_free(icl->num_regulators, icl->regulators); + v4l2_ctrl_handler_free(&icd->ctrl_handler); + + return NOTIFY_DONE; +} + +static int soc_camera_i2c_init(struct soc_camera_device *icd, struct soc_camera_link *icl) { struct i2c_client *client; - struct soc_camera_host *ici = to_soc_camera_host(icd->parent); - struct i2c_adapter *adap = i2c_get_adapter(icl->i2c_adapter_id); + struct soc_camera_host *ici; + struct i2c_adapter *adap; struct v4l2_subdev *subdev; + if (icl->host_wait) { + int ret; + icd->notifier.notifier_call = soc_camera_i2c_notify; + ret = bus_register_notifier(&i2c_bus_type, &icd->notifier); + if (!ret) + return -EPROBE_DEFER; + return ret; + } + + ici = to_soc_camera_host(icd->parent); + adap = i2c_get_adapter(icl->i2c_adapter_id); + if (!adap) { dev_err(icd->pdev, "Cannot get I2C adapter #%d. No driver?\n", icl->i2c_adapter_id); @@ -1144,7 +1300,7 @@ ei2cga: return -ENODEV; } -static void soc_camera_free_i2c(struct soc_camera_device *icd) +static void soc_camera_i2c_free(struct soc_camera_device *icd) { struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd)); @@ -1155,21 +1311,38 @@ static void soc_camera_free_i2c(struct soc_camera_device *icd) i2c_unregister_device(client); i2c_put_adapter(adap); } + +static void soc_camera_i2c_reprobe(struct soc_camera_device *icd) +{ + struct i2c_client *client = + to_i2c_client(to_soc_camera_control(icd)); + struct i2c_adapter *adap; + + if (icd->notifier.notifier_call == soc_camera_i2c_notify) + bus_unregister_notifier(&i2c_bus_type, &icd->notifier); + + if (!icd->control) + return; + + adap = client->adapter; + + icd->control = NULL; + v4l2_device_unregister_subdev(i2c_get_clientdata(client)); + /* Put device back in deferred-probing state */ + i2c_unregister_device(client); + i2c_new_device(adap, icd->link->board_info); +} #else -#define soc_camera_init_i2c(icd, icl) (-ENODEV) -#define soc_camera_free_i2c(icd) do {} while (0) +#define soc_camera_i2c_init(icd, icl) (-ENODEV) +#define soc_camera_i2c_free(icd) do {} while (0) +#define soc_camera_i2c_reprobe(icd) do {} while (0) #endif -static int soc_camera_video_start(struct soc_camera_device *icd); -static int video_dev_create(struct soc_camera_device *icd); /* Called during host-driver probe */ static int soc_camera_probe(struct soc_camera_device *icd) { - struct soc_camera_host *ici = to_soc_camera_host(icd->parent); struct soc_camera_link *icl = to_soc_camera_link(icd); struct device *control = NULL; - struct v4l2_subdev *sd; - struct v4l2_mbus_framefmt mf; int ret; dev_info(icd->pdev, "Probing %s\n", dev_name(icd->pdev)); @@ -1201,7 +1374,9 @@ static int soc_camera_probe(struct soc_camera_device *icd) /* Non-i2c cameras, e.g., soc_camera_platform, have no board_info */ if (icl->board_info) { - ret = soc_camera_init_i2c(icd, icl); + ret = soc_camera_i2c_init(icd, icl); + if (ret == -EPROBE_DEFER) + return 0; if (ret < 0) goto eadddev; } else if (!icl->add_device || !icl->del_device) { @@ -1228,58 +1403,15 @@ static int soc_camera_probe(struct soc_camera_device *icd) } } - sd = soc_camera_to_subdev(icd); - sd->grp_id = soc_camera_grp_id(icd); - v4l2_set_subdev_hostdata(sd, icd); - - if (v4l2_ctrl_add_handler(&icd->ctrl_handler, sd->ctrl_handler)) - goto ectrl; - - /* At this point client .probe() should have run already */ - ret = soc_camera_init_user_formats(icd); - if (ret < 0) - goto eiufmt; - - icd->field = V4L2_FIELD_ANY; - - /* - * ..._video_start() will create a device node, video_register_device() - * itself is protected against concurrent open() calls, but we also have - * to protect our data. - */ - mutex_lock(&icd->video_lock); - - ret = soc_camera_video_start(icd); - if (ret < 0) - goto evidstart; - - /* Try to improve our guess of a reasonable window format */ - ret = ici->ops->add(icd); + ret = soc_camera_probe_finish(icd); if (ret < 0) - goto eadd; - if (!v4l2_subdev_call(sd, video, g_mbus_fmt, &mf)) { - icd->user_width = mf.width; - icd->user_height = mf.height; - icd->colorspace = mf.colorspace; - icd->field = mf.field; - } - - ici->ops->remove(icd); - - mutex_unlock(&icd->video_lock); + goto efinish; return 0; -eadd: - video_unregister_device(icd->vdev); - icd->vdev = NULL; -evidstart: - mutex_unlock(&icd->video_lock); - soc_camera_free_user_formats(icd); -eiufmt: -ectrl: +efinish: if (icl->board_info) { - soc_camera_free_i2c(icd); + soc_camera_i2c_free(icd); } else { icl->del_device(icd); module_put(control->driver->owner); @@ -1315,7 +1447,10 @@ static int soc_camera_remove(struct soc_camera_device *icd) } if (icl->board_info) { - soc_camera_free_i2c(icd); + if (icl->host_wait) + soc_camera_i2c_reprobe(icd); + else + soc_camera_i2c_free(icd); } else { struct device_driver *drv = to_soc_camera_control(icd)->driver; if (drv) { diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h index 72342fe..1d4e3c5 100644 --- a/include/media/soc_camera.h +++ b/include/media/soc_camera.h @@ -50,6 +50,7 @@ struct soc_camera_device { int use_count; struct mutex video_lock; /* Protects device data */ struct file *streamer; /* stream owner */ + struct notifier_block notifier; /* Bus-event notifier */ union { struct videobuf_queue vb_vidq; struct vb2_queue vb2_vidq; @@ -125,6 +126,7 @@ struct soc_camera_link { int i2c_adapter_id; struct i2c_board_info *board_info; const char *module_name; + bool host_wait; void *priv; /* Optional regulators that have to be managed on power on/off events */
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@gmx.de> --- drivers/media/platform/soc_camera/soc_camera.c | 255 ++++++++++++++++++------ include/media/soc_camera.h | 2 + 2 files changed, 197 insertions(+), 60 deletions(-)