[PATCH 0/2] cpufreq: tegra186: Fix initialization and scaling

[PATCH 0/2] cpufreq: tegra186: Fix initialization and scaling

[Aaron Kling via B4 Relay]

This series fixes an issue with shared policy per cluster not scaling
all cpus and with some cores being initialized by the subsystem.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Aaron Kling (2):
      cpufreq: tegra186: Set target frequency for all cpus in policy
      cpufreq: tegra186: Initialize all cores to base frequencies

 drivers/cpufreq/tegra186-cpufreq.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)
---
base-commit: 1b237f190eb3d36f52dffe07a40b5eb210280e00
change-id: 20250826-tegra186-cpufreq-fixes-7fbff81c68a2

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

[PATCH 1/2] cpufreq: tegra186: Set target frequency for all cpus in policy

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

The original commit set all cores in a cluster to a shared policy, but
did not update set_target to apply a frequency change to all cores for
the policy. This caused most cores to remain stuck at their boot
frequency.

Fixes: be4ae8c19492 ("cpufreq: tegra186: Share policy per cluster")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 drivers/cpufreq/tegra186-cpufreq.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/tegra186-cpufreq.c b/drivers/cpufreq/tegra186-cpufreq.c
index cbabb726c6645d2e5f1857a47e5643c8552d1933..6c394b429b6182faffabf222e5af501393dbbba9 100644
--- a/drivers/cpufreq/tegra186-cpufreq.c
+++ b/drivers/cpufreq/tegra186-cpufreq.c
@@ -93,10 +93,14 @@ static int tegra186_cpufreq_set_target(struct cpufreq_policy *policy,
 {
 	struct tegra186_cpufreq_data *data = cpufreq_get_driver_data();
 	struct cpufreq_frequency_table *tbl = policy->freq_table + index;
-	unsigned int edvd_offset = data->cpus[policy->cpu].edvd_offset;
+	unsigned int edvd_offset;
 	u32 edvd_val = tbl->driver_data;
+	u32 cpu;
 
-	writel(edvd_val, data->regs + edvd_offset);
+	for_each_cpu(cpu, policy->cpus) {
+		edvd_offset = data->cpus[cpu].edvd_offset;
+		writel(edvd_val, data->regs + edvd_offset);
+	}
 
 	return 0;
 }

-- 
2.50.1

[PATCH 2/2] cpufreq: tegra186: Initialize all cores to base frequencies

[Aaron Kling via B4 Relay]

From: Aaron Kling <webgeek1234@gmail.com>

During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores
are still at reset values and not reflecting the actual frequency. This
causes get calls to fail. Set all cores to their respective base
frequency during probe to initialize the registers to working values.

Suggested-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
 drivers/cpufreq/tegra186-cpufreq.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/tegra186-cpufreq.c b/drivers/cpufreq/tegra186-cpufreq.c
index 6c394b429b6182faffabf222e5af501393dbbba9..ef288705f00b0918d0f8963ef9cc9fc53be88091 100644
--- a/drivers/cpufreq/tegra186-cpufreq.c
+++ b/drivers/cpufreq/tegra186-cpufreq.c
@@ -229,7 +229,8 @@ static int tegra186_cpufreq_probe(struct platform_device *pdev)
 {
 	struct tegra186_cpufreq_data *data;
 	struct tegra_bpmp *bpmp;
-	unsigned int i = 0, err;
+	unsigned int i = 0, err, edvd_offset;
+	u32 edvd_val, cpu;
 
 	data = devm_kzalloc(&pdev->dev,
 			    struct_size(data, clusters, TEGRA186_NUM_CLUSTERS),
@@ -257,6 +258,14 @@ static int tegra186_cpufreq_probe(struct platform_device *pdev)
 			err = PTR_ERR(cluster->table);
 			goto put_bpmp;
 		}
+
+		for (cpu = 0; cpu < ARRAY_SIZE(tegra186_cpus); cpu++) {
+			if (data->cpus[cpu].bpmp_cluster_id == i) {
+				edvd_val = cluster->table[0].driver_data;
+				edvd_offset = data->cpus[cpu].edvd_offset;
+				writel(edvd_val, data->regs + edvd_offset);
+			}
+		}
 	}
 
 	tegra186_cpufreq_driver.driver_data = data;

-- 
2.50.1

Re: [PATCH 2/2] cpufreq: tegra186: Initialize all cores to base frequencies

[Mikko Perttunen]

On Wednesday, August 27, 2025 5:16 AM Aaron Kling via B4 Relay wrote:
> From: Aaron Kling <webgeek1234@gmail.com>
> 
> During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores
> are still at reset values and not reflecting the actual frequency. This
> causes get calls to fail. Set all cores to their respective base
> frequency during probe to initialize the registers to working values.
> 
> Suggested-by: Mikko Perttunen <mperttunen@nvidia.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
>  drivers/cpufreq/tegra186-cpufreq.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/tegra186-cpufreq.c
> b/drivers/cpufreq/tegra186-cpufreq.c index
> 6c394b429b6182faffabf222e5af501393dbbba9..ef288705f00b0918d0f8963ef9cc9fc53
> be88091 100644 --- a/drivers/cpufreq/tegra186-cpufreq.c
> +++ b/drivers/cpufreq/tegra186-cpufreq.c
> @@ -229,7 +229,8 @@ static int tegra186_cpufreq_probe(struct platform_device
> *pdev) {
>  	struct tegra186_cpufreq_data *data;
>  	struct tegra_bpmp *bpmp;
> -	unsigned int i = 0, err;
> +	unsigned int i = 0, err, edvd_offset;
> +	u32 edvd_val, cpu;
> 
>  	data = devm_kzalloc(&pdev->dev,
>  			    struct_size(data, clusters, 
TEGRA186_NUM_CLUSTERS),
> @@ -257,6 +258,14 @@ static int tegra186_cpufreq_probe(struct
> platform_device *pdev) err = PTR_ERR(cluster->table);
>  			goto put_bpmp;
>  		}
> +
> +		for (cpu = 0; cpu < ARRAY_SIZE(tegra186_cpus); cpu++) {
> +			if (data->cpus[cpu].bpmp_cluster_id == i) {
> +				edvd_val = cluster->table[0].driver_data;
> +				edvd_offset = data->cpus[cpu].edvd_offset;
> +				writel(edvd_val, data->regs + 
edvd_offset);
> +			}
> +		}
>  	}
> 
>  	tegra186_cpufreq_driver.driver_data = data;

Looks OK, but I think it might be better to set the frequency to Fmax instead 
of Fmin to avoid any slowdown during boot.

Cheers,
Mikko

Re: [PATCH 2/2] cpufreq: tegra186: Initialize all cores to base frequencies

[Aaron Kling]

On Tue, Aug 26, 2025 at 9:09 PM Mikko Perttunen <mperttunen@nvidia.com> wrote:
>
> On Wednesday, August 27, 2025 5:16 AM Aaron Kling via B4 Relay wrote:
> > From: Aaron Kling <webgeek1234@gmail.com>
> >
> > During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores
> > are still at reset values and not reflecting the actual frequency. This
> > causes get calls to fail. Set all cores to their respective base
> > frequency during probe to initialize the registers to working values.
> >
> > Suggested-by: Mikko Perttunen <mperttunen@nvidia.com>
> > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > ---
> >  drivers/cpufreq/tegra186-cpufreq.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/tegra186-cpufreq.c
> > b/drivers/cpufreq/tegra186-cpufreq.c index
> > 6c394b429b6182faffabf222e5af501393dbbba9..ef288705f00b0918d0f8963ef9cc9fc53
> > be88091 100644 --- a/drivers/cpufreq/tegra186-cpufreq.c
> > +++ b/drivers/cpufreq/tegra186-cpufreq.c
> > @@ -229,7 +229,8 @@ static int tegra186_cpufreq_probe(struct platform_device
> > *pdev) {
> >       struct tegra186_cpufreq_data *data;
> >       struct tegra_bpmp *bpmp;
> > -     unsigned int i = 0, err;
> > +     unsigned int i = 0, err, edvd_offset;
> > +     u32 edvd_val, cpu;
> >
> >       data = devm_kzalloc(&pdev->dev,
> >                           struct_size(data, clusters,
> TEGRA186_NUM_CLUSTERS),
> > @@ -257,6 +258,14 @@ static int tegra186_cpufreq_probe(struct
> > platform_device *pdev) err = PTR_ERR(cluster->table);
> >                       goto put_bpmp;
> >               }
> > +
> > +             for (cpu = 0; cpu < ARRAY_SIZE(tegra186_cpus); cpu++) {
> > +                     if (data->cpus[cpu].bpmp_cluster_id == i) {
> > +                             edvd_val = cluster->table[0].driver_data;
> > +                             edvd_offset = data->cpus[cpu].edvd_offset;
> > +                             writel(edvd_val, data->regs +
> edvd_offset);
> > +                     }
> > +             }
> >       }
> >
> >       tegra186_cpufreq_driver.driver_data = data;
>
> Looks OK, but I think it might be better to set the frequency to Fmax instead
> of Fmin to avoid any slowdown during boot.

I considered this, but I'm somewhat skittish about setting Fmax by
default due to seeing instability across different tegra archs and
finding out that the t210 devkits have been factory overclocked on
mainline for the last six years [0]. That may be less of a problem on
t186+ with the bpmp having more tight control over stuff, but... yeah,
I'm still wary. But on the other hand, I set performance governor on
boot for my android builds and have not seen any obvious cpu related
instability on p2771 or p3636+p3509, so that might be okay. If you
still think Fmax is better, I'll update and send a v2.

Aaron

[0] https://lore.kernel.org/all/20250816-tegra210-speedo-v1-0-a981360adc27@gmail.com/

Re: [PATCH 2/2] cpufreq: tegra186: Initialize all cores to base frequencies

[Mikko Perttunen]

On Wednesday, August 27, 2025 2:54 PM Aaron Kling wrote:
> On Tue, Aug 26, 2025 at 9:09 PM Mikko Perttunen <mperttunen@nvidia.com> 
wrote:
> > On Wednesday, August 27, 2025 5:16 AM Aaron Kling via B4 Relay wrote:
> > > From: Aaron Kling <webgeek1234@gmail.com>
> > > 
> > > During initialization, the EDVD_COREx_VOLT_FREQ registers for some cores
> > > are still at reset values and not reflecting the actual frequency. This
> > > causes get calls to fail. Set all cores to their respective base
> > > frequency during probe to initialize the registers to working values.
> > > 
> > > Suggested-by: Mikko Perttunen <mperttunen@nvidia.com>
> > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > ---
> > > 
> > >  drivers/cpufreq/tegra186-cpufreq.c | 11 ++++++++++-
> > >  1 file changed, 10 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/cpufreq/tegra186-cpufreq.c
> > > b/drivers/cpufreq/tegra186-cpufreq.c index
> > > 6c394b429b6182faffabf222e5af501393dbbba9..ef288705f00b0918d0f8963ef9cc9f
> > > c53
> > > be88091 100644 --- a/drivers/cpufreq/tegra186-cpufreq.c
> > > +++ b/drivers/cpufreq/tegra186-cpufreq.c
> > > @@ -229,7 +229,8 @@ static int tegra186_cpufreq_probe(struct
> > > platform_device *pdev) {
> > > 
> > >       struct tegra186_cpufreq_data *data;
> > >       struct tegra_bpmp *bpmp;
> > > 
> > > -     unsigned int i = 0, err;
> > > +     unsigned int i = 0, err, edvd_offset;
> > > +     u32 edvd_val, cpu;
> > > 
> > >       data = devm_kzalloc(&pdev->dev,
> > >       
> > >                           struct_size(data, clusters,
> > 
> > TEGRA186_NUM_CLUSTERS),
> > 
> > > @@ -257,6 +258,14 @@ static int tegra186_cpufreq_probe(struct
> > > platform_device *pdev) err = PTR_ERR(cluster->table);
> > > 
> > >                       goto put_bpmp;
> > >               
> > >               }
> > > 
> > > +
> > > +             for (cpu = 0; cpu < ARRAY_SIZE(tegra186_cpus); cpu++) {
> > > +                     if (data->cpus[cpu].bpmp_cluster_id == i) {
> > > +                             edvd_val = cluster->table[0].driver_data;
> > > +                             edvd_offset = data->cpus[cpu].edvd_offset;
> > > +                             writel(edvd_val, data->regs +
> > 
> > edvd_offset);
> > 
> > > +                     }
> > > +             }
> > > 
> > >       }
> > >       
> > >       tegra186_cpufreq_driver.driver_data = data;
> > 
> > Looks OK, but I think it might be better to set the frequency to Fmax
> > instead of Fmin to avoid any slowdown during boot.
> 
> I considered this, but I'm somewhat skittish about setting Fmax by
> default due to seeing instability across different tegra archs and
> finding out that the t210 devkits have been factory overclocked on
> mainline for the last six years [0]. That may be less of a problem on
> t186+ with the bpmp having more tight control over stuff, but... yeah,
> I'm still wary. But on the other hand, I set performance governor on
> boot for my android builds and have not seen any obvious cpu related
> instability on p2771 or p3636+p3509, so that might be okay. If you
> still think Fmax is better, I'll update and send a v2.

Yeah, I think it should be fine on T186. BPMP is in charge of managing the 
frequency in the end and if this causes instability it would be a bug in BPMP.

Mikko

> 
> Aaron
> 
> [0]
> https://lore.kernel.org/all/20250816-tegra210-speedo-v1-0-a981360adc27@gmai
> l.com/