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

From: Jordan Crouse <jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: nm-l0cyMroinI0@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	rnayak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	vireshk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU
Date: Fri, 9 Mar 2018 09:03:55 -0700	[thread overview]
Message-ID: <20180309160355.GC10589@jcrouse-lnx.qualcomm.com> (raw)
In-Reply-To: <20180309034332.GO6842@vireshk-i7>

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.

Jordan
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno