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

[Mikko Perttunen <mperttunen@nvidia.com>]

On Wednesday, September 3, 2025 3:28 PM Aaron Kling wrote:
> On Wed, Sep 3, 2025 at 12:50 AM Mikko Perttunen <mperttunen@nvidia.com> wrote:
> >
> > On Saturday, August 16, 2025 2:53 PM Aaron Kling via B4 Relay wrote:
> > > From: Aaron Kling <webgeek1234@gmail.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.

I can't see any reference to failing thermal tests. Can to point to the commit?

I looked into why this was added for porg -- it does not seem to be related to reliability, but more so consistency of performance. I don't think that's a huge concern for upstream -- though in any case we should be capping the frequency in the DFLL driver for now since we don't support dynamic thermal capping.

> 
> > 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.

The speedo values are coefficients used to calculate voltage requirements for frequency operating points. Usually that kind of stuff starts with conservative constant values that are then refined, so my assumption is that the fixed values we currently have are safe but unoptimal (at least when they get used).

> 
> Aaron