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

[Jon Hunter <jonathanh@nvidia.com>]

On 12/11/2025 11:42, Krzysztof Kozlowski wrote:
> On 12/11/2025 11:59, Jon Hunter wrote:
>>
>> On 12/11/2025 07:26, Krzysztof Kozlowski wrote:
>>> On 12/11/2025 07:18, Jon Hunter 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
>>>
>>> It's still breaking all the users then.
>>
>> Yes indeed.
> 
> 
> Please test if dropping sync_state from memory controller drivers helps
> you. This might be the easiest fix and it is also known solution when
> there are no users.

I had a quick look, but I believe that sync_state was first added for 
Tegra234 devices. The current issue is with Tegra194, so I am not sure 
we can simply drop it.

Jon

-- 
nvpublic