[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALHNRZ8SfAZHm5PszA0uCbr0QUYFSkdayVwEwjgRYX2JT0xhfQ@mail.gmail.com>
Date: Wed, 27 Aug 2025 00:54:41 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Mikko Perttunen <mperttunen@...dia.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 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..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/
Powered by blists - more mailing lists