On 27 October 2016 at 05:46, Viresh Kumar viresh.kumar@linaro.org wrote:
On 26-10-16, 12:00, Kevin Hilman wrote:
Yes. As I've suggested to qcom/linaro folks (off-list discussions), I
No one told me this story :)
think extending genpd to handle performance states is a logical extension. Otherwise, you will be (re)inventing something that looks an awful lot like genpd anyways.
I completely agree. Runtime PM and genpd look to be the perfect placeholder for such stuff. I actually tried to convince Ulf yesterday on this and he wasn't sure if it will ever get accepted upstream and that's when I started this thread :)
The other related framework is per-device PM QoS which could be used to set constraints on specific devices, and the genpd governors would then be responsible for looking at the constraints and changing states as needed.
I am not sure if genpd governors are also background governors like cpufreq, but we need to make sure that the voltage is raised after the function requesting a change returns, so that the clk rate can be increased then.
The M3 core takes only care of the voltage but not the clock ?
Just to be sure to understand the problem: -There is no real voltage value but instead an opaque index that has to be used with frequency instead of a voltage. -This index is used by the M3 core to set voltages but M3 core doesn't set the clock which is managed by Linux. -The M3 core takes only one index input for the whole voltage domain and Linux must aggregate the constraints (with probably a max policy) of all devices that belong this domain
Am i missing something ?
Vincent
-- viresh