Linux Power Management development
 help / color / mirror / Atom feed
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/





      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