[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aff97e62-03c8-416a-842c-bf8ebd8cb578@kernel.org>
Date: Wed, 12 Nov 2025 08:26:04 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Aaron Kling <webgeek1234@...il.com>, Jon Hunter <jonathanh@...dia.com>
Cc: 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 12/11/2025 00:17, Aaron Kling wrote:
>>
>> The actual rate that is set is 408MHz if I read the rate after
>> it is set ...
>>
>> [ 13.912099] tegra186_emc_icc_set_bw-362: rate 408000000
>>
>> This is a simple boot test and so nothing we are doing via
>> debugfs/sysfs to influence this.
>
> 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
If this depends on DT changes then it is obvious ABI break. Nothing in
commit msgs explained ABI impact.
> 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.
>
> Aaron
Best regards,
Krzysztof
Powered by blists - more mailing lists