Re: [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc scaling

[Jon Hunter]

On 11/11/2025 11:16, Krzysztof Kozlowski wrote:
> On 11/11/2025 12:13, Jon Hunter wrote:
> > > > > > +
> > > > > >         if (tegra_bpmp_mrq_is_supported(emc->bpmp, MRQ_EMC_DVFS_LATENCY)) {
> > > > > >                 err = tegra186_emc_get_emc_dvfs_latency(emc);
> > > > > >                 if (err)
> > > > >
> > > > >
> > > > > FYI, this patch is causing a boot regression on Tegra194 devices. I
> > > > > noticed that tegra194-p2972-0000 and tegra194-p3509-0000+p3668-0000 are
> > > > > no longer booting and bisect is pointing to this. I will have a closer
> > > > > look and try to see why this is.
> > > >
> > > > Interesting. Both were booting for me during my verification, though
> > > > my use case involves the dt changes that I don't believe have been
> > > > picked up yet. Thought I had explicitly verified without the dt
> > > > changes too, though. Since I was asked to do so on this or one of the
> > > > other similar series. I will try to check linux-next as-is soon.
> > >
> > > I just built next-20251110 using the standard arm64 defconfig and
> > > flashed the resulting Image and dtb's to p2972 and p3518 (p3509+p3668)
> > > and both booted to cli on a barebones busybox ramdisk. I do not see
> > > any errors from tegra-mc, and the only error I see from tegra186-emc
> > > is that it can't find the opp tables, which is expected without the dt
> > > changes, and is not fatal.
> >
> > Thanks for testing. Something is not right because our boards are
> > failing. So may be we are doing/testing something different. However,
> > this should not break. So there is a problem here.
>
>
> Did you meant: "So there is NO problem here"?

Nope. I mean that this is a problem here.

> I kept these for 10 days in linux-next and yesterday sent them in pull
> request. If some patches are needed on top, they can still fit coming
> merge window if sent soon.

Looking back I see it started failing with next-20251103. next-20251031 
was fine. Reverting this commit on top of next-20251110 fixes the issue.

There may be a difference in the firmware being used. Our testing is 
based upon an older NVIDIA L4T r32.5.1 release but nonetheless, we 
should not break that.

Jon
--
nvpublic