Re: [PATCH V2 0/6] PM / Domains: Implement domain performance states
On 17-02-17, 15:22, Kevin Hilman wrote:
> Viresh Kumar 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?
The V2 bindings were modified to take that into account:
https://marc.info/?l=linux-kernel&m=148154021427727&w=2
Copying an example from it:
+ domain_perf_state1: pstate@1 {
+ performance-level = <1>;
+ domain-microvolt = <97 975000 985000>;
+ };
The above node describes one performance state for the power domain.
This node can have any number of configurables depending on the
individual platforms. The performance-level is the integer number we
have been talking about in this series, which can be used in all the
calculations to differentiate between different levels.
The final code in the generic PM layer will end up calling
set_performance_state(performance-level); Now the drivers can go find
a corresponding node to find different configurables like
domain-microvolt, etc and configure the hardware. Or in simple cases,
like Qcom, the performance-level can be used directly without
referring to the node.
Consider the 'performance-level' field as the 'opp-hz' field in the
OPP tables which is used to distinguish lower/higher OPPs. Just that
we will not always have a frequency here and so an integer value.
> IMO, this implementation should start with a more generic approach
> (e.g. OPPs) that would be useful on more SoCs that just qcom.
I agree with that opinion. Perhaps things became a bit confusing as
the bindings were sent separately earlier and the code followed
separately. Also not everything was finished here to follow proper
bindings. Like the generic helpers weren't introduced yet to parse the
nodes like domain_perf_state1.
> For SoCs
> like QCOM, you could use dummy/simplfied OPPs that represent the integer
> values passed to the qcom firmware.
I am not sure if reusing OPPs here would be a good choice. I would
rather have separate nodes like what I defined earlier.
In the next version I will try to send all things together and try to
close all the open ends..
--
viresh
Re: [PATCH V2 0/6] PM / Domains: Implement domain performance states
Viresh Kumar 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
Re: [PATCH V2 0/6] PM / Domains: Implement domain performance states
On 17 February 2017 at 06:38, Viresh Kumar 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
Re: [PATCH V2 0/6] PM / Domains: Implement domain performance states
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. Thanks. -- viresh
