| Message ID | 20201202171120.65269-1-markpearson@lenovo.com (mailing list archive) |
|---|---|
| State | Deferred, archived |
| Headers | show |
| Series | [v5,1/3] Documentation: Add documentation for new platform_profile sysfs attribute | expand |
Hi, On 12/2/20 6:11 PM, Mark Pearson wrote: > On modern systems the platform performance, temperature, fan and other > hardware related characteristics are often dynamically configurable. The > profile is often automatically adjusted to the load by some > automatic-mechanism (which may very well live outside the kernel). > > These auto platform-adjustment mechanisms often can be configured with > one of several 'platform-profiles', with either a bias towards low-power > consumption or towards performance (and higher power consumption and > thermals). > > Introduce a new platform_profile sysfs API which offers a generic API for > selecting the performance-profile of these automatic-mechanisms. > > Co-developed-by: Mark Pearson <markpearson@lenovo.com> > Signed-off-by: Mark Pearson <markpearson@lenovo.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> Thank you, patches 1 and 2 look good to me now, you may add my: Reviewed-by: Hans de Goede <hdegoede@redhat.com> To patch 2 (since I'm co-author of patch 1 it would be a bit weird to add it there too). Rafael, it would be great if you pick up patches 1 and 2 for merging into 5.11 (assuming that you agree that they are ready) then I will merge patch 3 once 5.11-rc1 is out. Regards, Hans > --- > Changes in v2: > - updated to rst format > Changes in v3, v4 & v5: > - version bump along with rest of patch series > > .../ABI/testing/sysfs-platform_profile.rst | 66 +++++++++++++++++++ > 1 file changed, 66 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-platform_profile.rst > > diff --git a/Documentation/ABI/testing/sysfs-platform_profile.rst b/Documentation/ABI/testing/sysfs-platform_profile.rst > new file mode 100644 > index 000000000000..5f7b2a94409b > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-platform_profile.rst > @@ -0,0 +1,66 @@ > +======================================================================= > + Platform Profile Selection (e.g. /sys/firmware/acpi/platform_profile) > +======================================================================= > + > + > +On modern systems the platform performance, temperature, fan and other > +hardware related characteristics are often dynamically configurable. The > +profile is often automatically adjusted to the load by some > +automatic mechanism (which may very well live outside the kernel). > + > +These auto platform adjustment mechanisms often can be configured with > +one of several platform profiles, with either a bias towards low power > +operation or towards performance. > + > +The purpose of the platform_profile attribute is to offer a generic sysfs > +API for selecting the platform profile of these automatic mechanisms. > + > +Note that this API is only for selecting the platform profile, it is > +NOT a goal of this API to allow monitoring the resulting performance > +characteristics. Monitoring performance is best done with device/vendor > +specific tools such as e.g. turbostat. > + > +Specifically when selecting a high performance profile the actual achieved > +performance may be limited by various factors such as: the heat generated > +by other components, room temperature, free air flow at the bottom of a > +laptop, etc. It is explicitly NOT a goal of this API to let userspace know > +about any sub-optimal conditions which are impeding reaching the requested > +performance level. > + > +Since numbers on their own cannot represent the multiple variables that a > +profile will adjust (power consumption, heat generation, etc) this API > +uses strings to describe the various profiles. To make sure that userspace > +gets a consistent experience this API document defines a fixed set of > +profile names. Drivers *must* map their internal profile representation > +onto this fixed set. > + > + > +If there is no good match when mapping then a new profile name may be > +added. Drivers which wish to introduce new profile names must: > + > + 1. Explain why the existing profile names canot be used. > + 2. Add the new profile name, along with a clear description of the > + expected behaviour, to the documentation. > + > +:What: /sys/firmware/acpi/platform_profile_choices > +:Date: October 2020 > +:Contact: Hans de Goede <hdegoede@redhat.com> > +:Description: This file contains a space-separated list of profiles supported for this device. > + > + Drivers must use the following standard profile-names:: > + > + low-power: Low power consumption > + cool: Cooler operation > + quiet: Quieter operation > + balanced: Balance between low power consumption and performance > + performance: High performance operation > + > + Userspace may expect drivers to offer more than one of these > + standard profile names. > + > +:What: /sys/firmware/acpi/platform_profile > +:Date: October 2020 > +:Contact: Hans de Goede <hdegoede@redhat.com> > +:Description: Reading this file gives the current selected profile for this > + device. Writing this file with one of the strings from > + available_profiles changes the profile to the new value. >
On Thu, Dec 3, 2020 at 10:46 AM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 12/2/20 6:11 PM, Mark Pearson wrote: > > On modern systems the platform performance, temperature, fan and other > > hardware related characteristics are often dynamically configurable. The > > profile is often automatically adjusted to the load by some > > automatic-mechanism (which may very well live outside the kernel). > > > > These auto platform-adjustment mechanisms often can be configured with > > one of several 'platform-profiles', with either a bias towards low-power > > consumption or towards performance (and higher power consumption and > > thermals). > > > > Introduce a new platform_profile sysfs API which offers a generic API for > > selecting the performance-profile of these automatic-mechanisms. > > > > Co-developed-by: Mark Pearson <markpearson@lenovo.com> > > Signed-off-by: Mark Pearson <markpearson@lenovo.com> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > Thank you, patches 1 and 2 look good to me now, you may add my: > > Reviewed-by: Hans de Goede <hdegoede@redhat.com> > > To patch 2 (since I'm co-author of patch 1 it would be a bit weird > to add it there too). > > Rafael, it would be great if you pick up patches 1 and 2 for merging > into 5.11 (assuming that you agree that they are ready) then I will merge > patch 3 once 5.11-rc1 is out. I've applied patch [1/2] (as 5.11-rc material) for now, but I still needed to fix it up somewhat. Please check the result in my bleeding-edge branch. I'll get to the other patch tomorrow. Thanks!
Hi, On 12/7/20 8:29 PM, Rafael J. Wysocki wrote: > On Thu, Dec 3, 2020 at 10:46 AM Hans de Goede <hdegoede@redhat.com> wrote: >> >> Hi, >> >> On 12/2/20 6:11 PM, Mark Pearson wrote: >>> On modern systems the platform performance, temperature, fan and other >>> hardware related characteristics are often dynamically configurable. The >>> profile is often automatically adjusted to the load by some >>> automatic-mechanism (which may very well live outside the kernel). >>> >>> These auto platform-adjustment mechanisms often can be configured with >>> one of several 'platform-profiles', with either a bias towards low-power >>> consumption or towards performance (and higher power consumption and >>> thermals). >>> >>> Introduce a new platform_profile sysfs API which offers a generic API for >>> selecting the performance-profile of these automatic-mechanisms. >>> >>> Co-developed-by: Mark Pearson <markpearson@lenovo.com> >>> Signed-off-by: Mark Pearson <markpearson@lenovo.com> >>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> >> Thank you, patches 1 and 2 look good to me now, you may add my: >> >> Reviewed-by: Hans de Goede <hdegoede@redhat.com> >> >> To patch 2 (since I'm co-author of patch 1 it would be a bit weird >> to add it there too). >> >> Rafael, it would be great if you pick up patches 1 and 2 for merging >> into 5.11 (assuming that you agree that they are ready) then I will merge >> patch 3 once 5.11-rc1 is out. > > I've applied patch [1/2] (as 5.11-rc material) for now, but I still > needed to fix it up somewhat. Please check the result in my > bleeding-edge branch. Thank you. > I'll get to the other patch tomorrow. The other patch likely conflicts with a bunch of other thinkpad_acpi changes already in pdx86/for-next; and I still need to review v5 of it, so please do not apply it. I will pick it up after 5.11-rc1 and send it out as part of a pull-req for rc2. Regards, Hans
Hi, On 12/8/20 10:11 AM, Hans de Goede wrote: > Hi, > > On 12/7/20 8:29 PM, Rafael J. Wysocki wrote: >> On Thu, Dec 3, 2020 at 10:46 AM Hans de Goede <hdegoede@redhat.com> wrote: >>> >>> Hi, >>> >>> On 12/2/20 6:11 PM, Mark Pearson wrote: >>>> On modern systems the platform performance, temperature, fan and other >>>> hardware related characteristics are often dynamically configurable. The >>>> profile is often automatically adjusted to the load by some >>>> automatic-mechanism (which may very well live outside the kernel). >>>> >>>> These auto platform-adjustment mechanisms often can be configured with >>>> one of several 'platform-profiles', with either a bias towards low-power >>>> consumption or towards performance (and higher power consumption and >>>> thermals). >>>> >>>> Introduce a new platform_profile sysfs API which offers a generic API for >>>> selecting the performance-profile of these automatic-mechanisms. >>>> >>>> Co-developed-by: Mark Pearson <markpearson@lenovo.com> >>>> Signed-off-by: Mark Pearson <markpearson@lenovo.com> >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >>> >>> Thank you, patches 1 and 2 look good to me now, you may add my: >>> >>> Reviewed-by: Hans de Goede <hdegoede@redhat.com> >>> >>> To patch 2 (since I'm co-author of patch 1 it would be a bit weird >>> to add it there too). >>> >>> Rafael, it would be great if you pick up patches 1 and 2 for merging >>> into 5.11 (assuming that you agree that they are ready) then I will merge >>> patch 3 once 5.11-rc1 is out. >> >> I've applied patch [1/2] (as 5.11-rc material) for now, but I still >> needed to fix it up somewhat. Please check the result in my >> bleeding-edge branch. > > Thank you. > >> I'll get to the other patch tomorrow. > > The other patch likely conflicts with a bunch of other thinkpad_acpi > changes already in pdx86/for-next; and I still need to review v5 of > it, so please do not apply it. > > I will pick it up after 5.11-rc1 and send it out as part of a > pull-req for rc2. Sorry I misread what you wrote, when you said you "applied patch [1/2]", I now see that you have only merged: "[PATCH v5 1/3] Documentation: Add documentation for new platform_profile sysfs attribute" And that the other patch which you intend to merge is not the thinkpad_acpi patch but: "[PATCH v5 2/3] ACPI: platform-profile: Add platform profile support" So please ignore what I said before. ### I checked out the fixed up version of: "[PATCH v5 1/3] Documentation: Add documentation for new platform_profile sysfs attribute" Which you merged and it looks good to me, thanks. Regards, Hans
diff --git a/Documentation/ABI/testing/sysfs-platform_profile.rst b/Documentation/ABI/testing/sysfs-platform_profile.rst new file mode 100644 index 000000000000..5f7b2a94409b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform_profile.rst @@ -0,0 +1,66 @@ +======================================================================= + Platform Profile Selection (e.g. /sys/firmware/acpi/platform_profile) +======================================================================= + + +On modern systems the platform performance, temperature, fan and other +hardware related characteristics are often dynamically configurable. The +profile is often automatically adjusted to the load by some +automatic mechanism (which may very well live outside the kernel). + +These auto platform adjustment mechanisms often can be configured with +one of several platform profiles, with either a bias towards low power +operation or towards performance. + +The purpose of the platform_profile attribute is to offer a generic sysfs +API for selecting the platform profile of these automatic mechanisms. + +Note that this API is only for selecting the platform profile, it is +NOT a goal of this API to allow monitoring the resulting performance +characteristics. Monitoring performance is best done with device/vendor +specific tools such as e.g. turbostat. + +Specifically when selecting a high performance profile the actual achieved +performance may be limited by various factors such as: the heat generated +by other components, room temperature, free air flow at the bottom of a +laptop, etc. It is explicitly NOT a goal of this API to let userspace know +about any sub-optimal conditions which are impeding reaching the requested +performance level. + +Since numbers on their own cannot represent the multiple variables that a +profile will adjust (power consumption, heat generation, etc) this API +uses strings to describe the various profiles. To make sure that userspace +gets a consistent experience this API document defines a fixed set of +profile names. Drivers *must* map their internal profile representation +onto this fixed set. + + +If there is no good match when mapping then a new profile name may be +added. Drivers which wish to introduce new profile names must: + + 1. Explain why the existing profile names canot be used. + 2. Add the new profile name, along with a clear description of the + expected behaviour, to the documentation. + +:What: /sys/firmware/acpi/platform_profile_choices +:Date: October 2020 +:Contact: Hans de Goede <hdegoede@redhat.com> +:Description: This file contains a space-separated list of profiles supported for this device. + + Drivers must use the following standard profile-names:: + + low-power: Low power consumption + cool: Cooler operation + quiet: Quieter operation + balanced: Balance between low power consumption and performance + performance: High performance operation + + Userspace may expect drivers to offer more than one of these + standard profile names. + +:What: /sys/firmware/acpi/platform_profile +:Date: October 2020 +:Contact: Hans de Goede <hdegoede@redhat.com> +:Description: Reading this file gives the current selected profile for this + device. Writing this file with one of the strings from + available_profiles changes the profile to the new value.