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

[Antheas Kapenekakis]

On Thu, 15 Oct 2026 at 17:03, Mario Limonciello
<mario.limonciello@xxxxxxx> wrote:
>
>
>
> On 10/15/26 09:55, Antheas Kapenekakis wrote:
> > On Thu, 15 Oct 2026 at 16:37, Mario Limonciello
> > <mario.limonciello@xxxxxxx> wrote:
> >>
> >>
> >>
> >> On 10/15/26 04:35, Antheas Kapenekakis wrote:
> >>> On Tue, 10 Mar 2026 at 08:59, Antheas Kapenekakis <lkml@xxxxxxxxxxx> wrote:
> >>>>
> >>>> On Tue, 10 Mar 2026 at 03:43, Mario Limonciello
> >>>> <mario.limonciello@xxxxxxx> 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?
> >
> > 95F20B61-3D44-41F8-87E1-03CBF94C4E8F returns nothing on my ACPI dumps.
> > There are functions which contain the e.g., 0x00020026 on a lot of
> > ssdts but no WMI with the GUID that series provides.
> >
> > The WMI GUID of those functions is
> > ABBC0F6A-8EA1-11D1-00A0-C90629100000. If the interface is the same,
> > consider adding it to that driver.
>
> OK - It shouldn't be the same.
>
> >
> > You may reference to check yourself [2]
> >
> > Here is what my LLM told me about that GUID:
> >
> > | Dump | GUID present |
> > |---|---|
> > | Legion Go `N3CN26WW` | No |
> > | Legion Go `N3CN28WW` / `28WW-beta` | No |
> > | Legion Go `N3CN29WW` and later versions here | Yes |
> > | ROG Ally | No |
> > | Ally X | Yes |
> > | GPD Win 4 / Win Mini | No |
> > | One Xplayer / F1 Pro | Yes |
> >
> > So very mixed, and perhaps not an alternative to what this series
> > provides to these devices. Fine by me to go through
> >
> >> 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.
> >
> > I was specifically asking about this interface. Not in a rush, just
> > bumping this a bit so it does not end up getting re-implemented. I
> > might not be able to fix all of the issues but I will try the best I
> > can.
> >
> > It seems this interface is so universal the CPU check might be bogus,
> > but I managed to collect 99% of the CPUs, I only get a straggler
> > reported every month or so. So it should be ok to stay.
>
> I'll admit this series hasn't been top of mind for me in a while.  (So I
> might have some page faults while trying to remember things about it).
>
> Earlier in the discussion for this series that as long as this is tied
> to SMBIOS strings to *only* load on intended hardware that should be
> sufficient.  If two systems use the same SMBIOS strings between
> generations then you'll have to add CPU disambiguation.

You suggested removing it, but indeed that's the case. SMBIOS
information is shared per device generation for most manufacturers. So
typically there are 2-3 CPUs per device. But motherboard is the same,
TDP limits are the same. Typically it is bins of the same SOC, eg.
7600/7800/8600/8800 or 388/395, etc. I have not found an exception
yet.

I will add it to my todo list to revisit this submission

Antheas

> >
> >> 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.
> >
> > Sigh, if I figure out I will
>
> No worries if you can't.  I was just looking for an opportunity for less
> back and forth in case it flags something.
> >
> > [2] https://github.com/hhd-dev/hwinfo
> >
> >> https://lore.kernel.org/all/20261010190543.563161-1-Shyam-sundar.S-k@xxxxxxx/
> >> [1]
> >>
> >>
> >
>
>