Message ID | cover.1486611268.git.viresh.kumar@linaro.org |
---|---|
Headers | show |
Series | PM / Domains: Implement domain performance states | expand |
On 17 February 2017 at 06:38, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On 09-02-17, 09:11, Viresh Kumar wrote: >> The first 5 patches update the PM domain and QoS frameworks to support >> that and the last one presents the front end interface to it. > > @Kevin and Ulf, > > Is there something wrong with this series? Its been 7 weeks since this > series is getting posted and I haven't received a single review from > you guys. We will get into the merge window very soon and then it > wouldn't be good for me to ask for reviews as everyone would be busy. > > This stuff and the rest of the development around it is getting > delayed unnecessarily. > > Please see if you guys can take some time out to get this reviewed. Apologize for the delay! I will have a look asap. Kind regards Uffe
Viresh Kumar <viresh.kumar@linaro.org> writes: > An earlier series[1] tried to implement bindings for PM domain > performance states. Rob Herring suggested that we can actually merge the > supporting code first instead of bindings, as that will make things > easier to understand for all. The bindings can be decided and merged > later. > > The bindings [1] aren't discarded yet and this series is based on a > version of those only. The bindings are only used by the last patch, > which should not be applied and is only sent for completeness. > > IOW, this series doesn't have any dependencies and can be merged > straight away without waiting for the DT bindings. > > A brief summary of the problem this series is trying to solve: > > Some platforms have the capability to configure the performance state of > their Power Domains. The performance levels are represented by positive > integer values, a lower value represents lower performance state. And what about domains where the performance levels are represented by someting other than positive integer values? IMO, this implementation should start with a more generic approach (e.g. OPPs) that would be useful on more SoCs that just qcom. For SoCs like QCOM, you could use dummy/simplfied OPPs that represent the integer values passed to the qcom firmware. > We decided earlier that we should extend Power Domain framework to > support active state power management as well. The power-domains until > now were only concentrating on the idle state management of the device > and this needs to change in order to reuse the infrastructure of power > domains for active state management. Yes. Thanks for working on it! Kevin
On 17-02-17, 15:58, Kevin Hilman wrote: > Viresh Kumar <viresh.kumar@linaro.org> writes: > > > With runtime PM, the devices get suspended while the system is up and > > running in order to save power. At such times, it is important to > > re-evaluate the required performance state of the domain, in order to > > choose a lower state if possible. > > > > This patch updates the genpd suspend/resume callbacks to do that. > > > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > Doesn't this assume that a device in the domain would need to change > performance state while runtime suspended. How would that happen? > > Rather than adding this here, I would think that drivers would instead > remove any QoS requests before going into runtime suspend, which would > trigger an update before runtime suspending. Okay, lets leave it for the drivers, at least for the time being. I will drop this patch. -- viresh