On Thu, 3 Sep 2020 at 01:26, Lina Iyer <ilina@xxxxxxxxxxxxxx> wrote: > > 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. While striving towards entering the most optimal (energy and performance wise) idle state, I think it's an interesting approach. > > In the first patch, I am proposing an API for devices to specify their > wakeup as a time in the future and in the second patch, I am updating > the PM domain governor to use this information to determine the idle > state. I have not had a chance to test this out yet, but I wanted to > know if I am on the right track. I don't have any immediate objections - I think the approach seems reasonable. Still, my first thought that this could be an extension to the dev_pm_qos interface, but perhaps that isn't a good fit. I also have a couple of comments to the code, but I will reply to each patch separately about that. > > Would appreciate your thoughts on this. When it comes to showing real results, other than in theory, I think we need to make the genpd's cpu governor to cope with the next wakeup event as well. > > Thanks, > Lina > > > Lina Iyer (2): > PM / runtime: register device's next wakeup > PM / Domains: use device's next wakeup to determine domain idle state > > drivers/base/power/domain_governor.c | 87 ++++++++++++++++++++++++++-- > drivers/base/power/runtime.c | 31 ++++++++++ > include/linux/pm.h | 2 + > include/linux/pm_domain.h | 1 + > include/linux/pm_runtime.h | 1 + > 5 files changed, 116 insertions(+), 6 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > Kind regards Uffe
