From patchwork Mon Jun 19 16:08:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Sharma, Shashank" X-Patchwork-Id: 9796615 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4843D600C5 for ; Mon, 19 Jun 2017 16:05:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 374D3271CB for ; Mon, 19 Jun 2017 16:05:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2BF36262FF; Mon, 19 Jun 2017 16:05:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id F1806262FF for ; Mon, 19 Jun 2017 16:05:29 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EAD016E1DD; Mon, 19 Jun 2017 16:05:21 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id F271E6E1D2; Mon, 19 Jun 2017 16:05:20 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2017 09:05:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.39,361,1493708400"; d="scan'208"; a="1162219193" Received: from shashanks-linuxbox.iind.intel.com ([10.223.161.29]) by fmsmga001.fm.intel.com with ESMTP; 19 Jun 2017 09:05:18 -0700 From: Shashank Sharma To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, ville.syrjala@linux.intel.com Subject: [PATCH v4 02/15] drm: add YCBCR 420 capability identifier Date: Mon, 19 Jun 2017 21:38:09 +0530 Message-Id: <1497888502-24980-3-git-send-email-shashank.sharma@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1497888502-24980-1-git-send-email-shashank.sharma@intel.com> References: <1497888502-24980-1-git-send-email-shashank.sharma@intel.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP This patch adds a bool variable (ycbcr_420_allowed) in the drm connector structure. While handling the EDID from HDMI 2.0 sinks, its important to know if the source is capable of handling YCBCR 420 outputs or not, so that a lot of work can be done/bypassed based on this information. One such example is adding YCBCR420 only modes. If the driver knows that this source is not HDMI 2.0 capable, it will not add YCBCR420-only modes while adding EDID modes, and will prevent any runtime modeset failures. This variable will be initialized from I915 driver in the next patch and will be used in the EDID handling for HDMI 2.0 specific features, in this same series. V3: introduced the new variable V4: changed variable name from is_hdmi2_src to ycbcr_420_allowed (Ville) Signed-off-by: Shashank Sharma --- include/drm/drm_connector.h | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index d8bb25f..7493fd3 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -728,6 +728,15 @@ struct drm_connector { bool interlace_allowed; bool doublescan_allowed; bool stereo_allowed; + + /** + * @ycbcr_420_allowed : This bool indicates if this connector is + * capable of handling YCBCR 420 output. While parsing the EDID + * blocks, its very helpful to know, if the source is capable of + * handling YCBCR 420 outputs. + */ + bool ycbcr_420_allowed; + /** * @registered: Is this connector exposed (registered) with userspace? * Protected by @mutex.