Hi,
On 9/17/20 2:22 PM, Benjamin Berg wrote:
Hi,
On Thu, 2020-09-17 at 13:22 +0200, Hans de Goede wrote:
The big question is what do we do if there are more then 3 profiles?
The Intel p-state driver has the 4 modes:
* performance
* balance_performance
* balance_power
* power
This seems to also match what windows does with their power slider,
there the modes are mapped to integer values:
* power: 25
* balance_power: 50
* balance_performance: 75
* performance: 100
Which appears to be the same as what newer DPTF versions use. For older
DPTF versions this is done through OEM variables, which also appear to
have 4 separate states usually. The MS power slider seems to define the
four possible modes:
* Battery Saver
* Better Battery
* Better Performance
* Best Performance
https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/customize-power-slider#set-default-power-slider-mode
One option would be something like the following:
cat /sys/class/system_performance_profile/thinkpad_acpi/performance_profile
low-power [balanced] performance
I guess userspace is responsible for setting all drivers to the correct
state when the user changes a global system setting?
Yes.
cat /sys/class/system_performance_profile/thinkpad_acpi/extra_performance_profiles
extra-low-power balanced-performance-mix
So we add an optional extra_performance_profiles sysfs attribute and we ask all
drivers implemeting this class to implement at least the 3 standard profiles
(by mapping 3 of their options to these) and optional they can offer extra
profiles (with free form names) in the extra_performance_profiles
sysfs attribute under the class-device.
I think it would be good if userspace can figure out where such these
extra profiles would be sorted in on the "power save -- performance"
scale. Assigning an integer in the range of 0-100 might be a solution
for that.
Interesting, maybe the primary interface should even be an integer in
that range, so for each system_performance_profile class-device we
would then have the following attributes:
mappings (ro) - This attribute gives a list of valid performance-profile-values
In the form of "<integer-value> <description-string>\n", e.g.:
25 Low Power
50 Balanced
100 Performance
value (rw) - Integer in the range 0 (lowest performance setting) - 100
(highest performance setting). Note most drivers will only
support a number of specific discrete values, see the mappings
attribute. Userspace may write an arbitrary value between 0
and 100, this will be rounded to the closest supported discrete
value.
value_string (ro) - String representation of the currently active value,
this is a shortcut for looking up the string in the mappings
attribute yourself.
lap_mode (ro) - <lap_mode text here>
Something like p-p-daemon would then just interact with the value and lap_mode
fields, ignoring the mappings. It would then also need to do some rounding of
its own when reading value to map things back to its own internal levels.
One issue for p-p-d here might be that it writes its internal integer value
corresponding to say "Low power", then reads back a value and when rounding
that to its own discrete steps ends up at a different level then "Low power".
This can be avoid by using the mappings file to get the supported discrete values
and then only generate mappings for the discrete values to its own internal
discrete steps once and always use those mappings, thus always writing a
supported discrete value, avoiding rounding issues.
I think that this will give us a nice and flexible interface. Note if
anyone disagrees, or has a better idea please speak up. Once we have
decided on what the interface is going to be, we are effectively stuck
with it.
Regards,
Hans
Benjamin
The idea behind putting the extra profiles in a separate sysfs-attribute
is that reading the main performance_profile attribute will always show
one selected, even if one of the extra profiles is actually in use,
then the driver should also show the closest standardized profile as
being active.
This will allow userspace code to always rely on the standard interface
both for getting a representation of the currently active profile as well
as for setting the active profile.
Elia, Mark, I assume that both of you want to get your patches for this
upstream sooner, rather then later. But I think we should put them on
hold until we have an agreement on a shared userspace API for this.
I would like to think that the above proposal is a good start,
if we can quickly (*) decide on an userspace API here
Regards,
Hans
p.s.
I guess we should also add an optional lap_mode sysfs attribute
to the class-device, to have all the info for the Thinkpads in
one place.
*) but not too quickly, it is important we get this right
