[Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU

[Jordan Crouse]

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

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project