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@xxxxxxxxxxxxxx/ > > --- > 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@xxxxxxxxxxxxxx > > --- > 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,
