Message-ID: <0c5eddc0-8b37-4199-a8b8-f235ac3aa476@nvidia.com>
Date: Wed, 17 Dec 2025 21:53:02 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Aaron Kling <webgeek1234@...il.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 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

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

Powered by blists - more mailing lists