From: Ulf Hansson <ulf.hansson@linaro.org>
To: Douglas Anderson <dianders@chromium.org>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
Stephen Boyd <sboyd@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH] PM: runtime: Have devm_pm_runtime_enable() handle pm_runtime_dont_use_autosuspend()
Date: Tue, 1 Mar 2022 11:26:46 +0100 [thread overview]
Message-ID: <CAPDyKFrDncw0D2ccw9GJS+oRdm2kROJh25OV9pMs+992vQV-cQ@mail.gmail.com> (raw)
In-Reply-To: <20220223083441.1.I925ce9fa12992a58caed6b297e0171d214866fe7@changeid>
On Wed, 23 Feb 2022 at 17:35, Douglas Anderson <dianders@chromium.org> wrote:
>
> The PM Runtime docs say:
> Drivers in ->remove() callback should undo the runtime PM changes done
> in ->probe(). Usually this means calling pm_runtime_disable(),
> pm_runtime_dont_use_autosuspend() etc.
>
> From grepping code, it's clear that many people aren't aware of the
> need to call pm_runtime_dont_use_autosuspend().
Well, I admit it's good practice that they should take care of this.
However, it doesn't really matter to keep the autosuspend turned on
when runtime PM becomes disabled, I think. When the driver gets probed
again, it will most likely call pm_runtime_use_autosuspend() again,
which should work fine, right?
>
> When brainstorming solutions, one idea that came up was to leverage
> the new-ish devm_pm_runtime_enable() function. The idea here is that:
> * When the devm action is called we know that the driver is being
> removed. It's the perfect time to undo the use_autosuspend.
> * The code of pm_runtime_dont_use_autosuspend() already handles the
> case of being called when autosuspend wasn't enabled.
Hmm, I am hesitating to extend devm_pm_runtime_enable(), as it
currently makes it look too simple to turn off things at ->remove()
for runtime PM. While in fact it's more complicated.
A bigger problem, for example, is that a driver calls
pm_runtime_put_sync() during ->remove(), relying on that it actually
ends up calling its ->runtime_suspend() callback to turn off various
specific resources for the device. And in fact there are no guarantees
that will happen - and when it doesn't, the next time the driver's
->probe() runs, things are likely to be really screwed up.
To cover this case, one could use the below code in the ->remove() callback:
...
pm_runtime_get_sync();
"turn off resources for the devices - like calling
clk_disable_unprepare(), for example"
pm_runtime_disable();
pm_runtime_put_noidle();
...
In this example, it would be too late to call pm_runtime_disable()
through the pm_runtime_disable_action().
Kind regards
Uffe
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> drivers/base/power/runtime.c | 5 +++++
> include/linux/pm_runtime.h | 4 ++++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 2f3cce17219b..d4059e6ffeae 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -1476,11 +1476,16 @@ EXPORT_SYMBOL_GPL(pm_runtime_enable);
>
> static void pm_runtime_disable_action(void *data)
> {
> + pm_runtime_dont_use_autosuspend(data);
> pm_runtime_disable(data);
> }
>
> /**
> * devm_pm_runtime_enable - devres-enabled version of pm_runtime_enable.
> + *
> + * NOTE: this will also handle calling pm_runtime_dont_use_autosuspend() for
> + * you at driver exit time if needed.
> + *
> * @dev: Device to handle.
> */
> int devm_pm_runtime_enable(struct device *dev)
> diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
> index 9f09601c465a..2bff6a10095d 100644
> --- a/include/linux/pm_runtime.h
> +++ b/include/linux/pm_runtime.h
> @@ -567,6 +567,10 @@ static inline void pm_runtime_disable(struct device *dev)
> * Allow the runtime PM autosuspend mechanism to be used for @dev whenever
> * requested (or "autosuspend" will be handled as direct runtime-suspend for
> * it).
> + *
> + * NOTE: It's important to undo this with pm_runtime_dont_use_autosuspend()
> + * at driver exit time unless your driver initially enabled pm_runtime
> + * with devm_pm_runtime_enable() (which handles it for you).
> */
> static inline void pm_runtime_use_autosuspend(struct device *dev)
> {
> --
> 2.35.1.473.g83b2b277ed-goog
>
next prev parent reply other threads:[~2022-03-01 10:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 16:34 Douglas Anderson
2022-03-01 10:26 ` Ulf Hansson [this message]
2022-03-01 10:49 ` Laurent Pinchart
2022-03-01 11:18 ` Ulf Hansson
2022-03-01 16:29 ` Laurent Pinchart
2022-03-03 23:10 ` Ulf Hansson
2022-03-04 0:04 ` Doug Anderson
2022-03-04 7:46 ` Laurent Pinchart
2022-03-01 16:13 ` Doug Anderson
2022-03-04 10:03 ` Ulf Hansson
2022-03-04 17:30 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPDyKFrDncw0D2ccw9GJS+oRdm2kROJh25OV9pMs+992vQV-cQ@mail.gmail.com \
--to=ulf.hansson@linaro.org \
--cc=dianders@chromium.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=len.brown@intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®