On Tue, Mar 06, 2018 at 06:52:16PM +0900, Tomasz Figa wrote:
> On Tue, Mar 6, 2018 at 6:46 PM, Sakari Ailus
> <sakari.ai...@linux.intel.com> wrote:
> > On Tue, Mar 06, 2018 at 06:28:43PM +0900, Tomasz Figa wrote:
> >> On Tue, Mar 6, 2018 at 6:18 PM, Sakari Ailus
> >> <sakari.ai...@linux.intel.com> wrote:
> >> > On Tue, Mar 06, 2018 at 05:51:36PM +0900, Tomasz Figa wrote:
> >> >> On Tue, Mar 6, 2018 at 5:40 PM, Sakari Ailus
> >> >> <sakari.ai...@linux.intel.com> wrote:
> >> >> > Hi Tomasz and Andy,
> >> >> >
> >> >> > On Sat, Mar 03, 2018 at 12:43:59AM +0900, Tomasz Figa wrote:
> >> >> > ...
> >> >> >> > +static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
> >> >> >> > +{
> >> >> >> > +       struct imx258 *imx258 =
> >> >> >> > +               container_of(ctrl->handler, struct imx258, 
> >> >> >> > ctrl_handler);
> >> >> >> > +       struct i2c_client *client = 
> >> >> >> > v4l2_get_subdevdata(&imx258->sd);
> >> >> >> > +       int ret = 0;
> >> >> >> > +       /*
> >> >> >> > +        * Applying V4L2 control value only happens
> >> >> >> > +        * when power is up for streaming
> >> >> >> > +        */
> >> >> >> > +       if (pm_runtime_get_if_in_use(&client->dev) <= 0)
> >> >> >> > +               return 0;
> >> >> >>
> >> >> >> I thought we decided to fix this to handle disabled runtime PM 
> >> >> >> properly.
> >> >> >
> >> >> > Good point. I bet this is a problem in a few other drivers, too. How 
> >> >> > would
> >> >> > you fix that? Check for zero only?
> >> >> >
> >> >>
> >> >> bool need_runtime_put;
> >> >>
> >> >> ret = pm_runtime_get_if_in_use(&client->dev);
> >> >> if (ret <= 0 && ret != -EINVAL)
> >> >>         return ret;
> >> >> need_runtime_put = ret > 0;
> >> >>
> >> >> // Do stuff ...
> >> >>
> >> >> if (need_runtime_put)
> >> >>        pm_runtime_put(&client->dev);
> >> >>
> >> >> I don't like how ugly it is, but it appears to be the only way to
> >> >> handle this correctly.
> >> >
> >> > The driver enables runtime PM so if runtime PM is enabled in kernel
> >> > configuration, it is enabled here. In that case 
> >> > pm_runtime_get_if_in_use()
> >> > will return either 0 or 1. So as far as I can see, changing the lines to:
> >> >
> >> >         if (!pm_runtime_get_if_in_use(&client->dev))
> >> >                 return 0;
> >> >
> >> > is enough.
> >>
> >> Right, my bad. Somehow I was convinced that enable status can change at
> >> runtime.
> >
> > Good point. I guess in principle this could happen although I can't see a
> > reason to do so, other than to break things --- quoting
> > Documentation/power/runtime_pm.txt:
> >
> >         The user space can effectively disallow the driver of the device to
> >         power manage it at run time by changing the value of its
> >         /sys/devices/.../power/control attribute to "on", which causes
> >         pm_runtime_forbid() to be called. In principle, this mechanism may
> >         also be used by the driver to effectively turn off the runtime
> >         power management of the device until the user space turns it on.
> >         Namely, during the initialization the driver can make sure that the
> >         runtime PM status of the device is 'active' and call
> >         pm_runtime_forbid(). It should be noted, however, that if the user
> >         space has already intentionally changed the value of
> >         /sys/devices/.../power/control to "auto" to allow the driver to
> >         power manage the device at run time, the driver may confuse it by
> >         using pm_runtime_forbid() this way.
> >
> > So that comes with a warning that things might not work well after doing
> > so.
> >
> > What comes to the driver code, I still wouldn't complicate it by attempting
> > to make a driver work in such a case.
> 
> I think pm_runtime_forbid() and pm_runtime_enable() operate on
> complete different data. That was exactly the source of my confusion
> earlier. Looking at the code [1], even if runtime PM is "forbidden",
> it is still "enabled" and just the usage count is incremented.
> 
> https://elixir.bootlin.com/linux/latest/source/drivers/base/power/runtime.c#L1314

Ah, right. Thanks for the correction. Then indeed this is very clear.

-- 
Sakari Ailus
sakari.ai...@linux.intel.com

Reply via email to