On Wed, Jan 20, 2021 at 4:53 PM Lina Iyer <ilina@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/T > / > [2]. https://lore.kernel.org/linux-pm/20201012223400.23609-3-ilina@xxxxxxxxxxxxxx/T/#u > [3]. https://lore.kernel.org/linux-pm/20201015193807.17423-1-ilina@xxxxxxxxxxxxxx/ > [4]. https://www.spinics.net/lists/linux-arm-msm/msg74322.html > [5]. https://lore.kernel.org/linux-pm/20201106164811.3698-1-ilina@xxxxxxxxxxxxxx/T/#t > [6]. https://lore.kernel.org/linux-pm/20201130225039.15981-1-ilina@xxxxxxxxxxxxxx/T/#t > [7]. https://lore.kernel.org/linux-pm/20210113201601.14874-1-ilina@xxxxxxxxxxxxxx/T/#t > [8]. https://lore.kernel.org/linux-pm/20210115165004.22385-1-ilina@xxxxxxxxxxxxxx/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!
