linux-kernel - Re: [PATCH 5/5] arm64: tegra: Limit max cpu frequency on P3450

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALHNRZ8pn9shfq6PdeVe+CEzbq9wu-Vv6UDvD19=MsFrZQsBKg@mail.gmail.com>
Date: Wed, 3 Sep 2025 01:28:22 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Mikko Perttunen <mperttunen@...dia.com>
Cc: Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Thierry Reding <thierry.reding@...il.com>, Jonathan Hunter <jonathanh@...dia.com>, 
	Joseph Lo <josephl@...dia.com>, Peter De Schrijver <pdeschrijver@...dia.com>, 
	Prashant Gaikwad <pgaikwad@...dia.com>, linux-clk@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Thierry Reding <treding@...dia.com>
Subject: Re: [PATCH 5/5] arm64: tegra: Limit max cpu frequency on P3450

On Wed, Sep 3, 2025 at 12:50 AM Mikko Perttunen <mperttunen@...dia.com> wrote:
>
> On Saturday, August 16, 2025 2:53 PM Aaron Kling via B4 Relay wrote:
> > From: Aaron Kling <webgeek1234@...il.com>
> >
> > P3450's cpu is only rated for 1.4 GHz while the CVB table it uses tries
> > to scale to 1.5 GHz. Set an appropriate limit on the maximum scaling
> > frequency.
>
> Looking at downstream, from what I can tell, the CPU's maximum frequency is indeed 1.55GHz under normal conditions. However, at temperatures over 90C, its voltage is limited to 1090mV. Reference:
>
> static struct dvfs_therm_limits
> tegra210_core_therm_caps_ucm2[MAX_THERMAL_LIMITS] = {
>         {86, 1090},
>         {0, 0},
> };
> (rel-32 kernel-4.9/drivers/soc/tegra/tegra210-dvfs.c)
>
> Here the throttling is set at 86C, I suppose to give some margin.
>
> 1090mV perfectly matches the 1.479GHz operating point defined in the upstream kernel. So it seems to me that rather than setting a maximum frequency, we would need temperature dependent DVFS. Or, at least as a first step, we could have the driver just always limit the maximum frequency so it fits under the thermal cap voltage -- the temperature limit is rather high, after all.
>
> If you have other information, please do tell.

I am basing on this line in the downstream porg dt repo:

nvidia,dfll-max-freq-khz = <1479000>;
(tegra-l4t-r32.7.6_good kernel-dts/tegra210-porg-p3448-common.dtsi)

Which in the downstream dfll driver limits the max frequency it will use:

        max_freq = fcpu_data->cpu_max_freq_table[speedo_id];
        if (!of_property_read_u32(pdev->dev.of_node, "nvidia,dfll-max-freq-khz",
                                  &f))
                max_freq = min(max_freq, f * 1000UL);
(tegra-l4t-r32.7.6_good drivers/clk/tegra/clk-tegra124-dfll-fcpu.c)

If I read the commit history correctly, it does appear that this limit
was set because the always-on use case was failing thermal tests. I
couldn't say if it was intentional that this throttling was applied to
all use cases or not, but that is what appears to have happened. Hence
trying to replicate here in an effort to squash stability issues.

> Incidentally, some of the CVB tables in the upstream kernel seem to ignore speedo (I assume they are conservative) while rel-32 has different tables. So the upstream kernel is probably running at slightly unnecessarily high voltages.

This is worrying as well, though most of those tables cannot currently
be used as the fuse driver never assigns those cpu speedo ids. All I
checked in this series was that the correct cpu speedo id was picked
and the appropriate CVB table was applied to p2371-2180, p3450-0000,
and p3541-0000. I haven't yet researched what the speedo values mean
and do. There's many other sku's missing as well. Such as the one's
used by the shield tv's. I have as of yet been unable to boot to
userspace on p2571-0930/1 or p2894-0050, so I haven't determined which
sku(s) are used by those to add them here. I'm in the process of
getting uart access to continue that endeavour.

Aaron