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

[Mario Limonciello]

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.

> > 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]