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

[Jon Hunter]

On 09/12/2025 05:53, Krzysztof Kozlowski wrote:
> On 09/12/2025 05:26, Aaron Kling wrote:
> > On Sat, Nov 22, 2025 at 6:01 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> > > 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@xxxxxxxxxx> 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 ..
> >
> > With this patch dropped from -next, what needs to happen to get it
> > requeued? I gave an analysis over two weeks ago and have seen no
> > response since.
>
> Hm, I did not see the root cause identified, so maybe I missed something.
>
> Anyway, I am waiting for the patchset to be retested and resent. And
> testing MUST include kernel development process rules, including how
> patches are taken - see maintainer soc profile. Any dependencies must be
> clearly marked.

Yes me too. I am happy to re-test any updates.

Jon

--
nvpublic