All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Brian Norris <briannorris@chromium.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	linux-pm@vger.kernel.org, linux-iio@vger.kernel.org,
	"Andy Shevchenko" <andy@kernel.org>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	linux-stm32@st-md-mailman.stormreply.com,
	"Jonathan Cameron" <jic23@kernel.org>,
	"David Lechner" <dlechner@baylibre.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	linux-kernel@vger.kernel.org,
	"Fabrice Gasnier" <fabrice.gasnier@st.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/5] PM: runtime: Propagate last_busy from dependent to dependency
Date: Sat, 3 Oct 2026 18:21:44 +0300	[thread overview]
Message-ID: <asEdiIT7l49vhn7i@ashevche-desk.local> (raw)
In-Reply-To: <20261002160309.3.I40c0bc917fa0b13111251844e9a54feb1d9cd7d2@changeid>

On Fri, Oct 02, 2026 at 04:03:07PM -0700, Brian Norris wrote:
> When a child device suspends, it does not update the last_busy timestamp
> for its parent. If that parent configured autosuspend and didn't
> otherwise maintain its last_busy timestamp, it may now be immediately
> eligible to suspend. This is probably not expected -- the parent should
> wait for its autosuspend delay before suspending.
> 
> The effect of this behavior is that a parent device may suspend sooner
> than its autosuspend delay, simply because its usage was accounted by
> its children, and not by direct references to the parent device.
> 
> This was noticed in several cases, and some have implemented
> workarounds, such as in commit c537d3457542 ("iio: adc: stm32-adc: fix
> runtime autosuspend delay when slow polling"). At the same time, Ulf
> suggested these problems "should be solved in the runtime PM core".
> 
> Instead of working around the problem in drivers, we propagate last_busy
> timestamps from a dependent device to its dependencies any time it may
> allow a dependency to suspend -- i.e., when releasing a refcount for its
> parent or suppliers. We take care to only propagate the timestamp if it
> is larger than the existing busy timestamp.
> 
> Note that this works best if the dependent device is using autosuspend
> (and therefore updates its last_busy timestamps appropriately), but even
> for a non-autosuspend child, this is still somewhat useful --
> non-autosuspend devices still automatically update their last_busy every
> time they resume.

> Link: https://lore.kernel.org/all/CAPDyKFp=KTf8=zGBSzPYqhjnZpY8xwvjCeM1e-WTKT1QLSxaDA@mail.gmail.com/

Because Linus might complain on odd Link tags, please make sure you have a
reference to it in the text and place it in a form like

Link: $URL [1]

and respectively in the text use [1] as a reference.

> Cc: Ulf Hansson <ulfh@kernel.org>

Can go under the '---' cutter, so it won't pollute the commit message in the
Git history.

> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---

 Cc: ...

...

> +/*
> + * Propagate last_busy timestamp from one device to another. This can, for
> + * example, prevent overactive suspend when a dependency's usage is primarily
> + * driven by one of its dependents.
> + */
> +static void rpm_propagate_last_busy(struct device *dev, struct device *target)
> +{
> +	s64 busy = atomic64_read(&dev->power.last_busy);
> +	s64 target_busy = atomic64_read(&target->power.last_busy);
> +
> +	while (target_busy < busy)

But here you already have an outdated ones, no? Why is this not a problem?

> +		if (atomic64_try_cmpxchg(&target->power.last_busy, &target_busy, busy))
> +			return;
> +}

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2026-10-03 15:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 23:03 [PATCH 0/5] PM: runtime: Improve autosuspend child to parent propagation Brian Norris
2026-10-02 23:03 ` [PATCH 1/5] PM: runtime: Only queue an idle check for RPM-linked suppliers (part 2) Brian Norris
2026-10-02 23:03 ` [PATCH 2/5] PM: runtime: Convert last_busy to atomic64_t Brian Norris
2026-10-02 23:03 ` [PATCH 3/5] PM: runtime: Propagate last_busy from dependent to dependency Brian Norris
2026-10-03 15:21   ` Andy Shevchenko [this message]
2026-10-05 18:05     ` Brian Norris
2026-10-12 19:58       ` Andy Shevchenko
2026-10-12 23:17         ` Brian Norris
2026-10-13  6:11           ` Andy Shevchenko
2026-10-02 23:03 ` [PATCH 4/5] PM: runtime: Add tests for last_busy propagation Brian Norris
2026-10-02 23:03 ` [PATCH 5/5] iio: adc: stm32-adc: Drop runtime_idle() Brian Norris
2026-10-06 12:42   ` Fabrice Gasnier

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=asEdiIT7l49vhn7i@ashevche-desk.local \
    --to=andriy.shevchenko@intel.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andy@kernel.org \
    --cc=briannorris@chromium.org \
    --cc=dlechner@baylibre.com \
    --cc=fabrice.gasnier@st.com \
    --cc=jic23@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=nuno.sa@analog.com \
    --cc=rafael@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.