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

[Jordan Crouse]

On Fri, Mar 09, 2018 at 09:18:41AM -0800, Stephen Boyd wrote:
> (I wrote an email that seems to have been lost)
> 
> Quoting Jordan Crouse (2018-03-09 08:03:55)
> > On Fri, Mar 09, 2018 at 09:13:32AM +0530, Viresh Kumar wrote:
> > > On 08-03-18, 13:14, Jordan Crouse wrote:
> > > > 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
> > > 
> > > The "genpd" here is created specially for this RPM. The performance-state thing
> > > is designed to solve this very specific problem of qualcomm SoCs and there is no
> > > way we are going to add another property for this now.
> > > 
> > > > 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.
> > > 
> > > There is some WIP stuff here Rajendra is testing currently.
> > > 
> > > ssh://git@git.linaro.org/people/viresh.kumar/mylinux.git opp/genpd/qcom
> > > 
> > > Please have a talk with Rajendra who can help you understand on how this can be
> > > used for GPUs.
> > 
> > I don't think we are understanding each other. The GMU is a separate
> > microcontroller. It is given a magic number (actually a combination of magic
> > numbers) that it then uses to directly interact with the other hardware to make
> > the vote. The only responsibility that the CPU has is to construct that magic
> > number (once, at init) and send it across when asked.
> > 
> > Looking at the sdhc code from the testing tree it makes perfect sense
> > that you have a device that needs to eventually do a RPMh vote from the CPU and
> > so the 'required-opp' and performance state come together to do the right thing.
> > This is good code.
> > 
> > None of this is true for the GPU. The CPU never votes for the GPU so there 
> > isn't any need to connect it to the power domain drivers. Even if you did
> > there isn't any current mechanism for the rpmpd driver to pass the right magic
> > number to the GPU driver which is what it really needs.
> > 
> > I suppose that instead of using 'qcom,arc-level' we could use 'qcom-corner' but
> > then thats just a naming dispute. We still need a way for the GPU to query the
> > magic values.
> > 
> 
> Agreed. Forcing genpd and set_performance_state APIs on GMU doesn't make
> any sense if the GMU is doing it all itself.
> 
> The binding should be the same between sdhc and GMU if they're actually
> talking about the same thing though. I think they are, because I suspect
> GMU needs to translate the human reasonable value of qcom,corner into
> the hardware qcom,arc-level value to write into it's hardware so the GMU
> can auto-transition performance states. If I'm wrong, then
> qcom,arc-level needs to be created alongside of qcom,corner because
> they're different number spaces.

I think the value that we're discussing here is the RPMh voltage level which we
translate into the qcom,arc-level(s). I'm not sure how that matches up with
qcom,corner.

> BTW, it's qcom,corner and not qcom-corner right?

http://git.linaro.org/people/viresh.kumar/mylinux.git/commit/?h=opp/genpd/qcom&id=7586600b3bf3f8e79ce9198922fad7d4aa5b3f8d

+					qcom-corner = <1>;

shrug?

Jordan

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