[PATCH v2 0/3] drm: backlight quirk infrastructure and lower minimum for Framework AMD 13

Hans de Goede hdegoede at redhat.com
Mon Aug 5 12:55:19 UTC 2024


Hi Thomas,

On 6/23/24 10:51 AM, Thomas Weißschuh wrote:
> The value of "min_input_signal" returned from ATIF on a Framework AMD 13
> is "12". This leads to a fairly bright minimum display backlight.
> 
> Add a generic quirk infrastructure for backlight configuration to
> override the settings provided by the firmware.
> Also add amdgpu as a user of that infrastructure and a quirk for the
> Framework 13 matte panel.
> Most likely this will also work for the glossy panel, but I can't test
> that.
> 
> One solution would be a fixed firmware version, but given that the
> problem exists since the release of the hardware, it has been known for
> a month that the hardware can go lower and there was no acknowledgment
> from Framework in any way, I'd like to explore this alternative
> way forward.
> 
> Notes:
> 
> * Should the quirk infrastructure be part of drm_edid.c?
> * The current allocation of struct drm_edid in amdgpu is bad.
>   But it is done the same way in other parts of amdgpu.
>   I do have patches migrating amdgpu to proper usage of struct drm_edid [0]

So now that we have agreed to move forward with this approach one
generic design issue / question which popped into my head is:

What happens if i915 also gets support for the minimum brightness quirk?

Specifically the panel used on the framework 13 will match the quirk
independent of which GPU driver is used. But does say a minimum value
of "5" have the same meaning / results in the same minimum duty-cycle
when used by the i915 code vs the amdgpu code ?

I know that the actual quirk sets the min pwm to 0, which presumably results
in a 0% duty cycle on both i915 and amdgpu, but I'm worried what happens
if we see the same panel used in designs which can have it attached to
different vendor GPUs, how should the GPU driver interpret the
pwm_min_brightness value so that it is interpretted consistently between
drivers ? 

I guess this is covered by the docbook saying that min-brightness is on
a 0-255 brightness scale (with 255 being 100%) though ?  Just making sure
that everyone has agreement on that being the scale and that drivers
should not directly take this value but scale it as necessary.
This should also (scale it as necessary) be explicitly mentioned in
the docs IMHO.

Regards,

Hans






> Mario:
> 
> I intentionally left out the consideration of the firmware version.
> The quirk will stay correct even if the firmware starts reporting
> correct values.
> If there are strong opinions it would be easy to add, though.
> 
> Based on amdgpu/drm-next.
> 
> [0] https://lore.kernel.org/lkml/20240616-amdgpu-edid-bios-v1-1-2874f212b365@weissschuh.net/
> 
> ---
> Changes in v2:
> - Introduce proper drm backlight quirk infrastructure
> - Quirk by EDID and DMI instead of only DMI
> - Limit quirk to only single Framework 13 matte panel
> - Link to v1: https://lore.kernel.org/r/20240610-amdgpu-min-backlight-quirk-v1-1-8459895a5b2a@weissschuh.net
> 
> ---
> Thomas Weißschuh (3):
>       drm: Add panel backlight quirks
>       drm: panel-backlight-quirks: Add Framework 13 matte panel
>       drm/amd/display: Add support backlight quirks
> 
>  Documentation/gpu/drm-kms-helpers.rst             |  3 +
>  drivers/gpu/drm/Kconfig                           |  4 ++
>  drivers/gpu/drm/Makefile                          |  1 +
>  drivers/gpu/drm/amd/amdgpu/Kconfig                |  1 +
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 28 +++++++++
>  drivers/gpu/drm/drm_panel_backlight_quirks.c      | 76 +++++++++++++++++++++++
>  include/drm/drm_utils.h                           | 11 ++++
>  7 files changed, 124 insertions(+)
> ---
> base-commit: 1ecef5589320fd56af599b624d59c355d162ac7b
> change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a
> 
> Best regards,



More information about the dri-devel mailing list