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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALHNRZ_zhZ3a7h8nSWkpGv6+unKn6DkSA9tKQ6cmb5TXjGcC9w@mail.gmail.com>
Date: Wed, 17 Dec 2025 16:44:01 -0600
From: Aaron Kling <webgeek1234@...il.com>
To: Jon Hunter <jonathanh@...dia.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Rob Herring <robh@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Thierry Reding <thierry.reding@...il.com>, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc scaling

On Wed, Dec 17, 2025 at 3:53 PM Jon Hunter <jonathanh@...dia.com> wrote:
>
>
> On 17/12/2025 20:29, Aaron Kling wrote:
> > On Wed, Dec 17, 2025 at 12:59 PM Jon Hunter <jonathanh@...dia.com> 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@...il.com. And the dt
> > series, message id:
> > 20251021-tegra186-icc-p3-v3-0-68184ee8a89c@...il.com. So, my build
> > sequence is:
> >
> > git checkout next-20251217
> > b4 shazam 20251027-tegra186-icc-p2-v4-0-e4e4f57e2103@...il.com
> > b4 shazam 20251021-tegra186-icc-p3-v3-0-68184ee8a89c@...il.com
>
> 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

Okay, so. Modules are in the rootfs, none get copied to the initramfs?
And the rootfs is on nfs? And for this failure, nfs never gets
mounted. So... for this case, no modules get loaded, implying that
whatever is happening is happening with the built-in drivers. Which
means this case isn't pcie related. Are there any modifications to the
defconfig? It appears that there must be, to have dwc-eth-dwmac
available. I will see if I can trigger anything when using ethernet.

If this does eventually boot to a rootfs, as implied by the comments
about debugs below, can you check to see what emc clock speed is after
boot?

> >>> 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
>

Aaron