Re: [PATCH] arm64: dts: imx95: Use GPU_CGC as core clock for GPU

[Marek Vasut <marek.vasut@mailbox.org>]

On 12/3/25 3:48 AM, Rain Yang wrote:

Hello Rain,

>> diff --git a/arch/arm64/boot/dts/freescale/imx95-clock.h b/arch/arm64/boot/dts/freescale/imx95-clock.h
>> index e1f91203e7947..22311612e4403 100644
>> --- a/arch/arm64/boot/dts/freescale/imx95-clock.h
>> +++ b/arch/arm64/boot/dts/freescale/imx95-clock.h
>> @@ -183,5 +183,6 @@
>> #define IMX95_CLK_SEL_A55P                 (IMX95_CCM_NUM_CLK_SRC + 123 + 7)
>> #define IMX95_CLK_SEL_DRAM                 (IMX95_CCM_NUM_CLK_SRC + 123 + 8)
>> #define IMX95_CLK_SEL_TEMPSENSE            (IMX95_CCM_NUM_CLK_SRC + 123 + 9)
>> +#define IMX95_CLK_GPU_CGC                  (IMX95_CCM_NUM_CLK_SRC + 123 + 10)
>>
>> #endif	/* __CLOCK_IMX95_H */
>> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
>> index 6091c2713fa48..47f20e501315f 100644
>> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
>> @@ -2874,7 +2874,7 @@ netc_emdio: mdio@0,0 {
>> 		gpu: gpu@4d900000 {
>> 			compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
>> 			reg = <0 0x4d900000 0 0x480000>;
>> -			clocks = <&scmi_clk IMX95_CLK_GPU>, <&scmi_clk IMX95_CLK_GPUAPB>;
>> +			clocks = <&scmi_clk IMX95_CLK_GPU_CGC>, <&scmi_clk IMX95_CLK_GPUAPB>;
>> 			clock-names = "core", "coregroup";
>> 			interrupts = <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
>> 				     <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>,
>> -- 
>> 2.51.0
>>
> Hi Marek,
> 
> Thanks for integrating this downstream patch.

Which downstream patch do you refer to ?

> Please note that CLK_GPUAPB and CLK_GPU are
> always-on, so the commit message should be amended accordingly.

The GPU clock do not seem to be always-on, neither do the GPUAPB . It 
seems the SM can turn those clock off perfectly well.

> Additionally, the IMX95_CLK_GPUAPB handle shall be removed, as there is no valid OPP entry
> in the frequency table, this also helps minimize differences between downstream and upstream,
> reducing maintenance effort.

Downstream kernel forks are not relevant to this discussion, upstream 
your content and then you won't have to spend maintenance effort on 
downstream stuff.