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.
