Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp832654pxb; Wed, 6 Apr 2022 01:09:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyJ2A0ociyJfh3hVqDfunwOXcXR7Vm55U2xgSMVAGXs6w9eMxg3icRUjqMGgieyatnoII9C X-Received: by 2002:a17:902:ea10:b0:156:5b18:7599 with SMTP id s16-20020a170902ea1000b001565b187599mr7442410plg.19.1649232591130; Wed, 06 Apr 2022 01:09:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649232591; cv=none; d=google.com; s=arc-20160816; b=MhdUikhjLrEdvd+GWGNsp8XV9DZ51ztigGxk7KdaNwRdrCj+Dx+hGsmsx5yUKeViOg I86xCsRdxr7T0jyPFDSYRpNrKsyHI9rhDcUw1WpBK9cNU9g/csqOLZgjOFvkQUV3CEwS i43H+X26CCOu6wo5FvS6o5JdD2EBeq4xaD2xhlGzHFkZOuIGLFpV12AaiYUaRpHGNYA9 H33cUaMkbYLcB52DvoiQAHOtxhCfm33Y3TKzdl+9gXm2Sjp+51eAQDrrw7DmcBbbInw2 gn4qefHn63A+xFfKpUxxZ4trtNWsxFxecDTn7hiax0rMpgnbDvZ3biVsULiEplW20ZMF gZmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=iaf/cVxuTb3Z6ypxiM8HvCO1fBOmfOOdfHhBqU9kw9s=; b=fcLVNuDuHOv78OvdhJR7+CLmKP4iqR4ZbHndiQ1b+ORM9Zxnrb4jCM+zWL+LTjxGGb YAfjlN9uzp7pJxJ2Iz7JXl4zkAXny93d46iuaLtvA3ojBOsrAnFqt+l2vI0HxFyDQo9/ BkyqOnj0M6UXX2aFb8aO2W66n9u9CnVtYYMsSvngDx2Rd59UKgsgMm9GEiMRMH6lsaLR vAyz5CaEVicY7+Em7lJDNYd76guATvYqu8m1rFK9j5eKieLn6lQJusxq01XUE6KOQKZu 6Xps1/IuevFxMhZNroAmCcexSBRWjXS/Fbkbj2nUT8ctl+Ps/SOjGL75JYi3NB7KkPP6 iETQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=THNra1Ve; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id u5-20020a170902714500b001544c952660si14047707plm.353.2022.04.06.01.09.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 01:09:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=THNra1Ve; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F2B0B541E3D; Wed, 6 Apr 2022 00:39:12 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1587342AbiDFAIp (ORCPT + 99 others); Tue, 5 Apr 2022 20:08:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348828AbiDEJsk (ORCPT ); Tue, 5 Apr 2022 05:48:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1CAEB0A7B; Tue, 5 Apr 2022 02:36:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 780BB61368; Tue, 5 Apr 2022 09:36:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86E32C385A0; Tue, 5 Apr 2022 09:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649151382; bh=KbOJmrCYI/tPWvMS0mNsAb+2B9qS9w9YvfcfjYDuH/0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=THNra1VeHIPHiwJI+5L9FRaqLVNgNBEGwt7bYr2eDnzA/S6dbdnhpS9tsBUdtxYsS 5DLS9lJm6NRTGLh2E83qLrNDyywYJp3LQTlFRe3Jc5D6u5e+JhjtNBKpLqnfSYKvK6 UJ+v6NiAWM8FF3xKVa5E/ImgKt2NqiA8cOhN6sdY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maxime Ripard , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Sasha Levin Subject: [PATCH 5.15 395/913] drm/edid: Dont clear formats if using deep color Date: Tue, 5 Apr 2022 09:24:17 +0200 Message-Id: <20220405070351.688043605@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070339.801210740@linuxfoundation.org> References: <20220405070339.801210740@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Maxime Ripard [ 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 Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-3-maxime@cerno.tech Signed-off-by: Sasha Levin --- drivers/gpu/drm/drm_edid.c | 8 -------- 1 file changed, 8 deletions(-) --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -5033,16 +5033,8 @@ static void drm_parse_hdmi_deep_color_in 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); }