Re: [PATCH] cpufreq: tegra186: Default divider to 35 if register read fails

[Aaron Kling]

On Mon, Aug 25, 2025 at 11:48 PM Mikko Perttunen <mperttunen@xxxxxxxxxx> wrote:
>
> On Monday, August 25, 2025 2:08 PM Aaron Kling wrote:
> > On Mon, Aug 25, 2025 at 12:03 AM Aaron Kling via B4 Relay
> >
> > <devnull+webgeek1234.gmail.com@xxxxxxxxxx> wrote:
> > > From: Aaron Kling <webgeek1234@xxxxxxxxx>
> > >
> > > Several of the cores fail to read any registers and thus fail to
> > > initialize cpufreq. With shared policies, this only affects the Denver
>
> By failing to read any registers, do you just mean that they read as 0?

Yes, that is correct.

> I suspect the issue may be that the EDVD_COREx_VOLT_FREQ registers are just
> used to request VF transitions. If no one has requested anything, the register
> will be at its reset value, zero.
>
> AIUI, in downstream, the driver retrieves the CPU clock rate by measuring it
> instead of calculating it from an NDIV value, hence it would not run into this
> issue. I think the conclusion would be that if the register reads as zero, we
> cannot assume any clock rate. Is it possible to tell the cpufreq framework
> that we don't know the rate and it should ask us to set the rate to something?
> Or otherwise at probe time do this by ourselves.

This is a very helpful pointer. If I initialize all cores to their
respective base frequencies during probe, the subsequent get's work as
intended. I want to do a little more verification before sending in
another patch as I also found another issue with my previous shared
policy patch. I will submit a new series once that is done, so this
patch can be abandoned.

Aaron