Patch "drm/edid: Don't clear formats if using deep color" has been added to the 5.17-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    drm/edid: Don't clear formats if using deep color

to the 5.17-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     drm-edid-don-t-clear-formats-if-using-deep-color.patch
and it can be found in the queue-5.17 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 276a1610979b550610dc7b012157f0d7682be391
Author: Maxime Ripard <maxime@xxxxxxxxxx>
Date:   Thu Jan 20 16:16:11 2022 +0100

    drm/edid: Don't clear formats if using deep color
    
    [ Upstream commit 75478b3b393bcbdca4e6da76fe3a9f1a4133ec5d ]
    
    The current code, when parsing the EDID Deep Color depths, that the
    YUV422 cannot be used, referring to the HDMI 1.3 Specification.
    
    This specification, in its section 6.2.4, indeed states:
    
      For each supported Deep Color mode, RGB 4:4:4 shall be supported and
      optionally YCBCR 4:4:4 may be supported.
    
      YCBCR 4:2:2 is not permitted for any Deep Color mode.
    
    This indeed can be interpreted like the code does, but the HDMI 1.4
    specification further clarifies that statement in its section 6.2.4:
    
      For each supported Deep Color mode, RGB 4:4:4 shall be supported and
      optionally YCBCR 4:4:4 may be supported.
    
      YCBCR 4:2:2 is also 36-bit mode but does not require the further use
      of the Deep Color modes described in section 6.5.2 and 6.5.3.
    
    This means that, even though YUV422 can be used with 12 bit per color,
    it shouldn't be treated as a deep color mode.
    
    This is also broken with YUV444 if it's supported by the display, but
    DRM_EDID_HDMI_DC_Y444 isn't set. In such a case, the code will clear
    color_formats of the YUV444 support set previously in
    drm_parse_cea_ext(), but will not set it back.
    
    Since the formats supported are already setup properly in
    drm_parse_cea_ext(), let's just remove the code modifying the formats in
    drm_parse_hdmi_deep_color_info()
    
    Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.")
    Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx>
    Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
    Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-3-maxime@xxxxxxxxxx
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 32624217b8ee..86a7c4a5253f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5105,16 +5105,8 @@ static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
 		  connector->name, dc_bpc);
 	info->bpc = dc_bpc;
 
-	/*
-	 * Deep color support mandates RGB444 support for all video
-	 * modes and forbids YCRCB422 support for all video modes per
-	 * HDMI 1.3 spec.
-	 */
-	info->color_formats = DRM_COLOR_FORMAT_RGB444;
-
 	/* YCRCB444 is optional according to spec. */
 	if (hdmi[6] & DRM_EDID_HDMI_DC_Y444) {
-		info->color_formats |= DRM_COLOR_FORMAT_YCRCB444;
 		DRM_DEBUG("%s: HDMI sink does YCRCB444 in deep color.\n",
 			  connector->name);
 	}



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux