lkml.org 
[lkml]   [2011]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [PATCH 5/5 v2] [media] ov9740: Add suspend/resume
> > +	/* 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.


> > +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().


> > 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.

\
 
 \ /
  Last update: 2011-06-01 04:01    [W:0.052 / U:1.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site