# Dynamic Frequency Selection

**URL:** <https://community.solid-run.com/t/dynamic-frequency-selection/646>\
**Category:** OCTEON CN9130\
**Created:** [May 18, 2023, 7:10pm UTC](https://community.solid-run.com/t/dynamic-frequency-selection/646 "2023-05-18T19:10:02Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![mpmurphy00](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/mpmurphy00/32/133_2.png) [@mpmurphy00](https://community.solid-run.com/u/mpmurphy00)\
**Post date:** [May 18, 2023, 7:10pm UTC](https://community.solid-run.com/t/dynamic-frequency-selection/646/1 "2023-05-18T19:10:02Z")

</div>

Note: not referring here to the MPP pin sampled by hardware at reset; this is about a divide down of system clock under software control.

I’m looking into Linux “dynamic frequency selection”:  
[https://www.kernel.org/doc/Documentation/cpu-freq/](https://www.kernel.org/doc/Documentation/cpu-freq/)

The Marvell Armada CN9130 Functional Specifications document has this term, suggesting the feature exists. The kernel has \_/drivers/cpufreq/armada-8k-cpufreq.c and armada-37xx-cpufreq.c, but I’m not currently clear if either of these apply to this processor. I don’t see any setup for this in existing device tree files; by \_/Documentation/devicetree/bindings/opp/oop-v1.yaml, I would expect something which defines “operating-points” for example.

Question: what is the state of this feature for CN9130? Perhaps one of these …

- Not applicable for this processor
- The feature exists in hardware but no Linux driver currently available
- A driver in the mainline kernel can be used, if the device tree were edited to trigger it, and additional content for the device tree could be found at https://----
- A working driver exists someplace else

Hints welcomed, thanks.

---

<div class="post-metadata">

**Author:** ![jnettlet](https://dub1.discourse-cdn.com/flex005/user_avatar/community.solid-run.com/jnettlet/32/62_2.png) [@jnettlet](https://community.solid-run.com/u/jnettlet)\
**Post date:** [May 21, 2023, 7:48am UTC](https://community.solid-run.com/t/dynamic-frequency-selection/646/2 "2023-05-21T07:48:19Z")

</div>

This is currently not in mainline, but you can find the patch to enable clock scaling via the armada-8k driver in our patches here. [cn913x\_build/0013-cpufreq-armada-enable-ap807-cpu-clk.patch at master · SolidRun/cn913x\_build · GitHub](https://github.com/SolidRun/cn913x_build/blob/master/patches/linux/0013-cpufreq-armada-enable-ap807-cpu-clk.patch)

---

<div class="post-metadata">

**Author:** ![bareminimum](https://avatars.discourse-cdn.com/v4/letter/b/82dd89/32.png) [@bareminimum](https://community.solid-run.com/u/bareminimum)\
**Post date:** [May 23, 2023, 11:16am UTC](https://community.solid-run.com/t/dynamic-frequency-selection/646/3 "2023-05-23T11:16:02Z")

</div>

Since yesterday an update with a newer kernel landed with [https://github.com/SolidRun/cn913x\_build/commit/8a00da5c65ea3078c03308de904da7bebf76d203](https://github.com/SolidRun/cn913x_build/commit/8a00da5c65ea3078c03308de904da7bebf76d203), I built a new set of images to try and see what impact working `cpufreq` had.

Switching between `ondemand` and `performance` scaling governors showed only a difference of 0.05W in Idle.  
But with debian upstream kernels, the devices would regularly run into thermal shutdown after 15-20 minutes, whereas now the CPU seems to occasionally throttle at 85°C and keep the system running.
