Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3117438pxm; Mon, 28 Feb 2022 12:23:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJxhFNyUS5leksYYkSneN6/WTYE25LDdoqSorv07ogbTx0UwoM7JaAnGPhs5RTjs2w5Sme7e X-Received: by 2002:a17:902:d2ce:b0:151:6781:affa with SMTP id n14-20020a170902d2ce00b001516781affamr7146098plc.168.1646079794449; Mon, 28 Feb 2022 12:23:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646079794; cv=none; d=google.com; s=arc-20160816; b=hmBNTPKWIDORMqQ5nlFz3OQRlYZ6MuA0AaSCuMAEn9vdpbPAg9GhpskYPdQypH+Zp8 JDAfYZst2iFTfHUaznp7tRQa8A1zt0d5JGrVqjMmxvH0Dyg3AXdWFHElnW6jDa1oluOn SblsrlZ9m/2Umhl6hlrGY9scg7UbWM/nWQoWiLj6Yws6adzJB0LiPKm+58oywywdcw1c cRymLFpafkN1UfAyyHUXmcnUhN2YjfVyBa+lYdmByHMZ53WV9/zMiGR/KaUuZsH9eugX OeZiifwofs7zUwyPu9faw3VpC/ZZMb5qe+iIXWHLNFilielit7J/m6voPIeN36okcd5I Ozxw== 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=Tfx+w0Buix/Dlpb6KxdD8umvcdr/lbWe/ibppTuto68=; b=CZ1MNLhZGSDAjMyL2agDkIlLD29wUzypYYmVPT25cQFwdsav/vRH9kghsk6Ejhxwrb WbAixdypqPRuKRCOPHIw+fuhIY22pJg2XwuAU+c2DLMqf7OBE4MgZhIEJgT+D0++9oNd nO7N5hFScCIfOTnsKkBUxkplYszPNCOAxRSnXp7KC4tqZ5BZATAISiRl+4wRIzLsTIM5 FvmxGgHzVMEi2ErKXdHac+gBSJDnWWvnK/11xdSJJyM2S/cFPwEAqM9rCpv8/Q1mQcS9 wnyhsm6JfYwd/sdoueyF9mQcGntR8CGk4NZAHnTkvSaSy4NbhBpB+wIB2oNuPutZSCdP f2BA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=fS3skHyu; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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. [23.128.96.19]) by mx.google.com with ESMTPS id q5-20020a056a00150500b004e1676c82b8si9958770pfu.356.2022.02.28.12.23.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 12:23:14 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=fS3skHyu; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 E595C1CD9E1; Mon, 28 Feb 2022 11:42:24 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237337AbiB1Rc0 (ORCPT + 99 others); Mon, 28 Feb 2022 12:32:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237215AbiB1RbW (ORCPT ); Mon, 28 Feb 2022 12:31:22 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 020C57E084; Mon, 28 Feb 2022 09:28:41 -0800 (PST) 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 936DA612FA; Mon, 28 Feb 2022 17:28:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E91FC340E7; Mon, 28 Feb 2022 17:28:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646069321; bh=AXvA+n8YacUzFk7uoggoy1tWSaMT5KiqwlSkDctv1jw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fS3skHyu5Ggk4gFXOfP0rfdZ2XPkMABGjJxNXW9SUJVkGb2WY1Po33iolXp0J38ud HBSCtpl2euKhN+jjg7rFEa1xPFARWg4O1pBCupSV5+5TbnB9dByrdCwZg+0Vh4+FBt 2mOmVYlBICrq5kvwSxdzpK+PeZqq/txm5bt5Rba8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Matthias Reichl , Maxime Ripard Subject: [PATCH 4.19 12/34] drm/edid: Always set RGB444 Date: Mon, 28 Feb 2022 18:24:18 +0100 Message-Id: <20220228172209.451489408@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220228172207.090703467@linuxfoundation.org> References: <20220228172207.090703467@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.4 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=unavailable 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 commit ecbd4912a693b862e25cba0a6990a8c95b00721e upstream. In order to fill the drm_display_info structure each time an EDID is read, the code currently will call drm_add_display_info with the parsed EDID. drm_add_display_info will then call drm_reset_display_info to reset all the fields to 0, and then set them to the proper value depending on the EDID. In the color_formats case, we will thus report that we don't support any color format, and then fill it back with RGB444 plus the additional formats described in the EDID Feature Support byte. However, since that byte only contains format-related bits since the 1.4 specification, this doesn't happen if the EDID is following an earlier specification. In turn, it means that for one of these EDID, we end up with color_formats set to 0. The EDID 1.3 specification never really specifies what it means by RGB exactly, but since both HDMI and DVI will use RGB444, it's fairly safe to assume it's supposed to be RGB444. Let's move the addition of RGB444 to color_formats earlier in drm_add_display_info() so that it's always set for a digital display. Fixes: da05a5a71ad8 ("drm: parse color format support for digital displays") Cc: Ville Syrjälä Reported-by: Matthias Reichl Signed-off-by: Maxime Ripard Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220203115416.1137308-1-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/drm_edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4622,6 +4622,7 @@ u32 drm_add_display_info(struct drm_conn if (!(edid->input & DRM_EDID_INPUT_DIGITAL)) return quirks; + info->color_formats |= DRM_COLOR_FORMAT_RGB444; drm_parse_cea_ext(connector, edid); /* @@ -4670,7 +4671,6 @@ u32 drm_add_display_info(struct drm_conn DRM_DEBUG("%s: Assigning EDID-1.4 digital sink color depth as %d bpc.\n", connector->name, info->bpc); - info->color_formats |= DRM_COLOR_FORMAT_RGB444; if (edid->features & DRM_EDID_FEATURE_RGB_YCRCB444) info->color_formats |= DRM_COLOR_FORMAT_YCRCB444; if (edid->features & DRM_EDID_FEATURE_RGB_YCRCB422)