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

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

Message-ID: <2748485.BddDVKsqQX@senjougahara>
Date: Wed, 27 Aug 2025 19:16:27 +0900
From: Mikko Perttunen <mperttunen@...dia.com>
To: Aaron Kling <webgeek1234@...il.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
 Viresh Kumar <viresh.kumar@...aro.org>,
 Thierry Reding <thierry.reding@...il.com>,
 Jonathan Hunter <jonathanh@...dia.com>, Aaron Kling <luceoscutum@...il.com>,
 Sumit Gupta <sumitg@...dia.com>, Thierry Reding <treding@...dia.com>,
 linux-pm@...r.kernel.org, linux-tegra@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject:
 Re: [PATCH 2/2] cpufreq: tegra186: Initialize all cores to base frequencies

On Wednesday, August 27, 2025 2:54 PM Aaron Kling wrote:
> On Tue, Aug 26, 2025 at 9:09 PM Mikko Perttunen <mperttunen@...dia.com> 
wrote:
> > On Wednesday, August 27, 2025 5:16 AM Aaron Kling via B4 Relay wrote:
> > > From: Aaron Kling <webgeek1234@...il.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@...dia.com>
> > > Signed-off-by: Aaron Kling <webgeek1234@...il.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/