AMD DPTCi Driver Posted For Linux To Higher Improve Ryzen Gaming Handhelds

A request for feedback (RFC) patch collection was posted as we speak to the Linux kernel mailing record to introduce the AMD Dynamic Power and Thermal Configuration Interface “DPTCi” driver. With this driver it could present higher upstream Linux kernel assist for tuning the ability / efficiency / thermals of contemporary Ryzen-powered gaming handheld gadgets. Though do not get too excited instantly as the driving force was assembled partially by AI that’s already inflicting a little bit of a ruckus on the LKML resulting from lack of disclosure.

Antheas Kapenekakis is the developer who has been closely concerned on enhancing varied Linux drivers for various gaming handhelds. He’s tackled enhancing the Linux assist for OneXPlayer gadgets, ASUS {hardware}, AYANEO, MSI Claw, and extra. Now he is been engaged on penning this AMD DPTCi driver to assist additional enhance the upstream Linux kernel assist for the trendy AMD Ryzen powered handhelds.

Kapenekakis defined within the patch collection cowl 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 “gadget” 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 permit for nicer mainline kernel assist for having extra thermal and energy restrict tuning controls in real-time.

The RFC patch series has this preliminary proposed AMD Dynamic Power and Thermal Configuration Interface driver code.

This patch collection has additionally turned up a little bit of a snafu resulting from AI… It seems that this driver was constructed partially by AI. And that reality wasn’t disclosed straight-up within the authentic patches. During the code evaluate when questioning what’s “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 additionally depends on magic numbers obtained from varied 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 scrub up the code and addressing some AI slop. But a very good intent is there for the AMD DPTCi driver so hopefully it would evolve into one thing acceptable to the mainline kernel.