Re: [RFC v4 0/4] platform/x86/amd: Add AMD DPTCi driver for TDP control in devices without vendor-specific controls

[Mario Limonciello <mario.limonciello@amd.com>]

On 10/15/26 04:35, Antheas Kapenekakis wrote:
> On Tue, 10 Mar 2026 at 08:59, Antheas Kapenekakis <lkml@antheas.dev> wrote:
>>
>> On Tue, 10 Mar 2026 at 03:43, Mario Limonciello
>> <mario.limonciello@amd.com> wrote:
>>>
>>>
>>>
>>> On 3/9/2026 3:51 PM, Antheas Kapenekakis wrote:
>>>> 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:
>>>> sustained power limit (SPL/STAPM + skin), slow PPT, fast PPT, and the
>>>> thermal control target.
>>>>
>>>> Unlike mainstream AMD laptops, these devices do not implement vendor-
>>>> specific WMI or EC hooks for TDP control. The ones that do, use DPTCi
>>>> under the hood. For these devices, ALIB is the only viable mechanism for
>>>> the OS to adjust power limits, making a dedicated kernel driver the
>>>> correct approach rather than relying on the out-of-tree acpi_call module
>>>> or ryzenadj.
>>>>
>>>> The driver provides two layers of control:
>>>>
>>>>     * Platform profile integration (low-power / balanced / performance /
>>>>       custom), with per-device preset tunings derived from thermal envelope
>>>>       data. Selecting a non-custom profile applies values immediately and
>>>>       locks the individual tunables to read-only. The default profile is
>>>>       "custom", leaving the device at firmware defaults until userspace
>>>>       explicitly selects a profile.
>>>>
>>>>     * Four firmware-attributes tunables (ppt_pl1_spl, ppt_pl2_sppt,
>>>>       ppt_pl3_fppt, cpu_temp) that become writable in "custom" mode.
>>>>       Values are enforced against per-device limits (smin..smax), with an
>>>>       "expanded_limits" toggle that widens the range to the full hardware-
>>>>       validated envelope (min..max). A save_settings attribute controls
>>>>       whether writes commit immediately ("single") or are staged for an
>>>>       explicit bulk "save".
>>>>
>>>> On resume, the active profile or staged values are re-applied so that
>>>> suspend/resume cycles do not silently revert to firmware defaults unless
>>>> in custom and in bulk mode. In that case, defer to userspace.
>>>>
>>>> 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, 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.
>>>>
>>>> Responsible disclosure: The development of this driver is AI assisted.
>>>> This includes its writing, testing, reviewing, and readmes. The driver was
>>>> manually reviewed line by line, but there may still be small leftover
>>>> quirks. This is an RFC, not a final version. Let's push these tools to
>>>> their limits and see where it takes us.
>>>>
>>>
>>> I'll tell you where the most immediate limit is.  Humans can't review
>>> RFC changes that go in daily.
>>>
>>> Over my weekend I see multiple copies of the series in my inbox.  To me
>>> they must have obviously been garbage because you sent them so quickly
>>> instead of waiting for feedback.  So I'll delete those from my inbox and
>>> review the most recent one.
>>>
>>> That's somewhat tongue in cheek.  I know you're excited for this series,
>>> but please make sure you take time to gather and take feedback into
>>> account before posting another series.
>>
>> It's true, I've been having a bit of fun. But the series is stabilized
>> now, I don't plan to send another version soon unless I messed up
>> something.
>>
>> V3 incorporated your feedback/derek's and V4 incorporated rong's
>> feedback. V4 is minor, it is just nits.
>>
>>> Maybe you can pass this to a robot and it
>>> can give you actionable feedback, but a human sitting down and reviewing
>>> a patch series in a serious way takes time.
>>
>> I'm using this series as a testbed to make some tooling for this,
>> maybe I will post it soon.
> 
> Opus 4.6 was something. Anyway. @Mario v4 of this driver as it stands
> is pretty good for prod. Since then, I kept adding devices and
> adjusting devices based on user feedback but I did not have to touch
> the driver otherwise. It has been tested on most APUs and around 30
> device models now.
> 
> One thing this driver does not do is AC/DC limits and it would be good
> if it did. That way presets could be pushed higher for AC but that is
> only mildly necessary for AI Max platforms. 45W is more than enough
> for all of them anyway, but we could go to 55W e.g. (after that they
> saturate so it is unnecessary strain). But the updated limits I have
> are conservative enough where it is not an issue. I also found myself
> not using the commit option, so I think it can be removed.
> 
> The only issue with this driver is that steam maxes out TDP when you
> disable the TDP slider and as the custom limit is generic for both
> AC/DC it can strain the battery. This is an architectural issue with
> steamos manager as before steam used the _default tdp value in AMD
> sysfs but dropped the notion of default when transitioning to steamos
> manager. But this is a downstream problem unrelated to the driver
> where special DC limits could help a bit.
> 
> This is because I heard you might be working on something similar. So
> let's prevent some duplicative work. Should I repost a cleaned up V5?
> 
> Best,
> Antheas
By "something similar" do you mean the AMD overclocking driver posted 
recently [1]?

Does that happen to work on any of this hardware?

If it doesn't; sure please post your v5 that has incorporated feedback 
from this thread after the merge window at the start of the next kernel 
cycle and we can review it again.

BTW I think this version was last posted before Sashiko started 
reviewing patches too.  If you can; please run a local Sashiko review 
cycle on it before posting your v5.

https://lore.kernel.org/all/20261010190543.563161-1-Shyam-sundar.S-k@amd.com/ 
[1]