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

[Jordan Crouse]

On Fri, Mar 09, 2018 at 03:49:00PM +0530, Rajendra Nayak wrote:
> Hey Jordan/Viresh,
> 
> On 03/09/2018 09:13 AM, 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.
> 
> What I am doing is a powerdomain driver to communicate magic values from
> CPU to rpmh, looks like we need another one to communicate from CPU to
> GMU now :)
> 
> A few things,
> * someone will need to map these larger magic values into something that
> rpmh would understand (between 0 to 15 on the sdm845), thats done by
> reading the command db level maps. Is this done by GMU?

It is done by the GPU - we take the magic values, construct them into other
magic values and send them to the GMU. As far as I know we are the only other
in-kernel client of cmd-db other than the regulator(s).

> * are these communicated just once for every OPP at init/boot, or for
> every OPP switch?

Just once at init.

> * whats the communication mechanism we use between CPU and GMU?

Shared memory queues inspired by Venus HFI.

Jordan

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