On Thu, 2020-09-17 at 14:45 +0200, Hans de Goede wrote: > 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_p > > > rofile > > > > > > 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_perform > > > ance_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 The "description strings" need to come from a list. We're not going to use those anywhere but in debug messages, so we need a way to figure out what they would correspond to. > 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. That sounds slightly more complicated than I'd have expected it to be, but I can work with that API.
