[v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

  We want programs besides the compositor to be able to enable or disable
panel power saving features. However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.

Cc: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
---
v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
    commit when setting the value, call sysfs_remove_group() in
    amdgpu_dm_connector_unregister() and add some documentation.
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++++++++++++++++++
 1 file changed, 76 insertions(+)
  

On 2/2/2024 09:28, Hamza Mahfooz wrote:
> We want programs besides the compositor to be able to enable or disable
> panel power saving features. However, since they are currently only
> configurable through DRM properties, that isn't possible. So, to remedy
> that issue introduce a new "panel_power_savings" sysfs attribute.
> 
> Cc: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>

Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-by: Mario Limonciello <mario.limonciello@amd.com>

> ---
> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>      commit when setting the value, call sysfs_remove_group() in
>      amdgpu_dm_connector_unregister() and add some documentation.
> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++++++++++++++++++
>   1 file changed, 76 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 8590c9f1dda6..3c62489d03dc 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct drm_connector *connector,
>   	return ret;
>   }
>   
> +/**
> + * DOC: panel power savings
> + *
> + * The display manager allows you to set your desired **panel power savings**
> + * level (between 0-4, with 0 representing off), e.g. using the following::
> + *
> + *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
> + *
> + * Modifying this value can have implications on color accuracy, so tread
> + * carefully.
> + */
> +
> +static ssize_t panel_power_savings_show(struct device *device,
> +					struct device_attribute *attr,
> +					char *buf)
> +{
> +	struct drm_connector *connector = dev_get_drvdata(device);
> +	struct drm_device *dev = connector->dev;
> +	u8 val;
> +
> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> +	val = to_dm_connector_state(connector->state)->abm_level ==
> +		ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
> +		to_dm_connector_state(connector->state)->abm_level;
> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> +	return sysfs_emit(buf, "%u\n", val);
> +}
> +
> +static ssize_t panel_power_savings_store(struct device *device,
> +					 struct device_attribute *attr,
> +					 const char *buf, size_t count)
> +{
> +	struct drm_connector *connector = dev_get_drvdata(device);
> +	struct drm_device *dev = connector->dev;
> +	long val;
> +	int ret;
> +
> +	ret = kstrtol(buf, 0, &val);
> +
> +	if (ret)
> +		return ret;
> +
> +	if (val < 0 || val > 4)
> +		return -EINVAL;
> +
> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> +	to_dm_connector_state(connector->state)->abm_level = val ?:
> +		ABM_LEVEL_IMMEDIATE_DISABLE;
> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> +	drm_kms_helper_hotplug_event(dev);
> +
> +	return count;
> +}
> +
> +static DEVICE_ATTR_RW(panel_power_savings);
> +
> +static struct attribute *amdgpu_attrs[] = {
> +	&dev_attr_panel_power_savings.attr,
> +	NULL
> +};
> +
> +static const struct attribute_group amdgpu_group = {
> +	.name = "amdgpu",
> +	.attrs = amdgpu_attrs
> +};
> +
>   static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>   {
>   	struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector);
>   
> +	sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
>   	drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
>   }
>   
> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)
>   		to_amdgpu_dm_connector(connector);
>   	int r;
>   
> +	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> +		r = sysfs_create_group(&connector->kdev->kobj,
> +				       &amdgpu_group);
> +		if (r)
> +			return r;
> +	}
> +
>   	amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>   
>   	if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
  

On 2024-02-02 11:20, Mario Limonciello wrote:
> On 2/2/2024 09:28, Hamza Mahfooz wrote:
>> We want programs besides the compositor to be able to enable or disable
>> panel power saving features. However, since they are currently only
>> configurable through DRM properties, that isn't possible. So, to remedy
>> that issue introduce a new "panel_power_savings" sysfs attribute.
>>

I've been trying to avoid looking at this too closely, partly because
I want ABM enablement by default, with control for users. But the
more I think about this the more uncomfortable I get. The key for my
discomfort is that we're going around the back of DRM master to set
a DRM property. This is apt to create lots of weird behaviors,
especially if compositors also decide to implement support for the
abm_level property and then potentially fight PPD, or other users
of this sysfs.

I'm also not sure a new sysfs is a good candidate for drm-fixes.

Harry

>> Cc: Mario Limonciello <mario.limonciello@amd.com>
>> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
> 
> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
> Tested-by: Mario Limonciello <mario.limonciello@amd.com>
> 
>> ---
>> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>>      commit when setting the value, call sysfs_remove_group() in
>>      amdgpu_dm_connector_unregister() and add some documentation.
>> ---
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++++++++++++++++++
>>   1 file changed, 76 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 8590c9f1dda6..3c62489d03dc 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct drm_connector *connector,
>>       return ret;
>>   }
>>   +/**
>> + * DOC: panel power savings
>> + *
>> + * The display manager allows you to set your desired **panel power savings**
>> + * level (between 0-4, with 0 representing off), e.g. using the following::
>> + *
>> + *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
>> + *
>> + * Modifying this value can have implications on color accuracy, so tread
>> + * carefully.
>> + */
>> +
>> +static ssize_t panel_power_savings_show(struct device *device,
>> +                    struct device_attribute *attr,
>> +                    char *buf)
>> +{
>> +    struct drm_connector *connector = dev_get_drvdata(device);
>> +    struct drm_device *dev = connector->dev;
>> +    u8 val;
>> +
>> +    drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> +    val = to_dm_connector_state(connector->state)->abm_level ==
>> +        ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
>> +        to_dm_connector_state(connector->state)->abm_level;
>> +    drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>> +    return sysfs_emit(buf, "%u\n", val);
>> +}
>> +
>> +static ssize_t panel_power_savings_store(struct device *device,
>> +                     struct device_attribute *attr,
>> +                     const char *buf, size_t count)
>> +{
>> +    struct drm_connector *connector = dev_get_drvdata(device);
>> +    struct drm_device *dev = connector->dev;
>> +    long val;
>> +    int ret;
>> +
>> +    ret = kstrtol(buf, 0, &val);
>> +
>> +    if (ret)
>> +        return ret;
>> +
>> +    if (val < 0 || val > 4)
>> +        return -EINVAL;
>> +
>> +    drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> +    to_dm_connector_state(connector->state)->abm_level = val ?:
>> +        ABM_LEVEL_IMMEDIATE_DISABLE;
>> +    drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>> +    drm_kms_helper_hotplug_event(dev);
>> +
>> +    return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(panel_power_savings);
>> +
>> +static struct attribute *amdgpu_attrs[] = {
>> +    &dev_attr_panel_power_savings.attr,
>> +    NULL
>> +};
>> +
>> +static const struct attribute_group amdgpu_group = {
>> +    .name = "amdgpu",
>> +    .attrs = amdgpu_attrs
>> +};
>> +
>>   static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>>   {
>>       struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector);
>>   +    sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
>>       drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
>>   }
>>   @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)
>>           to_amdgpu_dm_connector(connector);
>>       int r;
>>   +    if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>> +        r = sysfs_create_group(&connector->kdev->kobj,
>> +                       &amdgpu_group);
>> +        if (r)
>> +            return r;
>> +    }
>> +
>>       amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>>         if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
>
  

On 2/15/2024 11:54, Harry Wentland wrote:
> On 2024-02-02 11:20, Mario Limonciello wrote:
>> On 2/2/2024 09:28, Hamza Mahfooz wrote:
>>> We want programs besides the compositor to be able to enable or disable
>>> panel power saving features. However, since they are currently only
>>> configurable through DRM properties, that isn't possible. So, to remedy
>>> that issue introduce a new "panel_power_savings" sysfs attribute.
>>>
> 
> I've been trying to avoid looking at this too closely, partly because
> I want ABM enablement by default, with control for users. But the
> more I think about this the more uncomfortable I get. The key for my
> discomfort is that we're going around the back of DRM master to set
> a DRM property. This is apt to create lots of weird behaviors,
> especially if compositors also decide to implement support for the
> abm_level property and then potentially fight PPD, or other users
> of this sysfs.

I feel the problem is that specifically both DRM master and sysfs can 
simultaneously fight over the value for ABM.

This isn't a totally new problem because previously the user and DRM
master could fight over this (with the user setting it on command line
and DRM master overriding that).  That was fixed in a follow up patch
though in that the DRM property isn't attached if a user sets the value
on the command line.

I feel the solution to these concerns is that we should make a knob that 
controls whether the DRM property is created or the sysfs file is 
created but not let them happen simultaneously.

We already have amdgpu.abmlevel=-1 is the only time sysfs is created. 
I'd say we should drop the drm property in that case and add a case for 
amdgpu.abmlevel=-2 which will only make the drm property and not the 
sysfs value.  With that done it turns into:

-2  : DRM master is in control
-1  : sysfs is in control.  Software like PPD will tune it as needed.
0-4 : User is in control.
  

On Fri, 2 Feb 2024 10:28:35 -0500
Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:

> We want programs besides the compositor to be able to enable or disable
> panel power saving features.

Could you also explain why, in the commit message, please?

It is unexpected for arbitrary programs to be able to override the KMS
client, and certainly new ways to do so should not be added without an
excellent justification.

Maybe debugfs would be more appropriate if the purpose is only testing
rather than production environments?

> However, since they are currently only
> configurable through DRM properties, that isn't possible. So, to remedy
> that issue introduce a new "panel_power_savings" sysfs attribute.

When the DRM property was added, what was used as the userspace to
prove its workings?


Thanks,
pq

> 
> Cc: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
> ---
> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>     commit when setting the value, call sysfs_remove_group() in
>     amdgpu_dm_connector_unregister() and add some documentation.
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++++++++++++++++++
>  1 file changed, 76 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 8590c9f1dda6..3c62489d03dc 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct drm_connector *connector,
>  	return ret;
>  }
>  
> +/**
> + * DOC: panel power savings
> + *
> + * The display manager allows you to set your desired **panel power savings**
> + * level (between 0-4, with 0 representing off), e.g. using the following::
> + *
> + *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
> + *
> + * Modifying this value can have implications on color accuracy, so tread
> + * carefully.
> + */
> +
> +static ssize_t panel_power_savings_show(struct device *device,
> +					struct device_attribute *attr,
> +					char *buf)
> +{
> +	struct drm_connector *connector = dev_get_drvdata(device);
> +	struct drm_device *dev = connector->dev;
> +	u8 val;
> +
> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> +	val = to_dm_connector_state(connector->state)->abm_level ==
> +		ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
> +		to_dm_connector_state(connector->state)->abm_level;
> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> +	return sysfs_emit(buf, "%u\n", val);
> +}
> +
> +static ssize_t panel_power_savings_store(struct device *device,
> +					 struct device_attribute *attr,
> +					 const char *buf, size_t count)
> +{
> +	struct drm_connector *connector = dev_get_drvdata(device);
> +	struct drm_device *dev = connector->dev;
> +	long val;
> +	int ret;
> +
> +	ret = kstrtol(buf, 0, &val);
> +
> +	if (ret)
> +		return ret;
> +
> +	if (val < 0 || val > 4)
> +		return -EINVAL;
> +
> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> +	to_dm_connector_state(connector->state)->abm_level = val ?:
> +		ABM_LEVEL_IMMEDIATE_DISABLE;
> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> +	drm_kms_helper_hotplug_event(dev);
> +
> +	return count;
> +}
> +
> +static DEVICE_ATTR_RW(panel_power_savings);
> +
> +static struct attribute *amdgpu_attrs[] = {
> +	&dev_attr_panel_power_savings.attr,
> +	NULL
> +};
> +
> +static const struct attribute_group amdgpu_group = {
> +	.name = "amdgpu",
> +	.attrs = amdgpu_attrs
> +};
> +
>  static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>  {
>  	struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector);
>  
> +	sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
>  	drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
>  }
>  
> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)
>  		to_amdgpu_dm_connector(connector);
>  	int r;
>  
> +	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> +		r = sysfs_create_group(&connector->kdev->kobj,
> +				       &amdgpu_group);
> +		if (r)
> +			return r;
> +	}
> +
>  	amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>  
>  	if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
  

On Thu, 15 Feb 2024, Mario Limonciello <mario.limonciello@amd.com> wrote:
> I feel the solution to these concerns is that we should make a knob that 
> controls whether the DRM property is created or the sysfs file is 
> created but not let them happen simultaneously.

*insert the eyeballs emoji here*

I mean no matter what the problem is, this sounds like the solution is
worse than the problem!


BR,
Jani.
  

Am 02.02.24 um 16:28 schrieb Hamza Mahfooz:
> We want programs besides the compositor to be able to enable or disable
> panel power saving features.

Well I don't know the full background, but that is usually a no-go.

> However, since they are currently only
> configurable through DRM properties, that isn't possible.

Maybe I'm repeating others, but I wanted to point it out explicitly: 
This is intentional and not that easily changeable.

If it's a common DRM property, e.g. something standardized among all 
drivers, then amdgpu is not allowed to circumvent that.

Regards,
Christian.

>   So, to remedy
> that issue introduce a new "panel_power_savings" sysfs attribute.
>
> Cc: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
> ---
> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>      commit when setting the value, call sysfs_remove_group() in
>      amdgpu_dm_connector_unregister() and add some documentation.
> ---
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++++++++++++++++++
>   1 file changed, 76 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 8590c9f1dda6..3c62489d03dc 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct drm_connector *connector,
>   	return ret;
>   }
>   
> +/**
> + * DOC: panel power savings
> + *
> + * The display manager allows you to set your desired **panel power savings**
> + * level (between 0-4, with 0 representing off), e.g. using the following::
> + *
> + *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
> + *
> + * Modifying this value can have implications on color accuracy, so tread
> + * carefully.
> + */
> +
> +static ssize_t panel_power_savings_show(struct device *device,
> +					struct device_attribute *attr,
> +					char *buf)
> +{
> +	struct drm_connector *connector = dev_get_drvdata(device);
> +	struct drm_device *dev = connector->dev;
> +	u8 val;
> +
> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> +	val = to_dm_connector_state(connector->state)->abm_level ==
> +		ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
> +		to_dm_connector_state(connector->state)->abm_level;
> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> +	return sysfs_emit(buf, "%u\n", val);
> +}
> +
> +static ssize_t panel_power_savings_store(struct device *device,
> +					 struct device_attribute *attr,
> +					 const char *buf, size_t count)
> +{
> +	struct drm_connector *connector = dev_get_drvdata(device);
> +	struct drm_device *dev = connector->dev;
> +	long val;
> +	int ret;
> +
> +	ret = kstrtol(buf, 0, &val);
> +
> +	if (ret)
> +		return ret;
> +
> +	if (val < 0 || val > 4)
> +		return -EINVAL;
> +
> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> +	to_dm_connector_state(connector->state)->abm_level = val ?:
> +		ABM_LEVEL_IMMEDIATE_DISABLE;
> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> +	drm_kms_helper_hotplug_event(dev);
> +
> +	return count;
> +}
> +
> +static DEVICE_ATTR_RW(panel_power_savings);
> +
> +static struct attribute *amdgpu_attrs[] = {
> +	&dev_attr_panel_power_savings.attr,
> +	NULL
> +};
> +
> +static const struct attribute_group amdgpu_group = {
> +	.name = "amdgpu",
> +	.attrs = amdgpu_attrs
> +};
> +
>   static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>   {
>   	struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector);
>   
> +	sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
>   	drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
>   }
>   
> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)
>   		to_amdgpu_dm_connector(connector);
>   	int r;
>   
> +	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> +		r = sysfs_create_group(&connector->kdev->kobj,
> +				       &amdgpu_group);
> +		if (r)
> +			return r;
> +	}
> +
>   	amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>   
>   	if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
  

On 2/16/24 03:19, Pekka Paalanen wrote:
> On Fri, 2 Feb 2024 10:28:35 -0500
> Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:
> 
>> We want programs besides the compositor to be able to enable or disable
>> panel power saving features.
> 
> Could you also explain why, in the commit message, please?
> 
> It is unexpected for arbitrary programs to be able to override the KMS
> client, and certainly new ways to do so should not be added without an
> excellent justification.
> 
> Maybe debugfs would be more appropriate if the purpose is only testing
> rather than production environments?
> 
>> However, since they are currently only
>> configurable through DRM properties, that isn't possible. So, to remedy
>> that issue introduce a new "panel_power_savings" sysfs attribute.
> 
> When the DRM property was added, what was used as the userspace to
> prove its workings?

To my knowledge, it is only used by IGT. Also, it is worth noting that
it is a vendor specific property, so I doubt there are any compositors
out there that felt motivated enough to use it in any capacity.

> 
> 
> Thanks,
> pq
> 
>>
>> Cc: Mario Limonciello <mario.limonciello@amd.com>
>> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
>> ---
>> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>>      commit when setting the value, call sysfs_remove_group() in
>>      amdgpu_dm_connector_unregister() and add some documentation.
>> ---
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++++++++++++++++++
>>   1 file changed, 76 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 8590c9f1dda6..3c62489d03dc 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct drm_connector *connector,
>>   	return ret;
>>   }
>>   
>> +/**
>> + * DOC: panel power savings
>> + *
>> + * The display manager allows you to set your desired **panel power savings**
>> + * level (between 0-4, with 0 representing off), e.g. using the following::
>> + *
>> + *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
>> + *
>> + * Modifying this value can have implications on color accuracy, so tread
>> + * carefully.
>> + */
>> +
>> +static ssize_t panel_power_savings_show(struct device *device,
>> +					struct device_attribute *attr,
>> +					char *buf)
>> +{
>> +	struct drm_connector *connector = dev_get_drvdata(device);
>> +	struct drm_device *dev = connector->dev;
>> +	u8 val;
>> +
>> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> +	val = to_dm_connector_state(connector->state)->abm_level ==
>> +		ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
>> +		to_dm_connector_state(connector->state)->abm_level;
>> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>> +	return sysfs_emit(buf, "%u\n", val);
>> +}
>> +
>> +static ssize_t panel_power_savings_store(struct device *device,
>> +					 struct device_attribute *attr,
>> +					 const char *buf, size_t count)
>> +{
>> +	struct drm_connector *connector = dev_get_drvdata(device);
>> +	struct drm_device *dev = connector->dev;
>> +	long val;
>> +	int ret;
>> +
>> +	ret = kstrtol(buf, 0, &val);
>> +
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (val < 0 || val > 4)
>> +		return -EINVAL;
>> +
>> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> +	to_dm_connector_state(connector->state)->abm_level = val ?:
>> +		ABM_LEVEL_IMMEDIATE_DISABLE;
>> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>> +	drm_kms_helper_hotplug_event(dev);
>> +
>> +	return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(panel_power_savings);
>> +
>> +static struct attribute *amdgpu_attrs[] = {
>> +	&dev_attr_panel_power_savings.attr,
>> +	NULL
>> +};
>> +
>> +static const struct attribute_group amdgpu_group = {
>> +	.name = "amdgpu",
>> +	.attrs = amdgpu_attrs
>> +};
>> +
>>   static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>>   {
>>   	struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector);
>>   
>> +	sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
>>   	drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
>>   }
>>   
>> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)
>>   		to_amdgpu_dm_connector(connector);
>>   	int r;
>>   
>> +	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>> +		r = sysfs_create_group(&connector->kdev->kobj,
>> +				       &amdgpu_group);
>> +		if (r)
>> +			return r;
>> +	}
>> +
>>   	amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>>   
>>   	if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
>
  

On 2/16/24 03:19, Pekka Paalanen wrote:
> On Fri, 2 Feb 2024 10:28:35 -0500
> Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:
> 
>> We want programs besides the compositor to be able to enable or disable
>> panel power saving features.
> 
> Could you also explain why, in the commit message, please?
> 
> It is unexpected for arbitrary programs to be able to override the KMS
> client, and certainly new ways to do so should not be added without an
> excellent justification.

Also, to be completely honest with you, I'm not sure why it was
initially exposed as a DRM prop, since it's a power management feature.
Which is to say, that it doesn't really make sense to have the
compositor control it.

> 
> Maybe debugfs would be more appropriate if the purpose is only testing
> rather than production environments?
> 
>> However, since they are currently only
>> configurable through DRM properties, that isn't possible. So, to remedy
>> that issue introduce a new "panel_power_savings" sysfs attribute.
> 
> When the DRM property was added, what was used as the userspace to
> prove its workings?
> 
> 
> Thanks,
> pq
> 
>>
>> Cc: Mario Limonciello <mario.limonciello@amd.com>
>> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
>> ---
>> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>>      commit when setting the value, call sysfs_remove_group() in
>>      amdgpu_dm_connector_unregister() and add some documentation.
>> ---
>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++++++++++++++++++
>>   1 file changed, 76 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 8590c9f1dda6..3c62489d03dc 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct drm_connector *connector,
>>   	return ret;
>>   }
>>   
>> +/**
>> + * DOC: panel power savings
>> + *
>> + * The display manager allows you to set your desired **panel power savings**
>> + * level (between 0-4, with 0 representing off), e.g. using the following::
>> + *
>> + *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
>> + *
>> + * Modifying this value can have implications on color accuracy, so tread
>> + * carefully.
>> + */
>> +
>> +static ssize_t panel_power_savings_show(struct device *device,
>> +					struct device_attribute *attr,
>> +					char *buf)
>> +{
>> +	struct drm_connector *connector = dev_get_drvdata(device);
>> +	struct drm_device *dev = connector->dev;
>> +	u8 val;
>> +
>> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> +	val = to_dm_connector_state(connector->state)->abm_level ==
>> +		ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
>> +		to_dm_connector_state(connector->state)->abm_level;
>> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>> +	return sysfs_emit(buf, "%u\n", val);
>> +}
>> +
>> +static ssize_t panel_power_savings_store(struct device *device,
>> +					 struct device_attribute *attr,
>> +					 const char *buf, size_t count)
>> +{
>> +	struct drm_connector *connector = dev_get_drvdata(device);
>> +	struct drm_device *dev = connector->dev;
>> +	long val;
>> +	int ret;
>> +
>> +	ret = kstrtol(buf, 0, &val);
>> +
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (val < 0 || val > 4)
>> +		return -EINVAL;
>> +
>> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> +	to_dm_connector_state(connector->state)->abm_level = val ?:
>> +		ABM_LEVEL_IMMEDIATE_DISABLE;
>> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>> +	drm_kms_helper_hotplug_event(dev);
>> +
>> +	return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(panel_power_savings);
>> +
>> +static struct attribute *amdgpu_attrs[] = {
>> +	&dev_attr_panel_power_savings.attr,
>> +	NULL
>> +};
>> +
>> +static const struct attribute_group amdgpu_group = {
>> +	.name = "amdgpu",
>> +	.attrs = amdgpu_attrs
>> +};
>> +
>>   static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>>   {
>>   	struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector);
>>   
>> +	sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
>>   	drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
>>   }
>>   
>> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)
>>   		to_amdgpu_dm_connector(connector);
>>   	int r;
>>   
>> +	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>> +		r = sysfs_create_group(&connector->kdev->kobj,
>> +				       &amdgpu_group);
>> +		if (r)
>> +			return r;
>> +	}
>> +
>>   	amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>>   
>>   	if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
>
  

On 2024-02-16 03:19, Pekka Paalanen wrote:
> On Fri, 2 Feb 2024 10:28:35 -0500
> Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:
> 
>> We want programs besides the compositor to be able to enable or disable
>> panel power saving features.
> 
> Could you also explain why, in the commit message, please?
> 
> It is unexpected for arbitrary programs to be able to override the KMS
> client, and certainly new ways to do so should not be added without an
> excellent justification.
> 
> Maybe debugfs would be more appropriate if the purpose is only testing
> rather than production environments?
> 
>> However, since they are currently only
>> configurable through DRM properties, that isn't possible. So, to remedy
>> that issue introduce a new "panel_power_savings" sysfs attribute.
> 
> When the DRM property was added, what was used as the userspace to
> prove its workings?
> 

I don't think there ever was a userspace implementation and doubt any
exists today. Part of that is on me. In hindsight, the KMS prop should
have never gone upstream.

I suggest we drop the KMS prop entirely.

As for the color accuracy topic, I think it is important that compositors
can have full control over that if needed, while it's also important
for HW vendors to optimize for power when absolute color accuracy is not
needed. An average end-user writing code or working on their slides
would rather have a longer battery life than a perfectly color-accurate
display. We should probably think of a solution that can support both
use-cases.

Harry

> 
> Thanks,
> pq
> 
>>
>> Cc: Mario Limonciello <mario.limonciello@amd.com>
>> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
>> ---
>> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>>     commit when setting the value, call sysfs_remove_group() in
>>     amdgpu_dm_connector_unregister() and add some documentation.
>> ---
>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++++++++++++++++++
>>  1 file changed, 76 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 8590c9f1dda6..3c62489d03dc 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct drm_connector *connector,
>>  	return ret;
>>  }
>>  
>> +/**
>> + * DOC: panel power savings
>> + *
>> + * The display manager allows you to set your desired **panel power savings**
>> + * level (between 0-4, with 0 representing off), e.g. using the following::
>> + *
>> + *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
>> + *
>> + * Modifying this value can have implications on color accuracy, so tread
>> + * carefully.
>> + */
>> +
>> +static ssize_t panel_power_savings_show(struct device *device,
>> +					struct device_attribute *attr,
>> +					char *buf)
>> +{
>> +	struct drm_connector *connector = dev_get_drvdata(device);
>> +	struct drm_device *dev = connector->dev;
>> +	u8 val;
>> +
>> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> +	val = to_dm_connector_state(connector->state)->abm_level ==
>> +		ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
>> +		to_dm_connector_state(connector->state)->abm_level;
>> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>> +	return sysfs_emit(buf, "%u\n", val);
>> +}
>> +
>> +static ssize_t panel_power_savings_store(struct device *device,
>> +					 struct device_attribute *attr,
>> +					 const char *buf, size_t count)
>> +{
>> +	struct drm_connector *connector = dev_get_drvdata(device);
>> +	struct drm_device *dev = connector->dev;
>> +	long val;
>> +	int ret;
>> +
>> +	ret = kstrtol(buf, 0, &val);
>> +
>> +	if (ret)
>> +		return ret;
>> +
>> +	if (val < 0 || val > 4)
>> +		return -EINVAL;
>> +
>> +	drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> +	to_dm_connector_state(connector->state)->abm_level = val ?:
>> +		ABM_LEVEL_IMMEDIATE_DISABLE;
>> +	drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>> +	drm_kms_helper_hotplug_event(dev);
>> +
>> +	return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(panel_power_savings);
>> +
>> +static struct attribute *amdgpu_attrs[] = {
>> +	&dev_attr_panel_power_savings.attr,
>> +	NULL
>> +};
>> +
>> +static const struct attribute_group amdgpu_group = {
>> +	.name = "amdgpu",
>> +	.attrs = amdgpu_attrs
>> +};
>> +
>>  static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>>  {
>>  	struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector);
>>  
>> +	sysfs_remove_group(&connector->kdev->kobj, &amdgpu_group);
>>  	drm_dp_aux_unregister(&amdgpu_dm_connector->dm_dp_aux.aux);
>>  }
>>  
>> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)
>>  		to_amdgpu_dm_connector(connector);
>>  	int r;
>>  
>> +	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>> +		r = sysfs_create_group(&connector->kdev->kobj,
>> +				       &amdgpu_group);
>> +		if (r)
>> +			return r;
>> +	}
>> +
>>  	amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>>  
>>  	if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||
>
  

On Fri, 16 Feb 2024 09:33:47 -0500
Harry Wentland <harry.wentland@amd.com> wrote:

> On 2024-02-16 03:19, Pekka Paalanen wrote:
> > On Fri, 2 Feb 2024 10:28:35 -0500
> > Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:
> >   
> >> We want programs besides the compositor to be able to enable or disable
> >> panel power saving features.  
> > 
> > Could you also explain why, in the commit message, please?
> > 
> > It is unexpected for arbitrary programs to be able to override the KMS
> > client, and certainly new ways to do so should not be added without an
> > excellent justification.
> > 
> > Maybe debugfs would be more appropriate if the purpose is only testing
> > rather than production environments?
> >   
> >> However, since they are currently only
> >> configurable through DRM properties, that isn't possible. So, to remedy
> >> that issue introduce a new "panel_power_savings" sysfs attribute.  
> > 
> > When the DRM property was added, what was used as the userspace to
> > prove its workings?
> >   
> 
> I don't think there ever was a userspace implementation and doubt any
> exists today. Part of that is on me. In hindsight, the KMS prop should
> have never gone upstream.
> 
> I suggest we drop the KMS prop entirely.

Sounds good. What about the sysfs thing? Should it be a debugfs thing
instead, assuming the below question will be resolved?

> As for the color accuracy topic, I think it is important that compositors
> can have full control over that if needed, while it's also important
> for HW vendors to optimize for power when absolute color accuracy is not
> needed. An average end-user writing code or working on their slides
> would rather have a longer battery life than a perfectly color-accurate
> display. We should probably think of a solution that can support both
> use-cases.

I agree. Maybe this pondering should start from "how would it work from
end user perspective"?

"Automatically" is probably be most desirable answer. Some kind of
desktop settings with options like "save power at the expense of image
quality":
- always
- not if watching movies/gaming
- on battery
- on battery, unless I'm watching movies/gaming
- never

Or maybe there already is something like that, and it only needs to be
plumbed through?

Which would point towards KMS clients needing to control it, which
means a generic KMS prop rather than vendor specific?

Or should the desktop compositor be talking to some daemon instead of
KMS for this? Maybe they already are?


Thanks,
pq
  

On 2024-02-16 10:42, Pekka Paalanen wrote:
> On Fri, 16 Feb 2024 09:33:47 -0500
> Harry Wentland <harry.wentland@amd.com> wrote:
> 
>> On 2024-02-16 03:19, Pekka Paalanen wrote:
>>> On Fri, 2 Feb 2024 10:28:35 -0500
>>> Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:
>>>   
>>>> We want programs besides the compositor to be able to enable or disable
>>>> panel power saving features.  
>>>
>>> Could you also explain why, in the commit message, please?
>>>
>>> It is unexpected for arbitrary programs to be able to override the KMS
>>> client, and certainly new ways to do so should not be added without an
>>> excellent justification.
>>>
>>> Maybe debugfs would be more appropriate if the purpose is only testing
>>> rather than production environments?
>>>   
>>>> However, since they are currently only
>>>> configurable through DRM properties, that isn't possible. So, to remedy
>>>> that issue introduce a new "panel_power_savings" sysfs attribute.  
>>>
>>> When the DRM property was added, what was used as the userspace to
>>> prove its workings?
>>>   
>>
>> I don't think there ever was a userspace implementation and doubt any
>> exists today. Part of that is on me. In hindsight, the KMS prop should
>> have never gone upstream.
>>
>> I suggest we drop the KMS prop entirely.
> 
> Sounds good. What about the sysfs thing? Should it be a debugfs thing
> instead, assuming the below question will be resolved?
> 


It's intended to be used by the power profiles daemon (PPD). I don't think
debugfs is the right choice. See
https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/commit/41ed5d33a82b0ceb7b6d473551eb2aa62cade6bc

>> As for the color accuracy topic, I think it is important that compositors
>> can have full control over that if needed, while it's also important
>> for HW vendors to optimize for power when absolute color accuracy is not
>> needed. An average end-user writing code or working on their slides
>> would rather have a longer battery life than a perfectly color-accurate
>> display. We should probably think of a solution that can support both
>> use-cases.
> 
> I agree. Maybe this pondering should start from "how would it work from
> end user perspective"?
> 
> "Automatically" is probably be most desirable answer. Some kind of

I agree

> desktop settings with options like "save power at the expense of image
> quality":
> - always
> - not if watching movies/gaming
> - on battery
> - on battery, unless I'm watching movies/gaming
> - never
> 

It's interesting that you split out movies/gaming, specifically. AMD's
ABM algorithm seems to have considered movies in particular when
evaluating the power/fidelity trade-off.

I wouldn't think consumer media is very particular about a specific
color fidelity (despite what HDR specs try to make you believe). Where
color fidelity would matter to me is when I'd want to edit pictures or
video.

The "abm_level" property that we expose is really just that, a setting
for the strength of the power-savings effect, with 0 being off and 4 being
maximum strength and power saving, at the expense of fidelity.

Mario's work is to let the PPD control it and set the ABM levels based on
the selected power profile:
0 - Performance
1 - Balance
3 - Power

And I believe we've looked at disabling ABM (setting it to 0) automatically
if we know we're on AC power.

> Or maybe there already is something like that, and it only needs to be
> plumbed through?
> 
> Which would point towards KMS clients needing to control it, which
> means a generic KMS prop rather than vendor specific?
> 
> Or should the desktop compositor be talking to some daemon instead of
> KMS for this? Maybe they already are?
> 

I think the intention is for the PPD to be that daemon. Mario can elaborate.

Harry

> 
> Thanks,
> pq
  

On 2024-02-16 11:11, Harry Wentland wrote:
> 
> 
> On 2024-02-16 10:42, Pekka Paalanen wrote:
>> On Fri, 16 Feb 2024 09:33:47 -0500
>> Harry Wentland <harry.wentland@amd.com> wrote:
>>
>>> On 2024-02-16 03:19, Pekka Paalanen wrote:
>>>> On Fri, 2 Feb 2024 10:28:35 -0500
>>>> Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:
>>>>   
>>>>> We want programs besides the compositor to be able to enable or disable
>>>>> panel power saving features.  
>>>>
>>>> Could you also explain why, in the commit message, please?
>>>>
>>>> It is unexpected for arbitrary programs to be able to override the KMS
>>>> client, and certainly new ways to do so should not be added without an
>>>> excellent justification.
>>>>
>>>> Maybe debugfs would be more appropriate if the purpose is only testing
>>>> rather than production environments?
>>>>   
>>>>> However, since they are currently only
>>>>> configurable through DRM properties, that isn't possible. So, to remedy
>>>>> that issue introduce a new "panel_power_savings" sysfs attribute.  
>>>>
>>>> When the DRM property was added, what was used as the userspace to
>>>> prove its workings?
>>>>   
>>>
>>> I don't think there ever was a userspace implementation and doubt any
>>> exists today. Part of that is on me. In hindsight, the KMS prop should
>>> have never gone upstream.
>>>
>>> I suggest we drop the KMS prop entirely.
>>
>> Sounds good. What about the sysfs thing? Should it be a debugfs thing
>> instead, assuming the below question will be resolved?
>>
> 
> 
> It's intended to be used by the power profiles daemon (PPD). I don't think
> debugfs is the right choice. See
> https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/commit/41ed5d33a82b0ceb7b6d473551eb2aa62cade6bc
> 
>>> As for the color accuracy topic, I think it is important that compositors
>>> can have full control over that if needed, while it's also important
>>> for HW vendors to optimize for power when absolute color accuracy is not
>>> needed. An average end-user writing code or working on their slides
>>> would rather have a longer battery life than a perfectly color-accurate
>>> display. We should probably think of a solution that can support both
>>> use-cases.
>>
>> I agree. Maybe this pondering should start from "how would it work from
>> end user perspective"?
>>
>> "Automatically" is probably be most desirable answer. Some kind of
> 
> I agree
> 
>> desktop settings with options like "save power at the expense of image
>> quality":
>> - always
>> - not if watching movies/gaming
>> - on battery
>> - on battery, unless I'm watching movies/gaming
>> - never
>>
> 
> It's interesting that you split out movies/gaming, specifically. AMD's
> ABM algorithm seems to have considered movies in particular when
> evaluating the power/fidelity trade-off.
> 
> I wouldn't think consumer media is very particular about a specific
> color fidelity (despite what HDR specs try to make you believe). Where
> color fidelity would matter to me is when I'd want to edit pictures or
> video.
> 
> The "abm_level" property that we expose is really just that, a setting
> for the strength of the power-savings effect, with 0 being off and 4 being
> maximum strength and power saving, at the expense of fidelity.
> 
> Mario's work is to let the PPD control it and set the ABM levels based on
> the selected power profile:
> 0 - Performance
> 1 - Balance
> 3 - Power
> 
> And I believe we've looked at disabling ABM (setting it to 0) automatically
> if we know we're on AC power.
> 
>> Or maybe there already is something like that, and it only needs to be
>> plumbed through?
>>
>> Which would point towards KMS clients needing to control it, which
>> means a generic KMS prop rather than vendor specific?
>>
>> Or should the desktop compositor be talking to some daemon instead of
>> KMS for this? Maybe they already are?
>>
> 
> I think the intention is for the PPD to be that daemon. Mario can elaborate.
> 

Some more details and screenshots on how the PPD is expected to work and look:
https://linuxconfig.org/how-to-manage-power-profiles-over-d-bus-with-power-profiles-daemon-on-linux

Harry

> Harry
> 
>>
>> Thanks,
>> pq
>
  

On 2/16/2024 10:13, Harry Wentland wrote:
> 
> 
> On 2024-02-16 11:11, Harry Wentland wrote:
>>
>>
>> On 2024-02-16 10:42, Pekka Paalanen wrote:
>>> On Fri, 16 Feb 2024 09:33:47 -0500
>>> Harry Wentland <harry.wentland@amd.com> wrote:
>>>
>>>> On 2024-02-16 03:19, Pekka Paalanen wrote:
>>>>> On Fri, 2 Feb 2024 10:28:35 -0500
>>>>> Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:
>>>>>    
>>>>>> We want programs besides the compositor to be able to enable or disable
>>>>>> panel power saving features.
>>>>>
>>>>> Could you also explain why, in the commit message, please?
>>>>>
>>>>> It is unexpected for arbitrary programs to be able to override the KMS
>>>>> client, and certainly new ways to do so should not be added without an
>>>>> excellent justification.
>>>>>
>>>>> Maybe debugfs would be more appropriate if the purpose is only testing
>>>>> rather than production environments?
>>>>>    
>>>>>> However, since they are currently only
>>>>>> configurable through DRM properties, that isn't possible. So, to remedy
>>>>>> that issue introduce a new "panel_power_savings" sysfs attribute.
>>>>>
>>>>> When the DRM property was added, what was used as the userspace to
>>>>> prove its workings?
>>>>>    
>>>>
>>>> I don't think there ever was a userspace implementation and doubt any
>>>> exists today. Part of that is on me. In hindsight, the KMS prop should
>>>> have never gone upstream.
>>>>
>>>> I suggest we drop the KMS prop entirely.
>>>
>>> Sounds good. What about the sysfs thing? Should it be a debugfs thing
>>> instead, assuming the below question will be resolved?
>>>
>>
>>
>> It's intended to be used by the power profiles daemon (PPD). I don't think
>> debugfs is the right choice. See
>> https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/commit/41ed5d33a82b0ceb7b6d473551eb2aa62cade6bc
>>
>>>> As for the color accuracy topic, I think it is important that compositors
>>>> can have full control over that if needed, while it's also important
>>>> for HW vendors to optimize for power when absolute color accuracy is not
>>>> needed. An average end-user writing code or working on their slides
>>>> would rather have a longer battery life than a perfectly color-accurate
>>>> display. We should probably think of a solution that can support both
>>>> use-cases.
>>>
>>> I agree. Maybe this pondering should start from "how would it work from
>>> end user perspective"?
>>>
>>> "Automatically" is probably be most desirable answer. Some kind of
>>
>> I agree
>>
>>> desktop settings with options like "save power at the expense of image
>>> quality":
>>> - always
>>> - not if watching movies/gaming
>>> - on battery
>>> - on battery, unless I'm watching movies/gaming
>>> - never
>>>
>>
>> It's interesting that you split out movies/gaming, specifically. AMD's
>> ABM algorithm seems to have considered movies in particular when
>> evaluating the power/fidelity trade-off.
>>
>> I wouldn't think consumer media is very particular about a specific
>> color fidelity (despite what HDR specs try to make you believe). Where
>> color fidelity would matter to me is when I'd want to edit pictures or
>> video.
>>
>> The "abm_level" property that we expose is really just that, a setting
>> for the strength of the power-savings effect, with 0 being off and 4 being
>> maximum strength and power saving, at the expense of fidelity.
>>
>> Mario's work is to let the PPD control it and set the ABM levels based on
>> the selected power profile:
>> 0 - Performance
>> 1 - Balance
>> 3 - Power
>>
>> And I believe we've looked at disabling ABM (setting it to 0) automatically
>> if we know we're on AC power.
>>
>>> Or maybe there already is something like that, and it only needs to be
>>> plumbed through?
>>>
>>> Which would point towards KMS clients needing to control it, which
>>> means a generic KMS prop rather than vendor specific?
>>>
>>> Or should the desktop compositor be talking to some daemon instead of
>>> KMS for this? Maybe they already are?
>>>
>>
>> I think the intention is for the PPD to be that daemon. Mario can elaborate.
>>
> 
> Some more details and screenshots on how the PPD is expected to work and look:
> https://linuxconfig.org/how-to-manage-power-profiles-over-d-bus-with-power-profiles-daemon-on-linux

Right, thanks!

The most important point is that the user indicates intent from the GUI.
The daemon orchestrates the various knobs to get that intent.

It's intentionally very coarse - 3 power states.  The policy of what to 
do for those states is managed by the daemon.

In the case of ABM it will only apply the policy if the daemon detects 
the system is on battery.
  

On Fri, 16 Feb 2024 10:32:10 -0600
Mario Limonciello <mario.limonciello@amd.com> wrote:

> On 2/16/2024 10:13, Harry Wentland wrote:
> > 
> > 
> > On 2024-02-16 11:11, Harry Wentland wrote:  
> >>
> >>
> >> On 2024-02-16 10:42, Pekka Paalanen wrote:  
> >>> On Fri, 16 Feb 2024 09:33:47 -0500
> >>> Harry Wentland <harry.wentland@amd.com> wrote:
> >>>  
> >>>> On 2024-02-16 03:19, Pekka Paalanen wrote:  
> >>>>> On Fri, 2 Feb 2024 10:28:35 -0500
> >>>>> Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:
> >>>>>      
> >>>>>> We want programs besides the compositor to be able to enable or disable
> >>>>>> panel power saving features.  
> >>>>>
> >>>>> Could you also explain why, in the commit message, please?
> >>>>>
> >>>>> It is unexpected for arbitrary programs to be able to override the KMS
> >>>>> client, and certainly new ways to do so should not be added without an
> >>>>> excellent justification.
> >>>>>
> >>>>> Maybe debugfs would be more appropriate if the purpose is only testing
> >>>>> rather than production environments?
> >>>>>      
> >>>>>> However, since they are currently only
> >>>>>> configurable through DRM properties, that isn't possible. So, to remedy
> >>>>>> that issue introduce a new "panel_power_savings" sysfs attribute.  
> >>>>>
> >>>>> When the DRM property was added, what was used as the userspace to
> >>>>> prove its workings?
> >>>>>      
> >>>>
> >>>> I don't think there ever was a userspace implementation and doubt any
> >>>> exists today. Part of that is on me. In hindsight, the KMS prop should
> >>>> have never gone upstream.
> >>>>
> >>>> I suggest we drop the KMS prop entirely.  
> >>>
> >>> Sounds good. What about the sysfs thing? Should it be a debugfs thing
> >>> instead, assuming the below question will be resolved?
> >>>  
> >>
> >>
> >> It's intended to be used by the power profiles daemon (PPD). I don't think
> >> debugfs is the right choice. See
> >> https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/commit/41ed5d33a82b0ceb7b6d473551eb2aa62cade6bc
> >>  
> >>>> As for the color accuracy topic, I think it is important that compositors
> >>>> can have full control over that if needed, while it's also important
> >>>> for HW vendors to optimize for power when absolute color accuracy is not
> >>>> needed. An average end-user writing code or working on their slides
> >>>> would rather have a longer battery life than a perfectly color-accurate
> >>>> display. We should probably think of a solution that can support both
> >>>> use-cases.  
> >>>
> >>> I agree. Maybe this pondering should start from "how would it work from
> >>> end user perspective"?
> >>>
> >>> "Automatically" is probably be most desirable answer. Some kind of  
> >>
> >> I agree
> >>  
> >>> desktop settings with options like "save power at the expense of image
> >>> quality":
> >>> - always
> >>> - not if watching movies/gaming
> >>> - on battery
> >>> - on battery, unless I'm watching movies/gaming
> >>> - never
> >>>  
> >>
> >> It's interesting that you split out movies/gaming, specifically. AMD's
> >> ABM algorithm seems to have considered movies in particular when
> >> evaluating the power/fidelity trade-off.
> >>
> >> I wouldn't think consumer media is very particular about a specific
> >> color fidelity (despite what HDR specs try to make you believe). Where
> >> color fidelity would matter to me is when I'd want to edit pictures or
> >> video.
> >>
> >> The "abm_level" property that we expose is really just that, a setting
> >> for the strength of the power-savings effect, with 0 being off and 4 being
> >> maximum strength and power saving, at the expense of fidelity.
> >>
> >> Mario's work is to let the PPD control it and set the ABM levels based on
> >> the selected power profile:
> >> 0 - Performance
> >> 1 - Balance
> >> 3 - Power
> >>
> >> And I believe we've looked at disabling ABM (setting it to 0) automatically
> >> if we know we're on AC power.
> >>  
> >>> Or maybe there already is something like that, and it only needs to be
> >>> plumbed through?
> >>>
> >>> Which would point towards KMS clients needing to control it, which
> >>> means a generic KMS prop rather than vendor specific?
> >>>
> >>> Or should the desktop compositor be talking to some daemon instead of
> >>> KMS for this? Maybe they already are?
> >>>  
> >>
> >> I think the intention is for the PPD to be that daemon. Mario can elaborate.
> >>  
> > 
> > Some more details and screenshots on how the PPD is expected to work and look:
> > https://linuxconfig.org/how-to-manage-power-profiles-over-d-bus-with-power-profiles-daemon-on-linux  
> 
> Right, thanks!
> 
> The most important point is that the user indicates intent from the GUI.
> The daemon orchestrates the various knobs to get that intent.
> 
> It's intentionally very coarse - 3 power states.  The policy of what to 
> do for those states is managed by the daemon.
> 
> In the case of ABM it will only apply the policy if the daemon detects 
> the system is on battery.
> 

Sounds like sysfs is the best option, and it should never have been a
KMS property, indeed.


Thanks,
pq