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

Aaron Kling via B4 Relay posted 7 patches 1 month ago
There is a newer version of this series
.../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(-)
[PATCH RFC 0/7] Support Tegra210 actmon for dynamic EMC scaling
Posted by Aaron Kling via B4 Relay 1 month ago
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.

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.

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,
-- 
Aaron Kling <webgeek1234@gmail.com>
Re: [PATCH RFC 0/7] Support Tegra210 actmon for dynamic EMC scaling
Posted by Mikko Perttunen 1 month ago
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,
> 
Re: [PATCH RFC 0/7] Support Tegra210 actmon for dynamic EMC scaling
Posted by Aaron Kling 1 month ago
On Tue, Sep 2, 2025 at 6:51 PM Mikko Perttunen <mperttunen@nvidia.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
Re: [PATCH RFC 0/7] Support Tegra210 actmon for dynamic EMC scaling
Posted by Rob Herring (Arm) 1 month ago
On Thu, 28 Aug 2025 23:01:26 -0500, Aaron Kling 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.
> 
> 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.
> 
> 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,
> --
> Aaron Kling <webgeek1234@gmail.com>
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: using specified base-commit 8f5ae30d69d7543eee0d70083daf4de8fe15d585
 Deps: looking for dependencies matching 5 patch-ids
 Deps: Applying prerequisite patch: [PATCH 1/5] dt-bindings: clock: tegra124-dfll: Add property to limit frequency
 Deps: Applying prerequisite patch: [PATCH 2/5] soc: tegra: fuse: speedo-tegra210: Update speedo ids
 Deps: Applying prerequisite patch: [PATCH 3/5] soc: tegra: fuse: speedo-tegra210: Add sku 0x8F
 Deps: Applying prerequisite patch: [PATCH 4/5] clk: tegra: dfll: Support limiting max clock per device
 Deps: Applying prerequisite patch: [PATCH 5/5] arm64: tegra: Limit max cpu frequency on P3450

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/nvidia/' for 20250828-t210-actmon-v1-0-aeb19ec1f244@gmail.com:

arch/arm64/boot/dts/nvidia/tegra210-p3450-0000.dtb: external-memory-controller@7001b000 (nvidia,tegra210-emc): '#cooling-cells', '#interconnect-cells', 'operating-points-v2' do not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra210-emc.yaml#
arch/arm64/boot/dts/nvidia/tegra210-p2371-0000.dtb: external-memory-controller@7001b000 (nvidia,tegra210-emc): '#cooling-cells', '#interconnect-cells', 'operating-points-v2' do not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra210-emc.yaml#
arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dtb: external-memory-controller@7001b000 (nvidia,tegra210-emc): '#cooling-cells', '#interconnect-cells', 'operating-points-v2' do not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra210-emc.yaml#
arch/arm64/boot/dts/nvidia/tegra210-smaug.dtb: external-memory-controller@7001b000 (nvidia,tegra210-emc): '#cooling-cells', '#interconnect-cells', 'operating-points-v2' do not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra210-emc.yaml#
arch/arm64/boot/dts/nvidia/tegra210-p2894-0050-a08.dtb: external-memory-controller@7001b000 (nvidia,tegra210-emc): '#cooling-cells', '#interconnect-cells', 'operating-points-v2' do not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra210-emc.yaml#
arch/arm64/boot/dts/nvidia/tegra210-p2571.dtb: external-memory-controller@7001b000 (nvidia,tegra210-emc): '#cooling-cells', '#interconnect-cells', 'operating-points-v2' do not match any of the regexes: '^pinctrl-[0-9]+$'
	from schema $id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra210-emc.yaml#