LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Maulik Shah <mkshah@codeaurora.org>
To: Ulf Hansson <ulf.hansson@linaro.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Len Brown <len.brown@intel.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] PM: sleep: Fix runtime PM based cpuidle support
Date: Fri, 22 Oct 2021 14:45:06 +0530	[thread overview]
Message-ID: <28b0c55c-aa3e-8956-7be3-594e7b340107@codeaurora.org> (raw)
In-Reply-To: <CAPDyKFpjy5sZo6ayqPx07Jzs4J2yePy=cZk=k6VjhWB7zGeedg@mail.gmail.com>

Hi,

On 10/22/2021 1:26 AM, Ulf Hansson wrote:
> On Thu, 21 Oct 2021 at 21:02, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>
>> On Thu, Oct 21, 2021 at 8:12 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>>
>>> On Thu, 21 Oct 2021 at 18:33, Rafael J. Wysocki <rafael@kernel.org> wrote:
>>>>
>>>> On Thu, Oct 21, 2021 at 6:17 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>
>> [cut]
>>
>>>> So in theory you could check the pm_runtime_put_sync_suspend() return
>>>> value and fall back to something like WFI if that's an error code.
>>>
>>> I have already tried that, but it simply got too complicated. The main
>>> issue was that runtime PM could become disabled for the device in the
>>> middle of executing the ->enter() callback.
>>
>> So IIUC the problem is that you cannot resume after suspending in that case.
>>
>> IOW, you need to guarantee that if the suspend is successful, the
>> resume also will take place, but if the suspend fails, you basically
>> don't care.
> 
> Exactly.
> 
>>
>>> For example, if pm_runtime_get_sync() fails, I still need to make sure
>>> the reference counting in genpd becomes correct - and I can't do that
>>> using dev_pm_genpd_resume(). That's because it's not designed to be
>>> called in this "unknown" suspend phase, but should be called after the
>>> noirq phase and be properly balanced with dev_pm_genpd_suspend().
>>>
>>> In other words, the error path didn't work out for me.
>>
>> It should be sufficient to call wake_up_all_idle_cpus() in the suspend
>> path before dpm_suspend_late(), because system suspend acquires a
>> PM-runtime reference on every device.  IOW, it won't let any devices
>> runtime-suspend, so if your power domain devices are resumed in that
>> path, they will never suspend again in it and the
>> pm_runtime_put_sync_suspend() in __psci_enter_domain_idle_state()
>> becomes a reference counter management call which works regardless of
>> whether or not PM runtime is disabled.
> 
> That sounds like a great idea, this should work too! Then the question
> is, how to make that call to wake_up_all_idle_cpus() to become
> optional - or only invoked for the cpuidle drivers that need it.
> 
> In any case, I will try this out, thanks for the suggestion!
> 
> Kind regards
> Uffe

This may not work given that CPUs may re-enter idle after call to 
wake_up_all_idle_cpus() is finished.

say a case where,

1. wake_up_all_idle_cpus() is called first then
2. __device_suspend_late() does __pm_runtime_disable() for all CPU devices.

inbetween 1 and 2, CPUs may have entered idle again and would have done
pm_runtime_put_sync_suspend() while entering idle from cpuidle-psci.

I was thinking if PM-QoS may be of help here, before runtime PM is 
disabled, if QoS is taken with less value (say 1us) then all CPUs will
wake up to serve the QoS and then stay in simple WFI() due to QoS and 
won't do any runtime put/get, which serve similar to cpuidle_pause() + 
default idle call.

if QoS can be somehow taken from cpuidle-psci driver registering for 
suspend ops? it won't effect other archs/idle drivers.

Thanks,
Maulik
> 

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation

  reply	other threads:[~2021-10-22  9:15 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 14:44 [PATCH 0/2] cpuidle: Fix runtime PM based cpuidle for s2idle Ulf Hansson
2021-09-29 14:44 ` [PATCH 1/2] cpuidle: Avoid calls to cpuidle_resume|pause() " Ulf Hansson
2021-10-06 10:22   ` Maulik Shah
2021-10-06 13:10     ` Ulf Hansson
2021-10-09 15:42       ` Rafael J. Wysocki
2021-10-09 15:39   ` Rafael J. Wysocki
2021-10-11 10:04     ` Ulf Hansson
2021-09-29 14:44 ` [PATCH 2/2] PM: sleep: Fix runtime PM based cpuidle support Ulf Hansson
2021-10-06 10:28   ` Maulik Shah
2021-10-20 18:18   ` Rafael J. Wysocki
2021-10-21 11:48     ` Ulf Hansson
2021-10-21 13:45       ` Rafael J. Wysocki
2021-10-21 14:04         ` Ulf Hansson
2021-10-21 15:09           ` Rafael J. Wysocki
2021-10-21 15:45             ` Rafael J. Wysocki
2021-10-21 16:28               ` Ulf Hansson
2021-10-21 16:41                 ` Rafael J. Wysocki
2021-10-21 17:05                   ` Rafael J. Wysocki
2021-10-21 18:49                     ` Ulf Hansson
2021-10-21 18:36                   ` Ulf Hansson
2021-10-21 16:16             ` Ulf Hansson
2021-10-21 16:33               ` Rafael J. Wysocki
2021-10-21 18:11                 ` Ulf Hansson
2021-10-21 19:02                   ` Rafael J. Wysocki
2021-10-21 19:56                     ` Ulf Hansson
2021-10-22  9:15                       ` Maulik Shah [this message]
2021-10-22 10:18                       ` Ulf Hansson
2021-10-22 12:02                         ` Rafael J. Wysocki
2021-10-22 12:56                           ` Ulf Hansson
2021-10-22 13:08                             ` 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=28b0c55c-aa3e-8956-7be3-594e7b340107@codeaurora.org \
    --to=mkshah@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=len.brown@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=vincent.guittot@linaro.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;
as well as URLs for NNTP newsgroup(s).