On 04/09/25 22:17, Aaron Kling wrote:

External email: Use caution opening links or attachments


On Thu, Sep 4, 2025 at 6:47 AM Sumit Gupta [off-list ref] wrote:

quoted

On 01/09/25 09:03, Aaron Kling via B4 Relay wrote:

quoted

External email: Use caution opening links or attachments


This series borrows the concept used on Tegra234 to scale EMC based on
CPU frequency and applies it to Tegra186 and Tegra194. Except that the
bpmp on those archs does not support bandwidth manager, so the scaling
iteself is handled similar to how Tegra124 currently works.

Signed-off-by: Aaron Kling <redacted>
---

Tegra186/194 had multiple drivers for BWMGR, ISOMGR and LA+PTSA configs
on the CPU side. I am not sure how effective this patch series will be
in absence
of those components. In Tegra234, those were moved to BPMP-FW. So, Kernel
forwards the BW request to BPMP (R5) who takes care of setting the final
freq.

I know it's not ideal, but it seems to be working okay as a rough
approximation. When the cpu governor kicks up the cpu freq, the emc
freq scales to match. In my testing, this has been enough to keep aosp
from obviously lagging. Existing drivers for earlier archs, such as
tegra124-emc, stub out LA+PTSA as well. Does the lack of that handling
make things worse for Tegra186/194 than it would for
Tegra124/Tegra210? I'm trying to improve things across all these archs
small pieces at time. In several of my recent series, I'm just trying
to get any form of load based dfs to work, so I don't have to keep
everything pegged to max frequency with the associated thermals and
power usage.

Aaron

I am not much familiar with the previous SoCs. But yes having some kind
of scaling is better than not having at all and running always at max. This
can be a starting point of more improvements for these SoCs in future.

Thank you,
Sumit Gupta