From: Mario Limonciello <superm1@kernel.org>
To: Antheas Kapenekakis <lkml@antheas.dev>
Cc: "Kurt Borja" <kuurtb@gmail.com>,
"Shyam Sundar S K" <Shyam-sundar.S-k@amd.com>,
"Rafael J . Wysocki" <rafael@kernel.org>,
"Hans de Goede" <hdegoede@redhat.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Luke D . Jones" <luke@ljones.dev>,
"Mark Pearson" <mpearson-lenovo@squebb.ca>,
"open list:AMD PMF DRIVER" <platform-driver-x86@vger.kernel.org>,
"open list" <linux-kernel@vger.kernel.org>,
"open list:ACPI" <linux-acpi@vger.kernel.org>,
"Derek J . Clark" <derekjohn.clark@gmail.com>,
me@kylegospodneti.ch, "Denis Benato" <benato.denis96@gmail.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Armin Wolf" <W_Armin@gmx.de>
Subject: Re: [PATCH 1/3] ACPI: platform_profile: Add support for hidden choices
Date: Sat, 1 Mar 2025 07:52:15 -0600 [thread overview]
Message-ID: <09674d15-d639-4cb3-837a-9575f0028a76@kernel.org> (raw)
In-Reply-To: <CAGwozwGFLQxGEQ-nb+d9yrikz=fx+u48mpTYUyUtvgFD-9ypQg@mail.gmail.com>
>>> Let me know what you think!
>>
>> I don't really like that profiles can get out of sync, this is asking
>> for a non-deterministic behavior that can be difficult to diagnose
>> issues and also difficult for userspace to work with.
>
> I agree with Mario here. Imagine two drivers, one with low-power and
> one with quiet. They both begin at performance.
>
> Then, userspace software gets confused (incl. ppd) and sets firmware
> profile to low-power. The latter gets left in performance, causing
> excess drain.
>
> I do not believe the legacy interface should be deprecated. Right now,
> amd-pmf is a NOOP in most devices
"Most" devices is not accurate. There are a lot of devices that it does
enable. In the gaming space right now it's often behaving as a no-op.
> so there is actually 0 reason for
> generic power handlers to move to the new API. Just extra work. So
> lets make sure the legacy endpoint works properly for the foreseeable
> future.
>
> Also, when power handlers start moving to the new interface, they will
> hardcode choices based on the name. As they should. TDP needs to be
> customized per device/manufacturer. So moving handlers between
> low-power and quiet will not be possible.
>
> @Mario: I do not have a device with an amd-pmf integration. All of
> mine have stub handlers. I would expect that a properly configured pmf
> handler for e.g., Asus would do the same as the armoury interface, so
> that users do not have to rely to vendor software on WIndows. Then
> power profiles would be synced between windows and armoury. In that
> case, we have a problem of setting the power mode twice. What would be
> the mitigation for something like that?
>
> Antheas
"Power mode" is a concept, it doesn't just apply to configuring sPPT and
fPPT. I envisage that a vendor that actively uses PMF and their own
interface would be changing different things by the different interfaces.
For "example" PMF may reconfigure sPPT, fPPT, STT and STAPM but their
driver may notify their EC to change a fan curve.
If we really end up with a situation that vendor interface and PMF do
the same thing we can cross that bridge then.
next prev parent reply other threads:[~2025-03-01 13:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-28 17:01 [PATCH 0/3] Add support for hidden choices to platform_profile Mario Limonciello
2025-02-28 17:01 ` [PATCH 1/3] ACPI: platform_profile: Add support for hidden choices Mario Limonciello
2025-02-28 17:15 ` Antheas Kapenekakis
2025-02-28 22:08 ` Kurt Borja
2025-03-01 3:19 ` Mario Limonciello
2025-03-01 11:06 ` Antheas Kapenekakis
2025-03-01 13:52 ` Mario Limonciello [this message]
2025-03-01 14:06 ` Antheas Kapenekakis
2025-03-01 16:03 ` Mario Limonciello
2025-03-01 16:15 ` Antheas Kapenekakis
2025-03-02 3:23 ` Mark Pearson
2025-02-28 17:01 ` [PATCH 2/3] platform/x86/amd: pmf: Add 'quiet' to " Mario Limonciello
2025-02-28 17:01 ` [PATCH 3/3] platform/x86/amd: pmf: Add balanced-performance " Mario Limonciello
2025-02-28 19:39 ` [PATCH 0/3] Add support for hidden choices to platform_profile Mark Pearson
2025-02-28 19:44 ` Mario Limonciello
2025-02-28 19:53 ` Antheas Kapenekakis
2025-02-28 19:56 ` Mario Limonciello
2025-02-28 20:03 ` Mark Pearson
2025-02-28 20:38 ` Derek John Clark
2025-03-01 11:09 ` Antheas Kapenekakis
2025-03-01 13:44 ` Mario Limonciello
2025-03-01 13:51 ` Antheas Kapenekakis
2025-03-04 16:22 ` Ilpo Järvinen
2025-03-04 19:59 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09674d15-d639-4cb3-837a-9575f0028a76@kernel.org \
--to=superm1@kernel.org \
--cc=Shyam-sundar.S-k@amd.com \
--cc=W_Armin@gmx.de \
--cc=benato.denis96@gmail.com \
--cc=derekjohn.clark@gmail.com \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kuurtb@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@antheas.dev \
--cc=luke@ljones.dev \
--cc=mario.limonciello@amd.com \
--cc=me@kylegospodneti.ch \
--cc=mpearson-lenovo@squebb.ca \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®