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.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
index ec0e84cb83ef9bf8f0e52e2958db33666813917c..10f878d3f50815d1f0297d15669048ab9cad73ee 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
@@ -594,6 +594,7 @@ clock@70110000 {
nvidia,droop-ctrl = <0x00000f00>;
nvidia,force-mode = <1>;
nvidia,sample-rate = <25000>;
+ nvidia,dfll-max-freq = <1479000000>;
nvidia,pwm-min-microvolts = <708000>;
nvidia,pwm-period-nanoseconds = <2500>; /* 2.5us */
--
2.50.1On 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.
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.
Cheers,
Mikko
>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
> index ec0e84cb83ef9bf8f0e52e2958db33666813917c..10f878d3f50815d1f0297d15669048ab9cad73ee 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dts
> @@ -594,6 +594,7 @@ clock@70110000 {
> nvidia,droop-ctrl = <0x00000f00>;
> nvidia,force-mode = <1>;
> nvidia,sample-rate = <25000>;
> + nvidia,dfll-max-freq = <1479000000>;
>
> nvidia,pwm-min-microvolts = <708000>;
> nvidia,pwm-period-nanoseconds = <2500>; /* 2.5us */
>
>
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.
> 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
© 2016 - 2025 Red Hat, Inc.