mbox series

[v9,0/2] Better domain idle from device wakeup patterns

Message ID 20210120155042.28975-1-ilina@codeaurora.org (mailing list archive)
Headers show
Series Better domain idle from device wakeup patterns | expand

Message

Lina Iyer Jan. 20, 2021, 3:50 p.m. UTC
Changes since v8 [8]:
- Check if device is attached to genpd

Changes since v7 [7]:
- Whitespace and comment fixes
- Add Reviewed-by tags

Changes since v6 [6];
- Based on discussions on [6], this update simplifies the next wakeup
  of domains based on genpd flag GENPD_FLAG_MIN_RESIDENCY specified at
  init.
- Assume next wakeup will be set by devices when the domain is not
  powered down. This could avoid locking requirements.
- Update commit text.

Changes since v5 [5]:
- It was pointed out that we don't want to run through the unnecessary
  work for domains that do not need or support next-wakeup. So, patch #1
  in this version, now uses a flag to detemine if the domain would
  support next-wakeup.
- Other review comments addressed in patches #2, #3

Changes since v4 [4]:
- Address review comments

Changes since v3 [3]:
- Move the next_wakeup info of the device deeper into the device's
  domain data. This should avoid overhead for devices that do not have a
  predictable wakeup pattern.

Changes since v2:
- Fix unwanted change

Changes since v1 [2]:
- Update documentation and commit text
- Remove check for runtime PM when setting next_event
- Fix kernel-test robot reported issue

Changes since RFC [1]:
- Organized the code to make it cleaner
- Fixed some issues with idle state determination
- Add documentation and update commit text

Hello,

I was looking for an option to do better power management for some
domains where the devices enter runtime PM in a predictable fashion. For
example a display device that sends a vsync interrupt every 16 ms for a
60 Hz panel. These interrupts are not timer interrupts but tend to
interrupt periodically to service the workflow and the devices and
domains may go back to idle soon after. Two domains are affected by this
- the device's PM domain and the CPU PM domain.

As a first step, I am looking to solve for the device's PM domain idle
state (and hopefully solve for the CPU PM domains subsequently). The PM
domain could have multiple idle states and/or the enter/exit latencies
could be high. In either case, it may not always be beneficial to power
off the domain, only to turn it back on before satisfying the idle state
residency. When the wakeup is known for the device, we could use that to
determine the worthiness of entering a domain idle state. Only the
device can tell us when the future event would be and that could change
as the usecase changes. Like, when the panel refresh rate increases to
120 Hz. If this information was made available to runtime PM, we could
use that in the domain governor to determine a suitable idle state. This
is the idea behind these patches.

Would appreciate your thoughts on this.

Thanks,
Lina

[1].
https://lore.kernel.org/linux-pm/010101746eccb270-05beb27f-e1e4-40eb-92da-ad1bb48feb41-000000@us-west-2.amazonses.com/T
/
[2]. https://lore.kernel.org/linux-pm/20201012223400.23609-3-ilina@codeaurora.org/T/#u
[3]. https://lore.kernel.org/linux-pm/20201015193807.17423-1-ilina@codeaurora.org/
[4]. https://www.spinics.net/lists/linux-arm-msm/msg74322.html
[5]. https://lore.kernel.org/linux-pm/20201106164811.3698-1-ilina@codeaurora.org/T/#t
[6]. https://lore.kernel.org/linux-pm/20201130225039.15981-1-ilina@codeaurora.org/T/#t
[7]. https://lore.kernel.org/linux-pm/20210113201601.14874-1-ilina@codeaurora.org/T/#t
[8]. https://lore.kernel.org/linux-pm/20210115165004.22385-1-ilina@codeaurora.org/T/#t


Lina Iyer (2):
  PM / domains: inform PM domain of a device's next wakeup
  PM / Domains: use device's next wakeup to determine domain idle state

 drivers/base/power/domain.c          |  30 ++++++++
 drivers/base/power/domain_governor.c | 102 ++++++++++++++++++++++++---
 include/linux/pm_domain.h            |  12 ++++
 3 files changed, 135 insertions(+), 9 deletions(-)

Comments

Rafael J. Wysocki Jan. 22, 2021, 4:10 p.m. UTC | #1
On Wed, Jan 20, 2021 at 4:53 PM Lina Iyer <ilina@codeaurora.org> wrote:
>
> Changes since v8 [8]:
> - Check if device is attached to genpd
>
> Changes since v7 [7]:
> - Whitespace and comment fixes
> - Add Reviewed-by tags
>
> Changes since v6 [6];
> - Based on discussions on [6], this update simplifies the next wakeup
>   of domains based on genpd flag GENPD_FLAG_MIN_RESIDENCY specified at
>   init.
> - Assume next wakeup will be set by devices when the domain is not
>   powered down. This could avoid locking requirements.
> - Update commit text.
>
> Changes since v5 [5]:
> - It was pointed out that we don't want to run through the unnecessary
>   work for domains that do not need or support next-wakeup. So, patch #1
>   in this version, now uses a flag to detemine if the domain would
>   support next-wakeup.
> - Other review comments addressed in patches #2, #3
>
> Changes since v4 [4]:
> - Address review comments
>
> Changes since v3 [3]:
> - Move the next_wakeup info of the device deeper into the device's
>   domain data. This should avoid overhead for devices that do not have a
>   predictable wakeup pattern.
>
> Changes since v2:
> - Fix unwanted change
>
> Changes since v1 [2]:
> - Update documentation and commit text
> - Remove check for runtime PM when setting next_event
> - Fix kernel-test robot reported issue
>
> Changes since RFC [1]:
> - Organized the code to make it cleaner
> - Fixed some issues with idle state determination
> - Add documentation and update commit text
>
> Hello,
>
> I was looking for an option to do better power management for some
> domains where the devices enter runtime PM in a predictable fashion. For
> example a display device that sends a vsync interrupt every 16 ms for a
> 60 Hz panel. These interrupts are not timer interrupts but tend to
> interrupt periodically to service the workflow and the devices and
> domains may go back to idle soon after. Two domains are affected by this
> - the device's PM domain and the CPU PM domain.
>
> As a first step, I am looking to solve for the device's PM domain idle
> state (and hopefully solve for the CPU PM domains subsequently). The PM
> domain could have multiple idle states and/or the enter/exit latencies
> could be high. In either case, it may not always be beneficial to power
> off the domain, only to turn it back on before satisfying the idle state
> residency. When the wakeup is known for the device, we could use that to
> determine the worthiness of entering a domain idle state. Only the
> device can tell us when the future event would be and that could change
> as the usecase changes. Like, when the panel refresh rate increases to
> 120 Hz. If this information was made available to runtime PM, we could
> use that in the domain governor to determine a suitable idle state. This
> is the idea behind these patches.
>
> Would appreciate your thoughts on this.
>
> Thanks,
> Lina
>
> [1].
> https://lore.kernel.org/linux-pm/010101746eccb270-05beb27f-e1e4-40eb-92da-ad1bb48feb41-000000@us-west-2.amazonses.com/T
> /
> [2]. https://lore.kernel.org/linux-pm/20201012223400.23609-3-ilina@codeaurora.org/T/#u
> [3]. https://lore.kernel.org/linux-pm/20201015193807.17423-1-ilina@codeaurora.org/
> [4]. https://www.spinics.net/lists/linux-arm-msm/msg74322.html
> [5]. https://lore.kernel.org/linux-pm/20201106164811.3698-1-ilina@codeaurora.org/T/#t
> [6]. https://lore.kernel.org/linux-pm/20201130225039.15981-1-ilina@codeaurora.org/T/#t
> [7]. https://lore.kernel.org/linux-pm/20210113201601.14874-1-ilina@codeaurora.org/T/#t
> [8]. https://lore.kernel.org/linux-pm/20210115165004.22385-1-ilina@codeaurora.org/T/#t
>
>
> Lina Iyer (2):
>   PM / domains: inform PM domain of a device's next wakeup
>   PM / Domains: use device's next wakeup to determine domain idle state
>
>  drivers/base/power/domain.c          |  30 ++++++++
>  drivers/base/power/domain_governor.c | 102 ++++++++++++++++++++++++---
>  include/linux/pm_domain.h            |  12 ++++
>  3 files changed, 135 insertions(+), 9 deletions(-)
>
> --

Both patches applied as 5.12 material, thanks!
patchwork-bot+linux-arm-msm@kernel.org March 1, 2021, 7:59 p.m. UTC | #2
Hello:

This series was applied to qcom/linux.git (refs/heads/for-next):

On Wed, 20 Jan 2021 08:50:40 -0700 you wrote:
> Changes since v8 [8]:
> - Check if device is attached to genpd
> 
> Changes since v7 [7]:
> - Whitespace and comment fixes
> - Add Reviewed-by tags
> 
> [...]

Here is the summary with links:
  - [v9,1/2] PM / domains: inform PM domain of a device's next wakeup
    https://git.kernel.org/qcom/c/67e3242ee280
  - [v9,2/2] PM / Domains: use device's next wakeup to determine domain idle state
    https://git.kernel.org/qcom/c/c79aa080fb0f

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html