kernel/linux.git/drivers/gpu/drm/drm_edid_load.c, branch linux-7.0.y

drm/edid/firmware: Remove built-in EDIDs

2024-02-26T13:05:18+00:00

The EDID firmware loading mechanism introduced a few built-in EDIDs that could be forced on any connector, bypassing the EDIDs it exposes. While convenient, this limited set of EDIDs doesn't take into account the connector type, and we can end up with an EDID that is completely invalid for a given connector. For example, the edid/800x600.bin file matches the following EDID: edid-decode (hex): 00 ff ff ff ff ff ff 00 31 d8 00 00 00 00 00 00 05 16 01 03 6d 1b 14 78 ea 5e c0 a4 59 4a 98 25 20 50 54 01 00 00 45 40 01 01 01 01 01 01 01 01 01 01 01 01 01 01 a0 0f 20 00 31 58 1c 20 28 80 14 00 15 d0 10 00 00 1e 00 00 00 ff 00 4c 69 6e 75 78 20 23 30 0a 20 20 20 20 00 00 00 fd 00 3b 3d 24 26 05 00 0a 20 20 20 20 20 20 00 00 00 fc 00 4c 69 6e 75 78 20 53 56 47 41 0a 20 20 00 c2 ---------------- Block 0, Base EDID: EDID Structure Version & Revision: 1.3 Vendor & Product Identification: Manufacturer: LNX Model: 0 Made in: week 5 of 2012 Basic Display Parameters & Features: Analog display Signal Level Standard: 0.700 : 0.000 : 0.700 V p-p Blank level equals black level Sync: Separate Composite Serration Maximum image size: 27 cm x 20 cm Gamma: 2.20 DPMS levels: Standby Suspend Off RGB color display First detailed timing is the preferred timing Color Characteristics: Red : 0.6416, 0.3486 Green: 0.2919, 0.5957 Blue : 0.1474, 0.1250 White: 0.3125, 0.3281 Established Timings I & II: DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz Standard Timings: DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz Detailed Timing Descriptors: DTD 1: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz (277 mm x 208 mm) Hfront 40 Hsync 128 Hback 88 Hpol P Vfront 1 Vsync 4 Vback 23 Vpol P Display Product Serial Number: 'Linux #0' Display Range Limits: Monitor ranges (GTF): 59-61 Hz V, 36-38 kHz H, max dotclock 50 MHz Display Product Name: 'Linux SVGA' Checksum: 0xc2 So, an analog monitor EDID. However, if the connector was an HDMI monitor for example, it breaks the HDMI specification that requires, among other things, a digital display, the VIC 1 mode and an HDMI Forum Vendor Specific Data Block in an CTA-861 extension. We thus end up with a completely invalid EDID, which thus might confuse HDMI-related code that could parse it. After some discussions on IRC, we identified mainly two ways to fix this: - We can either create more EDIDs for each connector type to provide a built-in EDID that matches the resolution passed in the name, and still be a sensible EDID for that connector type; - Or we can just prevent the EDID to be exposed to userspace if it's built-in. Or possibly both. However, the conclusion was that maybe we just don't need the built-in EDIDs at all and we should just get rid of them. So here we are. Acked-by: Daniel Vetter Acked-by: Jani Nikula Acked-by: Pekka Paalanen Acked-by: Thomas Zimmermann Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240221092636.691701-1-mripard@kernel.org

drm/edid/firmware: drop drm_kms_helper.edid_firmware backward compat

2023-11-21T10:22:48+00:00

Since the edid_firmware module parameter was moved from drm_kms_helper.ko to drm.ko in v4.15, we've had a backwards compatibility helper in place, with a DRM_NOTE() suggesting to migrate to drm.edid_firmware. This was added in commit ac6c35a4d8c7 ("drm: add backwards compatibility support for drm_kms_helper.edid_firmware"). More than five years and 30+ kernel releases later, drop the backward compatibility. v2: Drop the warnings too Acked-by: Daniel Vetter Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20231114151406.61230-1-jani.nikula@intel.com

drm/edid/firmware: stop using a throwaway platform device

2022-11-16T12:54:44+00:00

We've used a temporary platform device for firmware EDID loading since it was introduced in commit da0df92b5731 ("drm: allow loading an EDID as firmware to override broken monitor"), but there's no explanation why. Using a temporary device does not play well with CONFIG_FW_CACHE=y, which caches firmware images (e.g. on suspend) so that drivers can request firmware when the system is not ready for it, and return the images from the cache (e.g. during resume). This works automatically for regular devices, but obviously not for a temporarily created device. Stop using the throwaway platform device, and use the drm device instead. Note that this may still be problematic for cases where the display was plugged in during suspend, and the firmware wasn't loaded and therefore not cached before suspend. References: https://lore.kernel.org/r/20220727074152.43059-1-matthieu.charette@gmail.com Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2061 Reported-by: Matthieu CHARETTE Tested-by: Matthieu CHARETTE Cc: Ville Syrjälä Signed-off-by: Jani Nikula Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20221114111709.434979-1-jani.nikula@intel.com

drm/edid/firmware: convert to drm device specific logging

2022-10-26T06:54:03+00:00

Conform to device specific logging. v2: Include [CONNECTOR:%d:%s] (Ville) Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/14f3a1e55729c9157aae93fc45320d05cc4cc7bc.1666614699.git.jani.nikula@intel.com

drm/edid: move edid load declarations to internal header

2022-10-26T06:53:56+00:00

The EDID loader is internal to drm, not for drivers. Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/d58a59fede286caa8766e0813f4be492a7200287.1666614699.git.jani.nikula@intel.com

drm/edid: use struct drm_edid for override/firmware EDID

2022-10-26T06:53:51+00:00

There's a lot going on here, but the main thing is switching the firmware EDID loader to use struct drm_edid. Unfortunately, it's difficult to reasonably split to smaller pieces. Convert the EDID loader to struct drm_edid. There's a functional change in validation; it no longer tries to fix errors or filter invalid blocks. It's stricter in this sense. Hopefully this will not be an issue. As a by-product, this change also allows HF-EEODB extended EDIDs to be passed via override/firmware EDID. Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/e64267c28eca483e83c802bc06ddd149bdcdfc66.1666614699.git.jani.nikula@intel.com

drm/edid/firmware: rename drm_load_edid_firmware() to drm_edid_load_firmware()

2022-10-26T06:53:46+00:00

Follow the usual naming convention by file name. Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/d6714ae737d789764bd2bdb6e7c9a5f56c99eef3.1666614699.git.jani.nikula@intel.com

drm/edid/firmware: drop redundant connector_name variable/parameter

2022-10-26T06:53:40+00:00

Stop passing around something that's readily available in connector->name. Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/befa53a33f2ea83094027a0e88d155779ad096e1.1666614699.git.jani.nikula@intel.com

drm/print: add drm_debug_enabled()

2019-10-02T13:28:55+00:00

Add helper to check if a drm debug category is enabled. Convert drm core to use it. No functional changes. v2: Move unlikely() to drm_debug_enabled() (Eric) v3: Keep unlikely() when combined with other conditions (Eric) Cc: Eric Engestrom Acked-by: Alex Deucher Reviewed-by: Eric Engestrom Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20191001140614.26909-1-jani.nikula@intel.com

Merge remote-tracking branch 'drm/drm-next' into drm-misc-next

2019-05-28T07:39:08+00:00

This picks up rc2 for us as well. Signed-off-by: Maarten Lankhorst