linux-kernel - Re: [PATCH RFC 0/7] Support Tegra210 actmon for dynamic EMC scaling

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] [day] [month] [year] [list]

Message-ID: <CALHNRZ-660RVcYLo9Pxxj9gz1s0x4nLYOSFwbtiEwSU1qbvA5Q@mail.gmail.com>
Date: Tue, 2 Sep 2025 19:55:36 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Mikko Perttunen <mperttunen@...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>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, MyungJoo Ham <myungjoo.ham@...sung.com>, 
	Kyungmin Park <kyungmin.park@...sung.com>, Chanwoo Choi <cw00.choi@...sung.com>, 
	Dmitry Osipenko <digetx@...il.com>, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-tegra@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH RFC 0/7] Support Tegra210 actmon for dynamic EMC scaling

On Tue, Sep 2, 2025 at 6:51 PM Mikko Perttunen <mperttunen@...dia.com> wrote:
>
> On Friday, August 29, 2025 1:01 PM Aaron Kling via B4 Relay wrote:
> > This series adds interconnect support to tegra210 MC and EMC, then
> > enables actmon. This enables dynamic emc scaling.
> >
> > This series is marked RFC for two reasons:
> >
> > 1) Calculating rate from bandwidth usage results in double the expected
> >    rate. I thought this might be due to the ram being 64-bit, but the
> >    related CFG5 register reports 32-bit on both p2371-2180 and
> >    p3450-0000. I'm using the calculation used for Tegra124 and haven't
> >    seen seen anything obviously different between the ram handling on
> >    these archs to cause a different result. I have considered that the
> >    number of channels might affect the reporting, and factoring in that
> >    variable does result in the correct rate, but I don't want to assume
> >    that's correct without confirmation.
>
> My thinking is also that this is due to the channels. L4T says
>
> /*
>  * Tegra11 has dual 32-bit memory channels, while
>  * Tegra12 has single 64-bit memory channel. Tegra21
>  * has either dual 32 bit channels (LP4) or a single
>  * 64 bit channel (LP3).
>  *
>  * MC effectively operates as 64-bit bus.
>  */
>
> next to calculating bw_to_freq, and proceeds to use the same divisor for T114 to T210. Regarding the CFG5_DRAM_WIDTH field, I'm guessing it gives the width for one channel, but I'm not sure how it would function for other memory types -- I'm not sure if any Tegra210 devices using memory other than LPDDR4 were ever released.

Mmm. "MC effectively operates as 64-bit bus." So I could just hardcode
64-bit dram width and skip reading the CFG5_DRAM_WIDTH field
altogether. And regardless of the layout, if I'm reading that
correctly, the calculation would remain correct. That should get the
numbers I'm expecting on the devkits, but I will verify again before
uploading a new revision.

Aaron