RE: [PATCH 5/5 v2] [media] ov9740: Add suspend/resume

Guennadi Liakhovetski
2011-06-01T19:51:57Z

On Tue, 31 May 2011, Andrew Chew wrote:

> > > + /* For suspend/resume. */
> > > + struct v4l2_mbus_framefmt current_mf;
> > > + int current_enable;
> >
> > bool?
>
> Are you sure you want this to be a bool? This thing is trying to shadow
> the "enable" parameter of the s_stream() callback, and that enable
> parameter is int.

You use it as a bool.

> > > +static int ov9740_suspend(struct soc_camera_device *icd,
> > pm_message_t state)
> > > +{
> > > + struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
> > > + struct ov9740_priv *priv = to_ov9740(sd);
> > > +
> > > + if (priv->current_enable) {
> > > + int current_enable = priv->current_enable;
> > > +
> > > + ov9740_s_stream(sd, 0);
> > > + priv->current_enable = current_enable;
> >
> > You don't need the local variable, just set
> >
> > priv->current_enable = true;
>
> I think I do need that local variable, the way the code is arranged now.
> I'm trying to save the state of enablement inside of
> priv->current_enable, at the time we are suspending, so it won't
> necessarily be true. And one of the side effects of calling
> ov9740_s_stream(sd, 0) is that priv->current_enable will be set to
> false, which is why I save off the value of priv->current_enable, and
> then restore it after the call to ov9740_s_stream().

? Sorry, don't understand. You only _enter_ that "if" statement, if
priv->current_enable is true. So, your local variable is _certainly_ true.
And that's what you're then writing in priv->current_enable back again.

> > > static struct soc_camera_ops ov9740_ops = {
> > > + .suspend = ov9740_suspend,
> > > + .resume = ov9740_resume,
> >
> > No, we don't want to use these, whey should disappear some
> > time... Please,
> > use .s_power() from struct v4l2_subdev_core_ops, you can check
> > http://article.gmane.org/gmane.linux.drivers.video-input-infra
> > structure/33105
> > for an example. If your host is not using these ops, it has
> > to be fixed.
> > So far in the mainline only one soc-camera host driver is using these
> > callbacks: pxa_camera.c, which, looking at your email
> > address, I doubt is
> > the driver, that you're using;)
>
> Okay, will do. Thanks for pointing that out :)
>
> Is the camera host driver expected to directly call the sensor driver's
> s_power (via v4l2_subdev_call(sd, core, s_power, <some value>)? Or does
> the v4l2 framework do this for you? I didn't see an example of this in
> my last pull of linux-next.

yes, the host driver has to call s_power explicitly.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer