A request for comments (RFC) patch series was posted today to the Linux kernel mailing list to introduce the AMD Dynamic Power and Thermal Configuration Interface “DPTCi” driver. With this driver it would provide better upstream Linux kernel support for tuning the power / performance / thermals of modern Ryzen-powered gaming handheld devices. Though don’t get too excited right away as the driver was assembled in part by AI that is already causing a bit of a ruckus on the LKML due to lack of disclosure.
Antheas Kapenekakis is the developer who has been heavily involved on improving various Linux drivers for different gaming handhelds. He’s tackled improving the Linux support for OneXPlayer devices, ASUS hardware, AYANEO, MSI Claw, and more. Now he’s been working on writing this AMD DPTCi driver to help further improve the upstream Linux kernel support for the modern AMD Ryzen powered handhelds.
Kapenekakis explained in the patch series cover letter:
“Many AMD-based handheld PCs (GPD, AYANEO, OneXPlayer, AOKZOE, OrangePi) ship with the AGESA ALIB method at _SB.ALIB, which accepts Function 0x0C (the Dynamic Power and Thermal Configuration Interface, DPTCi). This allows software to adjust APU power and thermal parameters at runtime: STAPM limit, fast/slow PPT limits, skin-temperature TDP limit, slow/STAPM time constants, and the thermal control target.
Until now userspace has reached this interface through the acpi_call out-of-tree module or ryzenadj, which carry no ABI guarantees and no per-device safety limits. This driver replaces that with a proper in-kernel implementation that:
* Exposes all seven parameters through the firmware-attributes sysfs ABI, so that standard tools (fwupd, systemd-bios-vendor, etc.) can enumerate and modify them without device-specific knowledge.
* Enforces tiered per-device and per-SoC limits. The default “device” mode restricts writes to a curated safe range (smin..smax) derived from the device’s thermal design. An “expanded” mode exposes the full hardware-validated range. An optional CONFIG_AMD_DPTC_EXTENDED Kconfig adds “soc” (raw ALIB_PARAMS envelope) and “unbound” tiers for advanced use. The active tier is itself a firmware-attribute, switchable at runtime.
* Stages values and commits them atomically in a single ALIB call, matching the protocol’s intended bulk-update semantics. A save_settings attribute (per firmware-attributes ABI) controls whether writes commit immediately (“single” mode) or are held until an explicit “save”.
* When in “single” mode, re-applies staged values after system resume, so suspend/resume cycles do not silently revert to firmware defaults.
Device limits are supplied for GPD Win Mini / Win 4 / Win 5 / Win Max 2 / Duo / Pocket 4, OrangePi NEO-01, AOKZOE A1/A2, OneXPlayer F1/2/X1/G1, and numerous AYANEO models. The SoC table covers Ryzen 5000, 6000, 7040, 8000, Z1, AI 9 HX 370, and the Ryzen AI MAX series.
Tested on a GPD Win 5 (Ryzen AI MAX+ 395). Confirmed with ryzenadj -i that committed values are applied to hardware, and that fast/slow PPT limits are honoured under a full-CPU stress load.”
Basically this AMD DPTCi driver will allow for nicer mainline kernel support for having more thermal and power limit tuning controls in real-time.
The RFC patch series has this initial proposed AMD Dynamic Power and Thermal Configuration Interface driver code.
This patch series has also turned up a bit of a snafu due to AI… It turns out that this driver was built in part by AI. And that fact wasn’t disclosed straight-up in the original patches. During the code review when questioning what is “systemd-bios-vendor”, Kapenekakis acknowledged:
“I used some AI assistance to compile this from my userspace implementation and the ASEGA pdf from the AMD site. I need to go through _everything_ before this moves to non-RFC. Same with copyright year. I focused on the implementation doing the things I want it to do for now.”
With this driver being developed externally from AMD, it also relies on magic numbers obtained from various sources:
“Trial and error, research, references from Windows, etc. All of the devices in this driver have been tested with a userspace implementation using the same limits for ppt/sppt/fppt.”
So a rewrite is expected to clean up the code and addressing some AI slop. But a good intent is there for the AMD DPTCi driver so hopefully it will evolve into something acceptable to the mainline kernel.
