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

[Jon Hunter]

On 17/12/2025 20:29, Aaron Kling wrote:
> On Wed, Dec 17, 2025 at 12:59 PM Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
> > On 17/12/2025 18:39, Aaron Kling wrote:
> >
> > ...
> >
> > > To try to move a resolution along, let me try to enumerate the issues
> > > again. Again, please clarify should I have something incorrect or
> > > incomplete.
> > >
> > > 1) The primary issue is when an old dtb is used with this commit and
> > > the pcie driver is loaded. I can reproduce this issue on t186 and
> > > t194. If this becomes the sole remaining blocking issue, I would like
> > > for an exception to the normal rule be considered and this merged
> > > anyways. Since it does not cause a boot failure and distros package a
> > > new dt normally anyways. And to my knowledge, working around this
> > > would involve redoing part off the icc subsystem itself, a major task
> > > in comparison.
> > >
> > > 2) T194 is reported to have low clocks even with a new dt on the
> > > Nvidia regression bench. I cannot reproduce this, even with the pcie
> > > driver loaded. Can this be re-verified, please? And if it still
> > > happens, can logs from the failure be made available and/or more
> > > information provided as to the state of the unit? Like changes to the
> > > default defconfig, modules that get loaded, etc.
> >
> > Can you list all the patches that need to be applied on top of the
> > current -next and I will run it through our testing to make sure I have
> > this correct.
>
> This series, message id:
> 20251027-tegra186-icc-p2-v4-0-e4e4f57e2103@xxxxxxxxx. And the dt
> series, message id:
> 20251021-tegra186-icc-p3-v3-0-68184ee8a89c@xxxxxxxxx. So, my build
> sequence is:
>
> git checkout next-20251217
> b4 shazam 20251027-tegra186-icc-p2-v4-0-e4e4f57e2103@xxxxxxxxx
> b4 shazam 20251021-tegra186-icc-p3-v3-0-68184ee8a89c@xxxxxxxxx

Thanks I added all these on top of next-20251216 (as that is the latest 
I have tested) and Tegra194 fails to boot. We always include all the 
modules in the rootfs that is being tested. You can see the boot log 
here [0]. We are using an NFS rootfs for testing and I see a message 
related to the NFS server not responding. I am guessing something is 
running too slow again because the only thing I changed was adding your 
patches. The test harness reports it is timing out ...

FAILED: Linux Boot Test 1
	Test Owner(s): N/A
	Execution Time 219.31 sec
	Test TIMEOUT reached. Test did not report results in 120 secs
	Percent passed so far: 0.0

> > > 3) Setting the max clock via debugfs fails when icc has pushed the
> > > current clock higher than the requested rate. This is a logic issue
> > > with all tegra emc drivers that implement dfs via icc. The suggested
> > > resolutions are to leave this as is to keep consistency with the
> > > existing drivers, perhaps updating all later, or to update the
> > > existing implementations in a separate series, then send a new
> > > revision here to match. I am personally unable to verify anything
> > > older than tegra124, however.
> >
> > Thierry and I chatted about this last week and we feel that debugfs
> > should be able to override the current configuration. So this will need
> > to be addressed as well.
>
> Alright. I will start looking at getting that logic straight, then
> upload a new series for the older archs and a new revision of this.

And just to confirm the test that sets the EMC frequency via the debugfs 
also still fails.

Jon

[0] https://pastebin.com/5ghbSsu7

--
nvpublic