Re: [PATCH RFC 24/24] arm64: dts: qcom: x1e80100: Describe GPU_CC power plumbing requirements

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 7/28/25 7:10 PM, Stephan Gerhold wrote:
> On Mon, Jul 28, 2025 at 06:16:24PM +0200, Konrad Dybcio wrote:
>> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> A number of power rails must be powered on in order for GPU_CC to
>> function. Ensure that's conveyed to the OS.
>>
>> Fixes: 721e38301b79 ("arm64: dts: qcom: x1e80100: Add gpu support")
>> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/x1e80100.dtsi | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>> index 5e9a8fa3cf96468b12775f91192cbd779d5ce946..6620517fbb0f3ed715c4901ec53dcbc6235be88f 100644
>> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
>> @@ -3928,6 +3928,12 @@ gpucc: clock-controller@3d90000 {
>>  			clocks = <&bi_tcxo_div2>,
>>  				 <&gcc GCC_GPU_GPLL0_CPH_CLK_SRC>,
>>  				 <&gcc GCC_GPU_GPLL0_DIV_CPH_CLK_SRC>;
>> +
>> +			power-domains = <&rpmhpd RPMHPD_CX>,
>> +					<&rpmhpd RPMHPD_MX>,
>> +					<&rpmhpd RPMHPD_GFX>,
>> +					<&rpmhpd RPMHPD_GMXC>;
>> +
>>  			#clock-cells = <1>;
>>  			#reset-cells = <1>;
>>  			#power-domain-cells = <1>;
>>
> 
> To repeat your own message from a couple of months back [1]:
> 
>> You shouldn't be messing with VDD_GFX on platforms with a GMU.
>>
>> Parts of the clock controller are backed by one of the MX rails,
>> with some logic depending on CX/GFX, but handling of the latter is
>> fully deferred to the GMU firmware.
>>
>> Konrad
> 
> Please describe somewhere in the cover letter or the individual patches
> how this relates to the responsibilities of the GMU. I searched for
> "GMU" in the patch series and couldn't find any note about this.
> 
> Also: How much is a plain "power on" votes (without a corresponding
> "required-opps") really worth nowadays? An arbitrary low voltage level
> on those rails won't be sufficient to make the GPU_CC actually
> "function". Do you need "required-opps" here? In the videocc/camcc case
> we have those.

Right, I failed to capture this.

The GFX rail should be powered on before unclamping the GX_GDSC (as
per the programming guide). The clock controller HPG however doesn't
seem to have a concept of RPMh, so it says something that amounts to
"tell the PMIC to supply power on this rail". In Linux, since Commit
e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the
domain") we don't really need a defined level for this (perhaps it's
more ""portable"" across potential fuse-bins if we don't hardcode the
lowest level anyway?).

However after that happens, the level scaling is done by the GMU
firmware. This holds for allOf CX/MX/GFX. I'm not super sure if
both MX and (G)MXC need to both be captured together - downstream
seems to describe MXC as a child of MX (in socname-regulators.dtsi),
but I'm not really sure this is true in hardware.

The GPU driver currently first enables the GX_GDSC and only then
does it kickstart the GMU firmware. Downstream seems to do that as
well. So on a second thought, since we've not seen any errors so
far, it calls into question what role the GFX rail plays in the
GX_GDSC's powering up..

Furthermore, this assumes that the OS is aware when the GPU is in
use, meaning VDD_GFX would be on when GPU(_CC) would be resumed, but
with IFPC or hwsched, we have 2 corner cases:

1) GPU is on but the OS doesn't know that
   (which is fine because by the time the GPU is on, the GMU has
   taken over)

2) GPU wants to be off, but the OS holds an RPMh vote

I *think* 2 shouldn't be an issue either, as downstream does
precisely this, and if it turns out to be a problem down the line,
it'd still be something to sort out on the C side.

LMK your thoughts

Konrad