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? > 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. 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 >
Attachment:
signature.asc
Description: This is a digitally signed message part
