AMD DPTCi Driver Posted For Linux To Better Enhance Ryzen Gaming Handhelds

A new Linux kernel driver proposal aims to provide better thermal and thermal management for AMD Ryzen-powered gaming handhelds, though its AI-assisted development has sparked controversy on the LKML.

Better Linux Support for Ryzen Handhelds

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.

Antheas Kapenekakis, a developer heavily involved in improving Linux drivers for various gaming handhelds, has been working on this AMD DPTCi driver to help further improve the upstream Linux kernel support for modern AMD Ryzen powered handhelds. His work has previously tackled improving Linux support for OneXPlayer devices, ASUS hardware, AYANEO, MSI Claw, and more.

What DPTCi Does

Kapenekakis explained in the patch series cover letter that 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.

AI Development Controversy

The patch series has 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 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 AGESA 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."

Testing and Future

The driver has been 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.

A rewrite is expected to clean up the code and address some AI-generated issues. But a good intent is there for the AMD DPTCi driver so hopefully it will evolve into something acceptable to the mainline kernel.