lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALHNRZ_-V+tQCy8k-fh7g1Q5QF6rWKtTBMK9F4Ah6M5KjaZf3g@mail.gmail.com>
Date: Thu, 4 Sep 2025 11:47:54 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Sumit Gupta <sumitg@...dia.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Rob Herring <robh@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Thierry Reding <thierry.reding@...il.com>, Jonathan Hunter <jonathanh@...dia.com>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, bbasu@...dia.com, linux-kernel@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-tegra@...r.kernel.org, 
	linux-pm@...r.kernel.org
Subject: Re: [PATCH 0/8] Support dynamic EMC frequency scaling on Tegra186/Tegra194

On Thu, Sep 4, 2025 at 6:47 AM Sumit Gupta <sumitg@...dia.com> wrote:
>
>
> On 01/09/25 09:03, Aaron Kling via B4 Relay wrote:
> > 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 <webgeek1234@...il.com>
> > ---
>
> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ