lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0355f521-e506-447f-bc6a-cf4405903cfd@mailbox.org>
Date: Mon, 5 Jan 2026 17:31:55 +0100
From: Marek Vasut <marek.vasut@...lbox.org>
To: Rain Yang <jiyu.yang@....nxp.com>
Cc: Frank.Li@....com, conor+dt@...nel.org, devicetree@...r.kernel.org,
 festevam@...il.com, imx@...ts.linux.dev, jiyu.yang@....com,
 kernel@...gutronix.de, krzk+dt@...nel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 liviu.dudau@....com, robh@...nel.org, s.hauer@...gutronix.de,
 shawnguo@...nel.org
Subject: Re: [PATCH] arm64: dts: imx95: remove CLK_GPUAPB

On 1/5/26 3:19 AM, Rain Yang wrote:
> On Fri, Jan 02, 2026 at 02:53:31PM +0100, Marek Vasut wrote:
>> On 1/2/26 11:37 AM, Rain Yang wrote:
>>> On Thu, Jan 01, 2026 at 05:51:12PM +0100, Marek Vasut wrote:
>>>> On 1/1/26 1:37 AM, Rain Yang wrote:
>>>>> On Wed, Dec 31, 2025 at 03:11:21PM +0100, Marek Vasut wrote:
>>>>>> On 12/31/25 4:19 AM, Rain Yang wrote:
>>>>>>> From: Rain Yang <jiyu.yang@....com>
>>>>>>>
>>>>>>> Dropping CLK_GPUAPB simplifies OPP handling and avoids unnecessary
>>>>>>> complexity.
>>>>>>>
>>>>>>> Fixes: 67934f248e64 ("arm64: dts: imx95: Describe Mali G310 GPU")
>>>>>>> Signed-off-by: Rain Yang <jiyu.yang@....com>
>>>>>>> ---
>>>>>>>      arch/arm64/boot/dts/freescale/imx95.dtsi | 4 ++--
>>>>>>>      1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
>>>>>>> index 88bde59e61b2..ab446aa6f73c 100644
>>>>>>> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
>>>>>>> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
>>>>>>> @@ -2164,8 +2164,8 @@ netc_emdio: mdio@0,0 {
>>>>>>>      		gpu: gpu@...00000 {
>>>>>>>      			compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
>>>>>>>      			reg = <0 0x4d900000 0 0x480000>;
>>>>>>> -			clocks = <&scmi_clk IMX95_CLK_GPU_CGC>, <&scmi_clk IMX95_CLK_GPUAPB>;
>>>>>>> -			clock-names = "core", "coregroup";
>>>>>>> +			clocks = <&scmi_clk IMX95_CLK_GPU_CGC>;
>>>>>>> +			clock-names = "core";
>>>>>>
>>>>>> I don't think this is correct, SM can disable the GPUAPB clock from the SM
>>>>>> monitor:
>>>>>>
>>>>>>> $ clock.w gpuapb off
>>>>>>
>>>>>> Linux has to make sure the GPUAPB clock are enabled to access the GPU
>>>>>> register, hence the clock have to be described in DT.
>>>>> Hi Marek,
>>>>
>>>> Hello Jiyu,
>>>>
>>>>> CLK_GPU and CLK_GPUAPB can only be controlled internally by the SM, not by Linux.
>>>>> CLK_GPUAPB always runs at a fixed frequency, does not require dynamic adjustment,
>>>>> and is practically always on.
>>>>> Additionally, CLK_GPUAPB's frequency is absent from all OPP entries. Removing it
>>>>> could simplify OPP handling logic and reduce unnecessary complexity.
>>>>
>>>> But the SM can turn the GPUAPB clock off, correct ?
>>>>
>>>> Linux has to be able to turn GPUAPB clock on, therefore the GPUAPB clock have
>>>> to be described in DT, correct ?
>>>
>>> Yes, CLK_GPUAPB can be turned off by the SM, but by default it remains on, just like
>>> CLK_GPU. AFAIK, there is no scenario where either of these clocks could or would be
>>> disabled in both SM and Linux.
>>>
>>> If enabling or disabling CLK_GPUAPB in Linux was wanted, the same shall apply to CLK_GPU
>>> to make this approach reasonable.
>>> Also, OPP framework shall be adjusted to meet these changes too.
>>
>> You can not depend on the state in which bootloader or any other prior stage
>> left the platform. If the clock can be turned off, you must make sure they
>> are turned on for correct hardware operation.
>>
>> CLK_GPU is enabled as parent clock of CLK_GPUCGC already.
> Hi Marek,
> I'm afraid it's not what you expected, the CLK_GPUCGC patch already based on the CLK_GPU is
> always-on, you can disable the CLK_GPU in SM, then run any gles application, the board will reboot.
Which kernel version are you testing ?

Also, can you share your /sys/kernel/debug/clk/clk_summary ? The clock 
relationship should be visible there.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ