Re: [PATCH v6] media: imx258: Add imx258 camera sensor driver

[Tomasz Figa <tfiga@chromium.org>]

On Tue, Mar 6, 2018 at 6:46 PM, Sakari Ailus
<sakari.ailus@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.ailus@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.ailus@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

Best regards,
Tomasz