Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp5649371ybc; Wed, 27 Nov 2019 07:20:52 -0800 (PST) X-Google-Smtp-Source: APXvYqybSyTbg/CnUjZo5HUG0hpGpQjbAq1TjSBMdP3DpfzAgyvF3/u5KCCPDpJOe46+zJ84f1Gt X-Received: by 2002:a17:907:216e:: with SMTP id rl14mr49994478ejb.291.1574868052202; Wed, 27 Nov 2019 07:20:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574868052; cv=none; d=google.com; s=arc-20160816; b=UUdX3oJ6MegdckA37/hTuojog+ywWQzWbfdeA8OFs+9uKt+FoPKmTD+vBS1vW7rrMP 3rbdVtwCQX/UjQ+JWhBLIIP9b6mSiP77tEFHYafoqjc/DcyDWNaVvpTDiWZglnxREZ4+ cQHkCJz1y4voju0r1hI3rKepwmk+pNpByWmbp3JPCYFl2TC8A+i563HAYgf3AzUDf7mu OczRdhL/dDjqj2/0r2jCeefGtsB0H2RH6VwMhlsjDNMafdCES+jhr0SUAMfaRk1kqSX0 CmrSKpUYwiutB6zmVFNLekPZGfJPncu6eqz5U+9lj1r3u0rGL0xY4d1EvpnBvRWorFpa Xp/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=/vJVjrzyZ290o/5qCVAFbPb0BLEgc+oUI1rMeNoppLo=; b=bOyeQs6FXuKsMZwXu4gSw1k0A7SbtL0l0Rc6U7NeUrGQc/CWfojFPiR84BN+FnmECB jBsTRBlg3en6Jx3GoLr9xxQLOXUPHpK9NCMgtVDiBErStbUUH0axpePgg4GMgelAJ2Er fGms4Lze2uiuKKNHKvvQUFOSaqfaM7KOdi/chF3DO9UHuYUtgg65M4CrAZqmz6wxCq79 yeRSetDQoHYTK8WvPIXtv7tq1QRyGNddn5HTU4oIRi+3lwQllKsvHpAvQ2Gp1lldIsZK QDTtWSN2B64lNetbpdvp6SQeIU4WXv+ToR5dZb6LT1l3/mrj0Jb/5KKbEar4JHXPuKCI x90g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k10si9885217edx.350.2019.11.27.07.20.27; Wed, 27 Nov 2019 07:20:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727079AbfK0PRJ (ORCPT + 99 others); Wed, 27 Nov 2019 10:17:09 -0500 Received: from mga05.intel.com ([192.55.52.43]:3353 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726729AbfK0PRI (ORCPT ); Wed, 27 Nov 2019 10:17:08 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2019 07:17:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,249,1571727600"; d="scan'208";a="221009990" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga002.jf.intel.com with SMTP; 27 Nov 2019 07:17:03 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 27 Nov 2019 17:17:03 +0200 Date: Wed, 27 Nov 2019 17:17:03 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Laurentiu Palcu Cc: Uma Shankar , "dri-devel@lists.freedesktop.org" , Daniel Vetter , "linux-kernel@vger.kernel.org" , dl-linux-imx Subject: Re: [PATCH] drm: fix HDR static metadata type field numbering Message-ID: <20191127151703.GJ1208@intel.com> References: <1574865719-24490-1-git-send-email-laurentiu.palcu@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1574865719-24490-1-git-send-email-laurentiu.palcu@nxp.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 27, 2019 at 02:42:35PM +0000, Laurentiu Palcu wrote: > According to CTA-861 specification, HDR static metadata data block allows a > sink to indicate which HDR metadata types it supports by setting the SM_0 to > SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is > indicated by setting the SM_0 bit to 1. > > However, the connector->hdr_sink_metadata.hdmi_type1.metadata_type is always > 0, because hdr_metadata_type() in drm_edid.c checks the wrong bit. > > This patch corrects the HDMI_STATIC_METADATA_TYPE1 bit position. Was confused for a while why this has even been workning, but I guess that's due to userspace populating the metadata infoframe blob correctly even if we misreported the metadata types in the parsed EDID metadata blob. Hmm. Actually on further inspection this all seems to be dead code. The only thing we seem to use from the parsed EDID metadata stuff is eotf bitmask. We check that in drm_hdmi_infoframe_set_hdr_metadata() but we don't check the metadata type. Maybe we should just nuke this EDID parsing stuff entirely? Seems pretty much pointless. > > Signed-off-by: Laurentiu Palcu > --- > include/linux/hdmi.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h > index 9918a6c..216e25e 100644 > --- a/include/linux/hdmi.h > +++ b/include/linux/hdmi.h > @@ -155,7 +155,7 @@ enum hdmi_content_type { > }; > > enum hdmi_metadata_type { > - HDMI_STATIC_METADATA_TYPE1 = 1, > + HDMI_STATIC_METADATA_TYPE1 = 0, > }; > > enum hdmi_eotf { > -- > 2.7.4 -- Ville Syrj?l? Intel