From: g.liakhovetski@gmx.de (Guennadi Liakhovetski)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/5] media: ov2640: add async probe function
Date: Fri, 19 Dec 2014 23:16:15 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.64.1412192307320.21176@axis700.grange> (raw)
In-Reply-To: <5493C1A8.4050204@atmel.com>
On Fri, 19 Dec 2014, Josh Wu wrote:
> Hi, Guennadi
>
> Thanks for the review.
>
> On 12/19/2014 5:59 AM, Guennadi Liakhovetski wrote:
> > Hi Josh,
> >
> > Thanks for your patches!
> >
> > On Thu, 18 Dec 2014, Josh Wu wrote:
> >
> > > To support async probe for ov2640, we need remove the code to get 'mclk'
> > > in ov2640_probe() function. oterwise, if soc_camera host is not probed
> > > in the moment, then we will fail to get 'mclk' and quit the ov2640_probe()
> > > function.
> > >
> > > So in this patch, we move such 'mclk' getting code to ov2640_s_power()
> > > function. That make ov2640 survive, as we can pass a NULL (priv-clk) to
> > > soc_camera_set_power() function.
> > >
> > > And if soc_camera host is probed, the when ov2640_s_power() is called,
> > > then we can get the 'mclk' and that make us enable/disable soc_camera
> > > host's clock as well.
> > >
> > > Signed-off-by: Josh Wu <josh.wu@atmel.com>
> > > ---
> > > v3 -> v4:
> > > v2 -> v3:
> > > v1 -> v2:
> > > no changes.
> > >
> > > drivers/media/i2c/soc_camera/ov2640.c | 31
> > > +++++++++++++++++++++----------
> > > 1 file changed, 21 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/soc_camera/ov2640.c
> > > b/drivers/media/i2c/soc_camera/ov2640.c
> > > index 1fdce2f..9ee910d 100644
> > > --- a/drivers/media/i2c/soc_camera/ov2640.c
> > > +++ b/drivers/media/i2c/soc_camera/ov2640.c
> > > @@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int
> > > on)
> > > struct i2c_client *client = v4l2_get_subdevdata(sd);
> > > struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> > > struct ov2640_priv *priv = to_ov2640(client);
> > > + struct v4l2_clk *clk;
> > > +
> > > + if (!priv->clk) {
> > > + clk = v4l2_clk_get(&client->dev, "mclk");
> > > + if (IS_ERR(clk))
> > > + dev_warn(&client->dev, "Cannot get the mclk. maybe
> > > soc-camera host is not probed yet.\n");
> > > + else
> > > + priv->clk = clk;
> > > + }
> > > return soc_camera_set_power(&client->dev, ssdd, priv->clk,
> > > on);
> > > }
Ok, think about this: you check whether priv->clk is set on each
.s_power() call, which is already a bit awkward. Such approach can be used
when there's no other way to perform a one-time action, but here we have
one. But never mind, that's not the main problem. If priv->clk isn't set,
you try to acquire it. But during probing, when this function is called
for the first time clock isn't available yet, but you still want to
succeed probing. So, you just issue a warning and continue. But then later
an application opens the camera, .s_power() is called again, but for some
reason the clock might still be not available, and this time you should
fail. But you don't, you succeed and then you'll fail somewhere later,
presumably, with a timeout waiting for frames. Am I right?
> > > @@ -1078,21 +1087,21 @@ static int ov2640_probe(struct i2c_client *client,
> > > if (priv->hdl.error)
> > > return priv->hdl.error;
> > > - priv->clk = v4l2_clk_get(&client->dev, "mclk");
> > > - if (IS_ERR(priv->clk)) {
> > > - ret = PTR_ERR(priv->clk);
> > > - goto eclkget;
> > > - }
> > > -
> > > ret = ov2640_video_probe(client);
> > The first thing the above ov2640_video_probe() function will do is call
> > ov2640_s_power(), which will request the clock. So, by moving requesting
> > the clock from ov2640_probe() to ov2640_s_power() doesn't change how
> > probing will be performed, am I right?
> yes, you are right. In this patch, the "mclk" will requested by
> ov2640_s_power().
>
> The reason why I put the getting "mclk" code from ov2640_probe() to
> ov2640_s_power() is : as the "mclk" here is camera host's peripheral clock.
> That means ov2640 still can be probed properly (read ov2640 id) even no
> "mclk". So when I move this code to ov2640_s_power(), otherwise the
> ov2640_probe() will be failed or DEFER_PROBE.
>
> Is this true for all camera host? If it's not true, then I think use
> -EPROBE_DEFER would be a proper way.
Sorry, not sure what your question is. And I'm not sure ov2640's registers
can be accessed with no running clock. I think some camera sensors can do
this, but I have no idea about this one. How did you verify? Is it
mentioned in a datasheet? Or did you really disconnected (grounded) the
sensor clock input and tried to access its reqisters? If you just
verified, that it's working without requesting the clock, are you sure
your clock output isn't running permanently all the time anyway?
Thanks
Guennadi
>
>
> > Or are there any other patched,
> > that change that, that I'm overseeing?
> >
> > If I'm right, then I would propose an approach, already used in other
> > drivers instead of this one: return -EPROBE_DEFER if the clock isn't
> > available during probing. See ef6672ea35b5bb64ab42e18c1a1ffc717c31588a for
> > an example. Or did I misunderstand anything?
> Actually months ago I already done a version of ov2640 patch which use
> -EPROBE_DEFER way.
>
> But now I think the ov2640 can be probed correctly without "mclk", so it is no
> need to return -EPROBE_DEFER.
> And the v4l2 asyn API can handle the synchronization of host. So I prefer to
> use this way.
> What do you think about this?
>
> Best Regards,
> Josh Wu
>
> >
> > Thanks
> > Guennadi
> >
> > > if (ret) {
> > > - v4l2_clk_put(priv->clk);
> > > -eclkget:
> > > - v4l2_ctrl_handler_free(&priv->hdl);
> > > + goto evideoprobe;
> > > } else {
> > > dev_info(&adapter->dev, "OV2640 Probed\n");
> > > }
> > > + ret = v4l2_async_register_subdev(&priv->subdev);
> > > + if (ret < 0)
> > > + goto evideoprobe;
> > > +
> > > + return 0;
> > > +
> > > +evideoprobe:
> > > + v4l2_ctrl_handler_free(&priv->hdl);
> > > return ret;
> > > }
> > > @@ -1100,7 +1109,9 @@ static int ov2640_remove(struct i2c_client
> > > *client)
> > > {
> > > struct ov2640_priv *priv = to_ov2640(client);
> > > - v4l2_clk_put(priv->clk);
> > > + v4l2_async_unregister_subdev(&priv->subdev);
> > > + if (priv->clk)
> > > + v4l2_clk_put(priv->clk);
> > > v4l2_device_unregister_subdev(&priv->subdev);
> > > v4l2_ctrl_handler_free(&priv->hdl);
> > > return 0;
> > > --
> > > 1.9.1
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2014-12-19 22:16 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 2:27 [PATCH v4 0/5] media: ov2640: add device tree support Josh Wu
2014-12-18 2:27 ` [PATCH v4 1/5] media: soc-camera: use icd->control instead of icd->pdev for reset() Josh Wu
2014-12-18 2:27 ` [PATCH v4 2/5] media: ov2640: add async probe function Josh Wu
2014-12-18 21:59 ` Guennadi Liakhovetski
2014-12-19 6:11 ` Josh Wu
2014-12-19 22:16 ` Guennadi Liakhovetski [this message]
2014-12-22 10:27 ` Josh Wu
2014-12-24 22:39 ` Guennadi Liakhovetski
2014-12-26 6:37 ` Josh Wu
2014-12-26 9:01 ` Laurent Pinchart
2014-12-26 9:14 ` Guennadi Liakhovetski
2014-12-26 10:06 ` Laurent Pinchart
2014-12-26 10:38 ` Guennadi Liakhovetski
2014-12-30 0:23 ` Laurent Pinchart
2014-12-30 8:36 ` Guennadi Liakhovetski
2014-12-30 8:58 ` Laurent Pinchart
2014-12-30 10:08 ` Josh Wu
2014-12-30 12:12 ` Guennadi Liakhovetski
2015-01-01 17:44 ` Laurent Pinchart
2014-12-29 8:28 ` Josh Wu
2014-12-30 0:15 ` Laurent Pinchart
2014-12-30 10:02 ` Josh Wu
2015-01-01 17:43 ` Laurent Pinchart
2014-12-18 2:27 ` [PATCH v4 3/5] media: ov2640: add primary dt support Josh Wu
2014-12-18 2:27 ` [PATCH v4 4/5] media: ov2640: add a master clock for sensor Josh Wu
2014-12-18 2:27 ` [PATCH v4 5/5] media: ov2640: dt: add the device tree binding document Josh Wu
2014-12-18 11:56 ` Laurent Pinchart
2014-12-18 12:13 ` Sylwester Nawrocki
2014-12-18 12:21 ` Fabio Estevam
2014-12-22 10:32 ` Josh Wu
2014-12-22 11:47 ` Sylwester Nawrocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1412192307320.21176@axis700.grange \
--to=g.liakhovetski@gmx.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox