From: Mikko Perttunen <mperttunen@nvidia.com>
To: Aaron Kling <webgeek1234@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Thierry Reding <thierry.reding@gmail.com>,
Jonathan Hunter <jonathanh@nvidia.com>,
Aaron Kling <luceoscutum@gmail.com>,
Sumit Gupta <sumitg@nvidia.com>,
Thierry Reding <treding@nvidia.com>,
linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] cpufreq: tegra186: Initialize all cores to base frequencies
Date: Wed, 27 Aug 2025 19:16:27 +0900 [thread overview]
Message-ID: <2748485.BddDVKsqQX@senjougahara> (raw)
In-Reply-To: <CALHNRZ8SfAZHm5PszA0uCbr0QUYFSkdayVwEwjgRYX2JT0xhfQ@mail.gmail.com>
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/
prev parent reply other threads:[~2025-08-27 10:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-26 20:15 [PATCH 0/2] cpufreq: tegra186: Fix initialization and scaling Aaron Kling via B4 Relay
2025-08-26 20:15 ` [PATCH 1/2] cpufreq: tegra186: Set target frequency for all cpus in policy Aaron Kling via B4 Relay
2025-08-26 20:16 ` [PATCH 2/2] cpufreq: tegra186: Initialize all cores to base frequencies Aaron Kling via B4 Relay
2025-08-27 2:09 ` Mikko Perttunen
2025-08-27 5:54 ` Aaron Kling
2025-08-27 10:16 ` Mikko Perttunen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2748485.BddDVKsqQX@senjougahara \
--to=mperttunen@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=luceoscutum@gmail.com \
--cc=rafael@kernel.org \
--cc=sumitg@nvidia.com \
--cc=thierry.reding@gmail.com \
--cc=treding@nvidia.com \
--cc=viresh.kumar@linaro.org \
--cc=webgeek1234@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox