From patchwork Wed Jun 21 10:34:00 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Sharma, Shashank" X-Patchwork-Id: 9801475 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 5C133600C5 for ; Wed, 21 Jun 2017 10:31:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4C8CE2851D for ; Wed, 21 Jun 2017 10:31:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 415EF28591; Wed, 21 Jun 2017 10:31:19 +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=ham 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 0341B2851D for ; Wed, 21 Jun 2017 10:31:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2D9906E508; Wed, 21 Jun 2017 10:31:18 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id EE7136E3DE; Wed, 21 Jun 2017 10:31:14 +0000 (UTC) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP; 21 Jun 2017 03:31:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,368,1493708400"; d="scan'208";a="101956397" Received: from shashanks-linuxbox.iind.intel.com ([10.223.161.29]) by orsmga002.jf.intel.com with ESMTP; 21 Jun 2017 03:31:12 -0700 From: Shashank Sharma To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, ville.syrjala@linux.intel.com Date: Wed, 21 Jun 2017 16:04:00 +0530 Message-Id: <1498041253-16426-3-git-send-email-shashank.sharma@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1498041253-16426-1-git-send-email-shashank.sharma@intel.com> References: <1498041253-16426-1-git-send-email-shashank.sharma@intel.com> Subject: [Intel-gfx] [RESEND-CI v4 02/15] drm: add YCBCR 420 capability identifier X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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 Reviewed-by: Neil Armstrong --- 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.