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.1On 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
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/
© 2016 - 2025 Red Hat, Inc.