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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 21/11/2025 12:21, Jon Hunter wrote:
> 
> On 12/11/2025 07:21, Aaron Kling wrote:
>> On Wed, Nov 12, 2025 at 12:18 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>>>
>>>
>>> On 11/11/2025 23:17, Aaron Kling wrote:
>>>
>>> ...
>>>
>>>> Alright, I think I've got the picture of what's going on now. The
>>>> standard arm64 defconfig enables the t194 pcie driver as a module. And
>>>> my simple busybox ramdisk that I use for mainline regression testing
>>>> isn't loading any modules. If I set the pcie driver to built-in, I
>>>> replicate the issue. And I don't see the issue on my normal use case,
>>>> because I have the dt changes as well.
>>>>
>>>> So it appears that the pcie driver submits icc bandwidth. And without
>>>> cpufreq submitting bandwidth as well, the emc driver gets a very low
>>>> number and thus sets a very low emc freq. The question becomes... what
>>>> to do about it? If the related dt changes were submitted to
>>>> linux-next, everything should fall into place. And I'm not sure where
>>>> this falls on the severity scale since it doesn't full out break boot
>>>> or prevent operation.
>>>
>>> Where are the related DT changes? If we can get these into -next and
>>> lined up to be merged for v6.19, then that is fine. However, we should
>>> not merge this for v6.19 without the DT changes.
>>
>> The dt changes are here [0].
> 
> To confirm, applying the DT changes do not fix this for me. Thierry is 
> having a look at this to see if there is a way to fix this.
> 
> BTW, I have also noticed that Thierry's memory frequency test [0] is 
> also failing on Tegra186. The test simply tries to set the frequency via 
> the sysfs and this is now failing. I am seeing ..


The pull request was not yet merged, so I can amend it. The issue was
reported 12 days ago, so if this cannot be fixed in for such time, then
it is not yet ready and I will drop the changes.

Best regards,
Krzysztof