[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFooD2z9J0vYC0GzcoyQBsEv1PEM4tG9RiQktDGt94sAPA@mail.gmail.com>
Date: Wed, 9 Jul 2025 15:24:49 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux PM <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>,
Alex Elder <elder@...aro.org>, Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH v1] PM: runtime: Take active children into account in pm_runtime_get_if_in_use()
On Wed, 9 Jul 2025 at 14:48, Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Wed, Jul 9, 2025 at 2:06 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
> >
> > On Wed, Jul 9, 2025 at 1:47 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
> > >
> > > On Wed, 9 Jul 2025 at 12:41, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> > > >
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > > >
> > > > For all practical purposes, there is no difference between the situation
> > > > in which a given device is not ignoring children and its active child
> > > > count is nonzero and the situation in which its runtime PM usage counter
> > > > is nonzero. However, pm_runtime_get_if_in_use() will only increment the
> > > > device's usage counter and return 1 in the latter case.
> > > >
> > > > For consistency, make it do so in the former case either by adjusting
> > > > pm_runtime_get_conditional() and update the related kerneldoc comments
> > > > accordingly.
> > > >
> > > > Fixes: c0ef3df8dbae ("PM: runtime: Simplify pm_runtime_get_if_active() usage")
> > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > > > ---
> > > > drivers/base/power/runtime.c | 27 ++++++++++++++++++---------
> > > > 1 file changed, 18 insertions(+), 9 deletions(-)
> > > >
> > > > --- a/drivers/base/power/runtime.c
> > > > +++ b/drivers/base/power/runtime.c
> > > > @@ -1203,10 +1203,12 @@
> > > > *
> > > > * Return -EINVAL if runtime PM is disabled for @dev.
> > > > *
> > > > - * Otherwise, if the runtime PM status of @dev is %RPM_ACTIVE and either
> > > > - * @ign_usage_count is %true or the runtime PM usage counter of @dev is not
> > > > - * zero, increment the usage counter of @dev and return 1. Otherwise, return 0
> > > > - * without changing the usage counter.
> > > > + * Otherwise, if its runtime PM status is %RPM_ACTIVE and (1) @ign_usage_count
> > > > + * is set, or (2) @dev is not ignoring children and its active child count is
> > > > + * nonero, or (3) the runtime PM usage counter of @dev is not zero, increment
> > > > + * the usage counter of @dev and return 1.
> > > > + *
> > > > + * Otherwise, return 0 without changing the usage counter.
> > > > *
> > > > * If @ign_usage_count is %true, this function can be used to prevent suspending
> > > > * the device when its runtime PM status is %RPM_ACTIVE.
> > > > @@ -1228,7 +1230,8 @@
> > > > retval = -EINVAL;
> > > > } else if (dev->power.runtime_status != RPM_ACTIVE) {
> > > > retval = 0;
> > > > - } else if (ign_usage_count) {
> > > > + } else if (ign_usage_count || (!dev->power.ignore_children &&
> > > > + atomic_read(&dev->power.child_count) > 0)) {
> > >
> > > I am not sure I understand why this is needed, sorry.
> > >
> > > If someone and somehow we have "dev->power.runtime_status ==
> > > RPM_ACTIVE", then the dev's parents/childrens and suppliers/consumers
> > > should have been reference counted correctly already.
> >
> > Sure.
> >
> > > Otherwise it should not have been possible to set the runtime_status to RPM_ACTIVE
> > > in the first place, right?
> >
> > Right.
> >
> > runtime_status must be RPM_ACTIVE, but pm_runtime_get_if_in_use() only
> > wants to bump it up if the device is in use in addition to that.
>
> I mean pm_runtime_get_if_in_use() only wants to bump up the device's
> usage counter if it is in use already.
>
> > So far it's been checking the usage counter only though.
>
> And the above is correct.
Aha, I understand your point now.
Comparing how a runtime resume of consumer-device-link works (it bumps
the provider's usage count), your change makes perfect sense as it
aligns the behaviour for child devices.
[...]
That said, please add:
Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
Kind regards
Uffe
Powered by blists - more mailing lists