Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute
@ 2020-10-26 17:44 Mark Pearson
  2020-10-26 18:33 ` Hans de Goede
  2020-10-26 18:33 ` Hans de Goede
  0 siblings, 2 replies; 9+ messages in thread
From: Mark Pearson @ 2020-10-26 17:44 UTC (permalink / raw)
  To: markpearson
  Cc: dvhart, mgross, mario.limonciello, eliadevito, hadess, bberg,
	linux-pm, linux-acpi, platform-driver-x86, linux-kernel,
	Hans de Goede

From: Hans de Goede <hdegoede@redhat.com>

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 somei
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>
---
 .../ABI/testing/sysfs-platform_profile        | 85 +++++++++++++++++++
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform_profile

diff --git a/Documentation/ABI/testing/sysfs-platform_profile b/Documentation/ABI/testing/sysfs-platform_profile
new file mode 100644
index 000000000000..37cb6275946c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform_profile
@@ -0,0 +1,85 @@
+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
+consumption or towards performance (and higher power consumption and
+thermals).
+
+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 are a rather meaningless way to describe platform-profiles
+this API uses strings to describe the various profiles. To make sure that
+userspace gets a consistent experience when using this API this API
+document defines a fixed set of profile-names. Drivers *must* map their
+internal profile representation/names onto this fixed set.
+
+If for some reason 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. Have very good reasons to do so.
+2. Add the new profile-name to this document, so that future drivers which also
+   have a similar problem can use the same new. Usually new profile-names will
+   be added to the "extra profile-names" section of this document. But in some
+   cases the set of standard profile-names may be extended.
+
+What:		/sys/firmware/acpi/platform_profile_choices
+Date:		October 2020
+Contact:	Hans de Goede <hdegoede@redhat.com>
+Description:
+		Reading this file gives a space separated list of profiles
+		supported for this device.
+
+		Drivers must use the following standard profile-names whenever
+		possible:
+
+		low-power:		Emphasises low power consumption
+		quiet:			Offers quieter operation (lower fan
+					speed but with higher performance and
+					temperatures then seen in low-power
+		balanced:		Balance between low power consumption
+					and performance
+		performance:		Emphasises performance (and may lead to
+					higher temperatures and fan speeds)
+
+		Userspace may expect drivers to offer at least several of these
+		standard profile-names! If none of the above are a good match
+		for some of the drivers profiles, then drivers may use one of
+		these extra profile-names:
+		<reserved for future use>
+
+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.
+
+		Reading this file may also return "custom". This is intended for
+		drivers which have and export multiple knobs. Such drivers may
+		very well still want to offer a set of profiles for easy of use
+		and to be able to offer a consistent standard API (this API) to
+		userspace for configuring their performance. The "custom" value
+		is intended for when ai user has directly configured the knobs
+		(through e.g. some advanced control-panel for a GPU) and the
+		knob values do not match any of the presets represented by the
+		platform-profiles. In this case writing this file will
+		override the modifications and restore the selected presets.
+
-- 
2.28.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute
  2020-10-26 17:44 [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute Mark Pearson
@ 2020-10-26 18:33 ` Hans de Goede
  2020-10-26 18:33 ` Hans de Goede
  1 sibling, 0 replies; 9+ messages in thread
From: Hans de Goede @ 2020-10-26 18:33 UTC (permalink / raw)
  To: Mark Pearson
  Cc: dvhart, mgross, mario.limonciello, eliadevito, hadess, bberg,
	linux-pm, linux-acpi, platform-driver-x86, linux-kernel

Hi Mark,

Thank you for this new version.

On 10/26/20 6:44 PM, Mark Pearson wrote:
> From: Hans de Goede <hdegoede@redhat.com>
> 
> 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 somei
> 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>
> ---
>  .../ABI/testing/sysfs-platform_profile        | 85 +++++++++++++++++++
>  1 file changed, 85 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform_profile
> 
> diff --git a/Documentation/ABI/testing/sysfs-platform_profile b/Documentation/ABI/testing/sysfs-platform_profile
> new file mode 100644
> index 000000000000..37cb6275946c
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform_profile
> @@ -0,0 +1,85 @@
> +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
> +consumption or towards performance (and higher power consumption and
> +thermals).
> +
> +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 are a rather meaningless way to describe platform-profiles
> +this API uses strings to describe the various profiles. To make sure that
> +userspace gets a consistent experience when using this API this API
> +document defines a fixed set of profile-names. Drivers *must* map their
> +internal profile representation/names onto this fixed set.
> +
> +If for some reason 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. Have very good reasons to do so.
> +2. Add the new profile-name to this document, so that future drivers which also
> +   have a similar problem can use the same new.

s/same new/same name/

> + Usually new profile-names will
> +   be added to the "extra profile-names" section of this document. But in some
> +   cases the set of standard profile-names may be extended.

With the change from a more generic API to this new one more targeted towards DPTF
I would drop this part.


> +
> +What:		/sys/firmware/acpi/platform_profile_choices
> +Date:		October 2020
> +Contact:	Hans de Goede <hdegoede@redhat.com>
> +Description:
> +		Reading this file gives a space separated list of profiles
> +		supported for this device.
> +
> +		Drivers must use the following standard profile-names whenever
> +		possible:
> +
> +		low-power:		Emphasises low power consumption
> +		quiet:			Offers quieter operation (lower fan
> +					speed but with higher performance and
> +					temperatures then seen in low-power

I think the description here is a bit too specific, this may cause userspace
to have expectations which are not necessary true. I would describe this as
just:

		quiet:			Emphasises quieter operation

> +		balanced:		Balance between low power consumption
> +					and performance
> +		performance:		Emphasises performance (and may lead to
> +					higher temperatures and fan speeds)
> +
> +		Userspace may expect drivers to offer at least several of these
> +		standard profile-names! If none of the above are a good match
> +		for some of the drivers profiles, then drivers may use one of
> +		these extra profile-names:
> +		<reserved for future use>
> +
> +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.

The part about custom profiles below may be dropped. That was intended for use
with e.g. GPUs but since this now strictly is a system-level profile API, the
part below can be dropped now.


> +
> +		Reading this file may also return "custom". This is intended for
> +		drivers which have and export multiple knobs. Such drivers may
> +		very well still want to offer a set of profiles for easy of use
> +		and to be able to offer a consistent standard API (this API) to
> +		userspace for configuring their performance. The "custom" value
> +		is intended for when ai user has directly configured the knobs
> +		(through e.g. some advanced control-panel for a GPU) and the
> +		knob values do not match any of the presets represented by the
> +		platform-profiles. In this case writing this file will
> +		override the modifications and restore the selected presets.
> +
> 

Regards,

Hans


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute
  2020-10-26 17:44 [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute Mark Pearson
  2020-10-26 18:33 ` Hans de Goede
@ 2020-10-26 18:33 ` Hans de Goede
  2020-10-26 19:55   ` [External] " Mark Pearson
  1 sibling, 1 reply; 9+ messages in thread
From: Hans de Goede @ 2020-10-26 18:33 UTC (permalink / raw)
  To: Mark Pearson
  Cc: dvhart, mgross, mario.limonciello, eliadevito, hadess, bberg,
	linux-pm, linux-acpi, platform-driver-x86, linux-kernel

Hi Mark,

Thank you for this new version.

On 10/26/20 6:44 PM, Mark Pearson wrote:
> From: Hans de Goede <hdegoede@redhat.com>
> 
> 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 somei
> 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>
> ---
>  .../ABI/testing/sysfs-platform_profile        | 85 +++++++++++++++++++
>  1 file changed, 85 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform_profile
> 
> diff --git a/Documentation/ABI/testing/sysfs-platform_profile b/Documentation/ABI/testing/sysfs-platform_profile
> new file mode 100644
> index 000000000000..37cb6275946c
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform_profile
> @@ -0,0 +1,85 @@
> +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
> +consumption or towards performance (and higher power consumption and
> +thermals).
> +
> +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 are a rather meaningless way to describe platform-profiles
> +this API uses strings to describe the various profiles. To make sure that
> +userspace gets a consistent experience when using this API this API
> +document defines a fixed set of profile-names. Drivers *must* map their
> +internal profile representation/names onto this fixed set.
> +
> +If for some reason 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. Have very good reasons to do so.
> +2. Add the new profile-name to this document, so that future drivers which also
> +   have a similar problem can use the same new.

s/same new/same name/

> + Usually new profile-names will
> +   be added to the "extra profile-names" section of this document. But in some
> +   cases the set of standard profile-names may be extended.

With the change from a more generic API to this new one more targeted towards DPTF
I would drop this part.


> +
> +What:		/sys/firmware/acpi/platform_profile_choices
> +Date:		October 2020
> +Contact:	Hans de Goede <hdegoede@redhat.com>
> +Description:
> +		Reading this file gives a space separated list of profiles
> +		supported for this device.
> +
> +		Drivers must use the following standard profile-names whenever
> +		possible:
> +
> +		low-power:		Emphasises low power consumption
> +		quiet:			Offers quieter operation (lower fan
> +					speed but with higher performance and
> +					temperatures then seen in low-power

I think the description here is a bit too specific, this may cause userspace
to have expectations which are not necessary true. I would describe this as
just:

		quiet:			Emphasises quieter operation

> +		balanced:		Balance between low power consumption
> +					and performance
> +		performance:		Emphasises performance (and may lead to
> +					higher temperatures and fan speeds)
> +
> +		Userspace may expect drivers to offer at least several of these
> +		standard profile-names! If none of the above are a good match
> +		for some of the drivers profiles, then drivers may use one of
> +		these extra profile-names:
> +		<reserved for future use>
> +
> +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.

The part about custom profiles below may be dropped. That was intended for use
with e.g. GPUs but since this now strictly is a system-level profile API, the
part below can be dropped now.


> +
> +		Reading this file may also return "custom". This is intended for
> +		drivers which have and export multiple knobs. Such drivers may
> +		very well still want to offer a set of profiles for easy of use
> +		and to be able to offer a consistent standard API (this API) to
> +		userspace for configuring their performance. The "custom" value
> +		is intended for when ai user has directly configured the knobs
> +		(through e.g. some advanced control-panel for a GPU) and the
> +		knob values do not match any of the presets represented by the
> +		platform-profiles. In this case writing this file will
> +		override the modifications and restore the selected presets.
> +
> 

Regards,

Hans


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [External] Re: [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute
  2020-10-26 18:33 ` Hans de Goede
@ 2020-10-26 19:55   ` Mark Pearson
  2020-10-27  7:54     ` Hans de Goede
  0 siblings, 1 reply; 9+ messages in thread
From: Mark Pearson @ 2020-10-26 19:55 UTC (permalink / raw)
  To: Hans de Goede
  Cc: dvhart, mgross, mario.limonciello, eliadevito, hadess, bberg,
	linux-pm, linux-acpi, platform-driver-x86, linux-kernel

Thanks Hans

On 26/10/2020 14:33, Hans de Goede wrote:
> Hi Mark,
> 
> Thank you for this new version.
> 
> On 10/26/20 6:44 PM, Mark Pearson wrote:
>> From: Hans de Goede <hdegoede@redhat.com>
>>
<snip>

>> +
>> +If for some reason 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. Have very good reasons to do so.
>> +2. Add the new profile-name to this document, so that future drivers which also
>> +   have a similar problem can use the same new.
> 
> s/same new/same name/
I've read this document so many times...I'm not sure how I missed that 
one. Thanks.
> 
>> + Usually new profile-names will
>> +   be added to the "extra profile-names" section of this document. But in some
>> +   cases the set of standard profile-names may be extended.
> 
> With the change from a more generic API to this new one more targeted towards DPTF
> I would drop this part.
OK - I have some questions then related to this change, below
> 
> 
>> +
>> +What:		/sys/firmware/acpi/platform_profile_choices
>> +Date:		October 2020
>> +Contact:	Hans de Goede <hdegoede@redhat.com>
>> +Description:
>> +		Reading this file gives a space separated list of profiles
>> +		supported for this device.
>> +
>> +		Drivers must use the following standard profile-names whenever
>> +		possible:
>> +
>> +		low-power:		Emphasises low power consumption
>> +		quiet:			Offers quieter operation (lower fan
>> +					speed but with higher performance and
>> +					temperatures then seen in low-power
> 
> I think the description here is a bit too specific, this may cause userspace
> to have expectations which are not necessary true. I would describe this as
> just:
> 
> 		quiet:			Emphasises quieter operation
> 
Agreed. I'll update

>> +		balanced:		Balance between low power consumption
>> +					and performance
>> +		performance:		Emphasises performance (and may lead to
>> +					higher temperatures and fan speeds)
>> +
>> +		Userspace may expect drivers to offer at least several of these
>> +		standard profile-names! If none of the above are a good match
>> +		for some of the drivers profiles, then drivers may use one of
>> +		these extra profile-names:
>> +		<reserved for future use>
>> +
If we remove the extra profile-names section above then I think it 
should be removed here too. If someone wants to add a new 'mode' then it 
would be added to the list of 'standard names', and becomes a new 
option. Wanted to check I'm not missing something important.

>> +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.
> 
> The part about custom profiles below may be dropped. That was intended for use
> with e.g. GPUs but since this now strictly is a system-level profile API, the
> part below can be dropped now.
Agreed
> 
> 
>> +
>> +		Reading this file may also return "custom". This is intended for
>> +		drivers which have and export multiple knobs. Such drivers may
>> +		very well still want to offer a set of profiles for easy of use
>> +		and to be able to offer a consistent standard API (this API) to
>> +		userspace for configuring their performance. The "custom" value
>> +		is intended for when ai user has directly configured the knobs
>> +		(through e.g. some advanced control-panel for a GPU) and the
>> +		knob values do not match any of the presets represented by the
>> +		platform-profiles. In this case writing this file will
>> +		override the modifications and restore the selected presets.
>> +
>>
> 
> Regards,
> 
> Hans
> 
Thanks!
mark

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [External] Re: [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute
  2020-10-26 19:55   ` [External] " Mark Pearson
@ 2020-10-27  7:54     ` Hans de Goede
  2020-10-27  9:19       ` Elia Devito
  0 siblings, 1 reply; 9+ messages in thread
From: Hans de Goede @ 2020-10-27  7:54 UTC (permalink / raw)
  To: Mark Pearson
  Cc: dvhart, mgross, mario.limonciello, eliadevito, hadess, bberg,
	linux-pm, linux-acpi, platform-driver-x86, linux-kernel

Hi,

On 10/26/20 8:55 PM, Mark Pearson wrote:
> Thanks Hans
> 
> On 26/10/2020 14:33, Hans de Goede wrote:
>> Hi Mark,
>>
>> Thank you for this new version.
>>
>> On 10/26/20 6:44 PM, Mark Pearson wrote:
>>> From: Hans de Goede <hdegoede@redhat.com>
>>>
> <snip>
> 
>>> +
>>> +If for some reason 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. Have very good reasons to do so.
>>> +2. Add the new profile-name to this document, so that future drivers which also
>>> +   have a similar problem can use the same new.
>>
>> s/same new/same name/
> I've read this document so many times...I'm not sure how I missed that one. Thanks.
>>
>>> + Usually new profile-names will
>>> +   be added to the "extra profile-names" section of this document. But in some
>>> +   cases the set of standard profile-names may be extended.
>>
>> With the change from a more generic API to this new one more targeted towards DPTF
>> I would drop this part.
> OK - I have some questions then related to this change, below
>>
>>
>>> +
>>> +What:        /sys/firmware/acpi/platform_profile_choices
>>> +Date:        October 2020
>>> +Contact:    Hans de Goede <hdegoede@redhat.com>
>>> +Description:
>>> +        Reading this file gives a space separated list of profiles
>>> +        supported for this device.
>>> +
>>> +        Drivers must use the following standard profile-names whenever
>>> +        possible:
>>> +
>>> +        low-power:        Emphasises low power consumption
>>> +        quiet:            Offers quieter operation (lower fan
>>> +                    speed but with higher performance and
>>> +                    temperatures then seen in low-power
>>
>> I think the description here is a bit too specific, this may cause userspace
>> to have expectations which are not necessary true. I would describe this as
>> just:
>>
>>         quiet:            Emphasises quieter operation
>>
> Agreed. I'll update
> 
>>> +        balanced:        Balance between low power consumption
>>> +                    and performance
>>> +        performance:        Emphasises performance (and may lead to
>>> +                    higher temperatures and fan speeds)
>>> +
>>> +        Userspace may expect drivers to offer at least several of these
>>> +        standard profile-names! If none of the above are a good match
>>> +        for some of the drivers profiles, then drivers may use one of
>>> +        these extra profile-names:
>>> +        <reserved for future use>
>>> +
> If we remove the extra profile-names section above then I think it should be removed here too. If someone wants to add a new 'mode' then it would be added to the list of 'standard names', and becomes a new option. Wanted to check I'm not missing something important.

You are completely right, any references to an extra profile-names section
should be removed here too. I did intend to add that it should be removed here
too, but I forgot.


>>> +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.
>>
>> The part about custom profiles below may be dropped. That was intended for use
>> with e.g. GPUs but since this now strictly is a system-level profile API, the
>> part below can be dropped now.
> Agreed
>>
>>
>>> +
>>> +        Reading this file may also return "custom". This is intended for
>>> +        drivers which have and export multiple knobs. Such drivers may
>>> +        very well still want to offer a set of profiles for easy of use
>>> +        and to be able to offer a consistent standard API (this API) to
>>> +        userspace for configuring their performance. The "custom" value
>>> +        is intended for when ai user has directly configured the knobs
>>> +        (through e.g. some advanced control-panel for a GPU) and the
>>> +        knob values do not match any of the presets represented by the
>>> +        platform-profiles. In this case writing this file will
>>> +        override the modifications and restore the selected presets.
>>> +
>>>
>>
>> Regards,
>>
>> Hans
>>
> Thanks!
> mark

Regards,

Hans


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [External] Re: [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute
  2020-10-27  7:54     ` Hans de Goede
@ 2020-10-27  9:19       ` Elia Devito
  2020-10-27 12:28         ` Mark Pearson
  0 siblings, 1 reply; 9+ messages in thread
From: Elia Devito @ 2020-10-27  9:19 UTC (permalink / raw)
  To: Mark Pearson, Hans de Goede
  Cc: dvhart, mgross, mario.limonciello, hadess, bberg, linux-pm,
	linux-acpi, platform-driver-x86, linux-kernel

Hi to all,

In data martedì 27 ottobre 2020 08:54:44 CET, Hans de Goede ha scritto:
> Hi,
> 
> On 10/26/20 8:55 PM, Mark Pearson wrote:
> > Thanks Hans
> > 
> > On 26/10/2020 14:33, Hans de Goede wrote:
> >> Hi Mark,
> >> 
> >> Thank you for this new version.
> >> 
> >> On 10/26/20 6:44 PM, Mark Pearson wrote:
> >>> From: Hans de Goede <hdegoede@redhat.com>
> > 
> > <snip>
> > 
> >>> +
> >>> +If for some reason 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. Have very good reasons to do so.
> >>> +2. Add the new profile-name to this document, so that future drivers
> >>> which also +   have a similar problem can use the same new.
> >> 
> >> s/same new/same name/
> > 
> > I've read this document so many times...I'm not sure how I missed that
> > one. Thanks.> 
> >>> + Usually new profile-names will
> >>> +   be added to the "extra profile-names" section of this document. But
> >>> in some +   cases the set of standard profile-names may be extended.
> >> 
> >> With the change from a more generic API to this new one more targeted
> >> towards DPTF I would drop this part.
> > 
> > OK - I have some questions then related to this change, below
> > 
> >>> +
> >>> +What:        /sys/firmware/acpi/platform_profile_choices
> >>> +Date:        October 2020
> >>> +Contact:    Hans de Goede <hdegoede@redhat.com>
> >>> +Description:
> >>> +        Reading this file gives a space separated list of profiles
> >>> +        supported for this device.
> >>> +
> >>> +        Drivers must use the following standard profile-names whenever
> >>> +        possible:
> >>> +
> >>> +        low-power:        Emphasises low power consumption
> >>> +        quiet:            Offers quieter operation (lower fan
> >>> +                    speed but with higher performance and
> >>> +                    temperatures then seen in low-power
> >> 
> >> I think the description here is a bit too specific, this may cause
> >> userspace to have expectations which are not necessary true. I would
> >> describe this as just:
> >> 
> >>         quiet:            Emphasises quieter operation
> > 
> > Agreed. I'll update
> > 
> >>> +        balanced:        Balance between low power consumption
> >>> +                    and performance
> >>> +        performance:        Emphasises performance (and may lead to
> >>> +                    higher temperatures and fan speeds)
> >>> +
> >>> +        Userspace may expect drivers to offer at least several of these
> >>> +        standard profile-names! If none of the above are a good match
> >>> +        for some of the drivers profiles, then drivers may use one of
> >>> +        these extra profile-names:
> >>> +        <reserved for future use>
> >>> +
> > 
> > If we remove the extra profile-names section above then I think it should
> > be removed here too. If someone wants to add a new 'mode' then it would
> > be added to the list of 'standard names', and becomes a new option.
> > Wanted to check I'm not missing something important.
> You are completely right, any references to an extra profile-names section
> should be removed here too. I did intend to add that it should be removed
> here too, but I forgot.
> 
> >>> +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.
> >> 
> >> The part about custom profiles below may be dropped. That was intended
> >> for use with e.g. GPUs but since this now strictly is a system-level
> >> profile API, the part below can be dropped now.
> > 
> > Agreed
> > 
> >>> +
> >>> +        Reading this file may also return "custom". This is intended
> >>> for
> >>> +        drivers which have and export multiple knobs. Such drivers may
> >>> +        very well still want to offer a set of profiles for easy of use
> >>> +        and to be able to offer a consistent standard API (this API) to
> >>> +        userspace for configuring their performance. The "custom" value
> >>> +        is intended for when ai user has directly configured the knobs
> >>> +        (through e.g. some advanced control-panel for a GPU) and the
> >>> +        knob values do not match any of the presets represented by the
> >>> +        platform-profiles. In this case writing this file will
> >>> +        override the modifications and restore the selected presets.
> >>> +
> >> 
> >> Regards,
> >> 
> >> Hans
> > 
> > Thanks!
> > mark
> 
> Regards,
> 
> Hans

This look good,
only thing is that hp-wmi driver need a cool profile (Emphasises the computer 
cool to touch), if you can add it would be perfect.

Regards
Elia




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [External] Re: [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute
  2020-10-27  9:19       ` Elia Devito
@ 2020-10-27 12:28         ` Mark Pearson
  2020-10-27 13:41           ` Hans de Goede
  0 siblings, 1 reply; 9+ messages in thread
From: Mark Pearson @ 2020-10-27 12:28 UTC (permalink / raw)
  To: Elia Devito, Hans de Goede
  Cc: dvhart, mgross, mario.limonciello, hadess, bberg, linux-pm,
	linux-acpi, platform-driver-x86, linux-kernel

Hi Elia

On 27/10/2020 05:19, Elia Devito wrote:
> Hi to all,
> 
> In data martedì 27 ottobre 2020 08:54:44 CET, Hans de Goede ha scritto:
>> Hi,
>>
>> On 10/26/20 8:55 PM, Mark Pearson wrote:
>>> Thanks Hans
>>>
>>> On 26/10/2020 14:33, Hans de Goede wrote:
>>>> Hi Mark,
>>>>
>>>> Thank you for this new version.
>>>>
>>>> On 10/26/20 6:44 PM, Mark Pearson wrote:
>>>>> From: Hans de Goede <hdegoede@redhat.com>
>>>
>>> <snip>
>>>
>>>>> +
>>>>> +If for some reason 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. Have very good reasons to do so.
>>>>> +2. Add the new profile-name to this document, so that future drivers
>>>>> which also +   have a similar problem can use the same new.
>>>>
>>>> s/same new/same name/
>>>
>>> I've read this document so many times...I'm not sure how I missed that
>>> one. Thanks.>
>>>>> + Usually new profile-names will
>>>>> +   be added to the "extra profile-names" section of this document. But
>>>>> in some +   cases the set of standard profile-names may be extended.
>>>>
>>>> With the change from a more generic API to this new one more targeted
>>>> towards DPTF I would drop this part.
>>>
>>> OK - I have some questions then related to this change, below
>>>
>>>>> +
>>>>> +What:        /sys/firmware/acpi/platform_profile_choices
>>>>> +Date:        October 2020
>>>>> +Contact:    Hans de Goede <hdegoede@redhat.com>
>>>>> +Description:
>>>>> +        Reading this file gives a space separated list of profiles
>>>>> +        supported for this device.
>>>>> +
>>>>> +        Drivers must use the following standard profile-names whenever
>>>>> +        possible:
>>>>> +
>>>>> +        low-power:        Emphasises low power consumption
>>>>> +        quiet:            Offers quieter operation (lower fan
>>>>> +                    speed but with higher performance and
>>>>> +                    temperatures then seen in low-power
>>>>
>>>> I think the description here is a bit too specific, this may cause
>>>> userspace to have expectations which are not necessary true. I would
>>>> describe this as just:
>>>>
>>>>          quiet:            Emphasises quieter operation
>>>
>>> Agreed. I'll update
>>>
>>>>> +        balanced:        Balance between low power consumption
>>>>> +                    and performance
>>>>> +        performance:        Emphasises performance (and may lead to
>>>>> +                    higher temperatures and fan speeds)
>>>>> +
>>>>> +        Userspace may expect drivers to offer at least several of these
>>>>> +        standard profile-names! If none of the above are a good match
>>>>> +        for some of the drivers profiles, then drivers may use one of
>>>>> +        these extra profile-names:
>>>>> +        <reserved for future use>
>>>>> +
>>>
>>> If we remove the extra profile-names section above then I think it should
>>> be removed here too. If someone wants to add a new 'mode' then it would
>>> be added to the list of 'standard names', and becomes a new option.
>>> Wanted to check I'm not missing something important.
>> You are completely right, any references to an extra profile-names section
>> should be removed here too. I did intend to add that it should be removed
>> here too, but I forgot.
>>
>>>>> +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.
>>>>
>>>> The part about custom profiles below may be dropped. That was intended
>>>> for use with e.g. GPUs but since this now strictly is a system-level
>>>> profile API, the part below can be dropped now.
>>>
>>> Agreed
>>>
>>>>> +
>>>>> +        Reading this file may also return "custom". This is intended
>>>>> for
>>>>> +        drivers which have and export multiple knobs. Such drivers may
>>>>> +        very well still want to offer a set of profiles for easy of use
>>>>> +        and to be able to offer a consistent standard API (this API) to
>>>>> +        userspace for configuring their performance. The "custom" value
>>>>> +        is intended for when ai user has directly configured the knobs
>>>>> +        (through e.g. some advanced control-panel for a GPU) and the
>>>>> +        knob values do not match any of the presets represented by the
>>>>> +        platform-profiles. In this case writing this file will
>>>>> +        override the modifications and restore the selected presets.
>>>>> +
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>
>>> Thanks!
>>> mark
>>
>> Regards,
>>
>> Hans
> 
> This look good,
> only thing is that hp-wmi driver need a cool profile (Emphasises the computer
> cool to touch), if you can add it would be perfect.
> 
> Regards
> Elia
> 
> 
> 
Is low-power is different to cool? I figured low-power was going to be 
cool so combined them.
I could call it low-power-cool if that helps? It seems a little clunky 
but not too bad. I'm sure the user space folks can put sunglasses on it 
or something ;)

Mark

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [External] Re: [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute
  2020-10-27 12:28         ` Mark Pearson
@ 2020-10-27 13:41           ` Hans de Goede
  2020-10-27 15:01             ` Mark Pearson
  0 siblings, 1 reply; 9+ messages in thread
From: Hans de Goede @ 2020-10-27 13:41 UTC (permalink / raw)
  To: Mark Pearson, Elia Devito
  Cc: dvhart, mgross, mario.limonciello, hadess, bberg, linux-pm,
	linux-acpi, platform-driver-x86, linux-kernel

Hi Mark,

On 10/27/20 1:28 PM, Mark Pearson wrote:
> Hi Elia
> 
> On 27/10/2020 05:19, Elia Devito wrote:
>> Hi to all,
>>
>> In data martedì 27 ottobre 2020 08:54:44 CET, Hans de Goede ha scritto:
>>> Hi,
>>>
>>> On 10/26/20 8:55 PM, Mark Pearson wrote:
>>>> Thanks Hans
>>>>
>>>> On 26/10/2020 14:33, Hans de Goede wrote:
>>>>> Hi Mark,
>>>>>
>>>>> Thank you for this new version.
>>>>>
>>>>> On 10/26/20 6:44 PM, Mark Pearson wrote:
>>>>>> From: Hans de Goede <hdegoede@redhat.com>
>>>>
>>>> <snip>
>>>>
>>>>>> +
>>>>>> +If for some reason 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. Have very good reasons to do so.
>>>>>> +2. Add the new profile-name to this document, so that future drivers
>>>>>> which also +   have a similar problem can use the same new.
>>>>>
>>>>> s/same new/same name/
>>>>
>>>> I've read this document so many times...I'm not sure how I missed that
>>>> one. Thanks.>
>>>>>> + Usually new profile-names will
>>>>>> +   be added to the "extra profile-names" section of this document. But
>>>>>> in some +   cases the set of standard profile-names may be extended.
>>>>>
>>>>> With the change from a more generic API to this new one more targeted
>>>>> towards DPTF I would drop this part.
>>>>
>>>> OK - I have some questions then related to this change, below
>>>>
>>>>>> +
>>>>>> +What:        /sys/firmware/acpi/platform_profile_choices
>>>>>> +Date:        October 2020
>>>>>> +Contact:    Hans de Goede <hdegoede@redhat.com>
>>>>>> +Description:
>>>>>> +        Reading this file gives a space separated list of profiles
>>>>>> +        supported for this device.
>>>>>> +
>>>>>> +        Drivers must use the following standard profile-names whenever
>>>>>> +        possible:
>>>>>> +
>>>>>> +        low-power:        Emphasises low power consumption
>>>>>> +        quiet:            Offers quieter operation (lower fan
>>>>>> +                    speed but with higher performance and
>>>>>> +                    temperatures then seen in low-power
>>>>>
>>>>> I think the description here is a bit too specific, this may cause
>>>>> userspace to have expectations which are not necessary true. I would
>>>>> describe this as just:
>>>>>
>>>>>          quiet:            Emphasises quieter operation
>>>>
>>>> Agreed. I'll update
>>>>
>>>>>> +        balanced:        Balance between low power consumption
>>>>>> +                    and performance
>>>>>> +        performance:        Emphasises performance (and may lead to
>>>>>> +                    higher temperatures and fan speeds)
>>>>>> +
>>>>>> +        Userspace may expect drivers to offer at least several of these
>>>>>> +        standard profile-names! If none of the above are a good match
>>>>>> +        for some of the drivers profiles, then drivers may use one of
>>>>>> +        these extra profile-names:
>>>>>> +        <reserved for future use>
>>>>>> +
>>>>
>>>> If we remove the extra profile-names section above then I think it should
>>>> be removed here too. If someone wants to add a new 'mode' then it would
>>>> be added to the list of 'standard names', and becomes a new option.
>>>> Wanted to check I'm not missing something important.
>>> You are completely right, any references to an extra profile-names section
>>> should be removed here too. I did intend to add that it should be removed
>>> here too, but I forgot.
>>>
>>>>>> +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.
>>>>>
>>>>> The part about custom profiles below may be dropped. That was intended
>>>>> for use with e.g. GPUs but since this now strictly is a system-level
>>>>> profile API, the part below can be dropped now.
>>>>
>>>> Agreed
>>>>
>>>>>> +
>>>>>> +        Reading this file may also return "custom". This is intended
>>>>>> for
>>>>>> +        drivers which have and export multiple knobs. Such drivers may
>>>>>> +        very well still want to offer a set of profiles for easy of use
>>>>>> +        and to be able to offer a consistent standard API (this API) to
>>>>>> +        userspace for configuring their performance. The "custom" value
>>>>>> +        is intended for when ai user has directly configured the knobs
>>>>>> +        (through e.g. some advanced control-panel for a GPU) and the
>>>>>> +        knob values do not match any of the presets represented by the
>>>>>> +        platform-profiles. In this case writing this file will
>>>>>> +        override the modifications and restore the selected presets.
>>>>>> +
>>>>>
>>>>> Regards,
>>>>>
>>>>> Hans
>>>>
>>>> Thanks!
>>>> mark
>>>
>>> Regards,
>>>
>>> Hans
>>
>> This look good,
>> only thing is that hp-wmi driver need a cool profile (Emphasises the computer
>> cool to touch), if you can add it would be perfect.
>>
>> Regards
>> Elia
>>
>>
>>
> Is low-power is different to cool? I figured low-power was going to be cool so combined them.
> I could call it low-power-cool if that helps? It seems a little clunky but not too bad. I'm sure the user space folks can put sunglasses on it or something ;)

IIRC we already had this discussion, cool means cool-to-touch, so could be done by
e.g. extra aggressive ramping up of the fans, so this is not necessarily the same
as low-power.

Yes this is all somewhat confusing. Luckily (for us kernel folks) we have already
sorta decided to just use the profile-names from the vendors more or less as is and
leave figuring this out further to userspace.

The reason to use the enum + try to have a fixed list of choices is to try and
limit the proliferation of profile-names to keep things somewhat manageable.

But as I discussed previously with Elia (*) we really need all 3 of low-power
cool and quiet.

Regards,

Hans



*) I was coming at this discussion from the same angle you (Mark) are


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [External] Re: [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute
  2020-10-27 13:41           ` Hans de Goede
@ 2020-10-27 15:01             ` Mark Pearson
  0 siblings, 0 replies; 9+ messages in thread
From: Mark Pearson @ 2020-10-27 15:01 UTC (permalink / raw)
  To: Hans de Goede, Elia Devito
  Cc: dvhart, mgross, mario.limonciello, hadess, bberg, linux-pm,
	linux-acpi, platform-driver-x86, linux-kernel



On 27/10/2020 09:41, Hans de Goede wrote:
> Hi Mark,
> 
> On 10/27/20 1:28 PM, Mark Pearson wrote:
>> Hi Elia
>>
>> On 27/10/2020 05:19, Elia Devito wrote:
>>> Hi to all,
>>>
>>> In data martedì 27 ottobre 2020 08:54:44 CET, Hans de Goede ha scritto:
<snip>
>>>
>>> This look good,
>>> only thing is that hp-wmi driver need a cool profile (Emphasises the computer
>>> cool to touch), if you can add it would be perfect.
>>>
>>> Regards
>>> Elia
>>>
>>>
>>>
>> Is low-power is different to cool? I figured low-power was going to be cool so combined them.
>> I could call it low-power-cool if that helps? It seems a little clunky but not too bad. I'm sure the user space folks can put sunglasses on it or something ;)
> 
> IIRC we already had this discussion, cool means cool-to-touch, so could be done by
> e.g. extra aggressive ramping up of the fans, so this is not necessarily the same
> as low-power.
> 
> Yes this is all somewhat confusing. Luckily (for us kernel folks) we have already
> sorta decided to just use the profile-names from the vendors more or less as is and
> leave figuring this out further to userspace.
> 
> The reason to use the enum + try to have a fixed list of choices is to try and
> limit the proliferation of profile-names to keep things somewhat manageable.
> 
> But as I discussed previously with Elia (*) we really need all 3 of low-power
> cool and quiet.
> 
> Regards,
> 
> Hans
> 
> 
> 
> *) I was coming at this discussion from the same angle you (Mark) are
> 
OK, I can add a cool option.

I'll get that out later today (unless Elia corrects me :))

Thanks all
Mark

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-26 17:44 [PATCH] [RFC] Documentation: Add documentation for new platform_profile sysfs attribute Mark Pearson
2020-10-26 18:33 ` Hans de Goede
2020-10-26 18:33 ` Hans de Goede
2020-10-26 19:55   ` [External] " Mark Pearson
2020-10-27  7:54     ` Hans de Goede
2020-10-27  9:19       ` Elia Devito
2020-10-27 12:28         ` Mark Pearson
2020-10-27 13:41           ` Hans de Goede
2020-10-27 15:01             ` Mark Pearson

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git