On Wed, Mar 07, 2018 at 10:36:24AM +0530, Viresh Kumar wrote:
On 06-03-18, 08:37, Jordan Crouse wrote:
I'll try to explain but I might need Stephen or some of the other folks to jump in and save me.
Maybe you should start using his kernel.org address then ? :)
On sdm845 there are shared power resources controlled by the RPMh which is programed by a series of commands from the regulator driver; but in the case of the GPU the votes are passed to the GMU (graphics management unit) which communicates with the RPMh on behalf of the GPU.
In order to construct the RPMh vote we need first need a voltage level that we can look up in a database. qcom,arc-level is the voltage level associated with a specific OPP.
I had previously been abusing this with opp-microvolt but that was wrong for obvious reasons and then Stephen pointed out that this would be a better way.
Glad that you shared that :)
A solution is already in progress for that and is partially merged as well.
Look for "performance_state" in genpd and OPP cores (already merged), followed by this series here:
https://lkml.kernel.org/r/cover.1513926033.git.viresh.kumar@linaro.org
It seems to me that performance_state has a direct relationship with genpd which is good for CPU votes but in this case, we're just passing along raw data to an independent microcontroller. The 'qcom,arc-level' is used to construct the actual values that the GMU will program into the RPMh. Since these are informational (from the CPU perspective) rather than functional I feel like that using performance_state for this would be as hacky as using opp-microvolt or something else.
Jordan