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

[Mikko Perttunen <mperttunen@nvidia.com>]

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.

I also noticed that when running on LPDDR4, the DRAM clock is actually running at 2x EMC rate. But I think this is (slightly inappropriately) papered over by the EMC driver, which actually deals in the DRAM clock rate even if the HW EMC clock might be running at half rate.

> 
> 2) I am seeing intermittent instability when transitioning to rates of
>    204 MHz or below on p2371-2180. I have noted that if the first
>    transition to such a state works, then it continues to work for the
>    rest of that boot cycle. But the kernel will often panic the first
>    time it tries to downclock. I suspect this is a pre-existing issue
>    only brought to light now because nothing would ever lower the clock
>    rate previously.

Not sure about this.

Cheers,
Mikko

> 
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
> Aaron Kling (7):
>       dt-bindings: memory: tegra210: Add memory client IDs
>       dt-bindings: devfreq: tegra30-actmon: Add Tegra124 fallback for Tegra210
>       soc: tegra: fuse: speedo-tegra210: Add soc speedo 2
>       memory: tegra210: Support interconnect framework
>       arm64: tegra: tegra210: Add actmon
>       arm64: tegra: Add interconnect properties to Tegra210 device-tree
>       arm64: tegra: Add OPP tables on Tegra210
> 
>  .../bindings/devfreq/nvidia,tegra30-actmon.yaml    |  13 +-
>  .../boot/dts/nvidia/tegra210-peripherals-opp.dtsi  | 135 ++++++++++
>  arch/arm64/boot/dts/nvidia/tegra210.dtsi           |  43 ++++
>  drivers/memory/tegra/Kconfig                       |   1 +
>  drivers/memory/tegra/tegra210-emc-core.c           | 276 ++++++++++++++++++++-
>  drivers/memory/tegra/tegra210-emc.h                |  25 ++
>  drivers/memory/tegra/tegra210.c                    |  81 ++++++
>  drivers/soc/tegra/fuse/speedo-tegra210.c           |   1 +
>  include/dt-bindings/memory/tegra210-mc.h           |  58 +++++
>  9 files changed, 626 insertions(+), 7 deletions(-)
> ---
> base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
> change-id: 20250822-t210-actmon-34904ce7ed0c
> prerequisite-change-id: 20250812-tegra210-speedo-470691e8b8cc:v1
> prerequisite-patch-id: 81859c81abbe79aed1cfbc95b4f5bcdc5637d6bd
> prerequisite-patch-id: 98bda8855bcc57c59b2231b7808d4478301afe68
> prerequisite-patch-id: 6e0b69d42ea542dc9f58b410abd5974644f75dc4
> prerequisite-patch-id: 9e3b9b2fdb8d9c2264dfa7641d1aec84fb7aedd9
> prerequisite-patch-id: ef4bcc4ddba7898b188fb3fc6e414a2662183f91
> 
> Best regards,
>