devfreq: add DEVFREQ_GOVERNOR to set the governor of devfreq devices

[wxphaha]

Add new parameters DEVFREQ_GOVERNOR_ON_PRF/BAL/SAV to set the governor of devfreq devices, e.g. GPU, DDR or NoC frequency controllers such as the Phytium NoC (phytium_nocfreq driver).

The governor is applied to all /sys/class/devfreq/devfreq*/governor devices, mirroring the existing CPU scaling governor implementation. When unconfigured (default), no changes are made. A governor rejected by the kernel is reported as a configuration error.

Tested on hardware with two devfreq devices (Phytium NoC):

• tlp performance -> governor=performance
• tlp balanced -> governor=simple_ondemand
• tlp power-saver -> governor=powersave

Log: add DEVFREQ_GOVERNOR parameters for devfreq devices

[linrunner]

Hi there.

At first glance, it seems to me that the range of target hardware for this is a small niche.

In the mainline kernel, I can only find the driver for NVIDIA Tegra: https://github.com/search?q=repo%3Atorvalds%2Flinux+devfreq_governor&type=code

The Phytium NoC is not laptop hardware, nor is the phytium_nocfreq driver included in the mainline kernel (which is usually a prerequisite for a feature to be included in TLP). I can't find any information about this online at all.

So far, I don’t see your PR falling within the scope of TLP. Do you have more information?

[wxphaha]

Thanks for the thorough review and for taking the time to look into
this. I understand your concern about the scope.

To clarify the background: Phytium is a Chinese processor vendor whose
chips are widely used in desktop and laptop systems sold on the Chinese
market (both in consumer and enterprise/gov segments). Their platforms
are becoming increasingly common as general-purpose workstations, and
users do run TLP on them. The devfreq interface exposed by the
phytium_nocfreq driver covers the on-chip NoC (network-on-chip)
frequency controller, which behaves just like the existing cpufreq /
GPU frequency controls TLP already manages.

You are right, though, that phytium_nocfreq is not yet part of the
mainline kernel. I will keep track of its upstreaming progress and
re-submit this PR once the driver is merged into mainline, so it
meets the same bar as the other features in TLP.

[linrunner]

Thanks for the info. I had already suspected that there isn't much to be found on Google about recent developments in China.

I'm still unsure what role the Pythium NoC serves here. Is it just a network controller/coprocessor integrated on chip with the main CPU and/or GPU?

devfreq seems to be a universal control option for multiple hardware categories. I'm struggling to fit it into the categories established in TLP. This is significant because it helps users to find it, for example, in tlp.conf or the output of tlp-stat. Speaking of tlp-stat: we'll need something there, too. If only because the user wants to know, “Do I have this in my PC?”

[wxphaha]

Thanks for the question.

First, a note on our level of knowledge: we are not the Phytium vendor, and we only have limited visibility into the driver internals. The description below is based on what we can observe on the hardware we have (Phytium-based, UOS 25, arm64), not on vendor documentation.

About the NoC: based on the device naming (nocfreq, ACPI hardware ID PHYT0047, driver phytium_nocfreq) and the exposed sysfs interface, it appears to be a frequency controller for the on-chip interconnect (the "network-on-chip") — i.e. the internal bus fabric that connects the CPU cores, GPU and memory controller on the SoC (functionally similar to Intel's ring bus or AMD's Infinity Fabric). It is not a network controller in the NIC sense, nor a separate coprocessor; it controls the clock of the internal fabric itself.

What it does: adjusting this frequency trades power consumption against interconnect throughput. Clocking the on-chip interconnect down saves power; clocking it up helps sustained performance for traffic between CPU/GPU and memory — which is why it appears under the devfreq framework, in the same way as other device frequency controllers.

That said, since we are not the vendor and the driver is not documented publicly, please treat the above as an informed interpretation from the exposed interfaces rather than a definitive specification.

[linrunner]

Thanks for your interesting insight.