From patchwork Fri May 6 10:10:10 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jani Nikula X-Patchwork-Id: 12840923 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DF740C433F5 for ; Fri, 6 May 2022 10:10:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 4BB5310F946; Fri, 6 May 2022 10:10:56 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7163810F946; Fri, 6 May 2022 10:10:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651831855; x=1683367855; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HgeNDGzi+0QMpiQwoNnEG61MqqkOaM1jTupHUWhlaQ8=; b=Ml3i3MfrnOzDRlMEB7YgTNfrwX2A5vNjhY8roevlBvMzLw19EB1zeU1z snetAicEVLWtUGEgIYGBL7hitTtH+CP5ck2NAeTep58TQrXit/UBLbY1K 7sSeyJYh56htl2V1agOHGv1hFyxt8coISnBbugW1U5qS+zSiFACzk44Km AI029g4wz0PlY32Pfo+m60fCzc7XFc8FDQyOZdIWGkMRwlmBTjOdAf2yh 1FiT0RTEpCCgxHEXZm936zeIulGstpMUC9yKGKikJGfVwMzdsc2RYE3K/ K4fDoIBlVZDLH88FHwgBf2+itp1Lg9Lg67Zbtawp7k4fs4QGhSGnMUnWe A==; X-IronPort-AV: E=McAfee;i="6400,9594,10338"; a="248959289" X-IronPort-AV: E=Sophos;i="5.91,203,1647327600"; d="scan'208";a="248959289" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2022 03:10:55 -0700 X-IronPort-AV: E=Sophos;i="5.91,203,1647327600"; d="scan'208";a="735566981" Received: from psikora-mobl.ger.corp.intel.com (HELO localhost) ([10.249.157.88]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2022 03:10:53 -0700 From: Jani Nikula To: dri-devel@lists.freedesktop.org Date: Fri, 6 May 2022 13:10:10 +0300 Message-Id: <263c5eea832947e740cc73b8bb187b91a3f1b79e.1651830938.git.jani.nikula@intel.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Subject: [Intel-gfx] [PATCH 03/25] drm/edid: add struct drm_edid container X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jani.nikula@intel.com, intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Introduce new opaque type struct drm_edid to encapsulate the EDID data and the size allocated for it. The contents will be private to drm_edid.c. There are a number of reasons for adding a container around struct edid: * struct edid is a raw blob pointer to data that usually originates outside of the kernel. Its size is contained within the structure. * There's no way to attach meta information (such as allocated memory size) to struct edid. * Validation of the EDID blob and its size become crucial, and it's spread all over the subsystem, with varying levels of accuracy. * HDMI Forum has introduced an HF-EEODB extension that defines an override EDID size within an EDID extension. The size allocated for an EDID depends on whether the allocator understands the HF-EEODB extension. Given a struct edid *, it's impossible to know how much memory was actually allocated for it. There are also some reasons for making the container type struct drm_edid opaque and private to drm_edid.c: * Have only one place for creating and parsing the EDID, to avoid duplicating bugs. * Prepare for reading a pure DisplayID 2.0 from its own DDC address, and adding it within the same struct drm_edid container, transparently, and for all drivers. * With the idea that the drm_edid objects are immutable during their lifetimes, it will be possible to refcount them and reduce EDID copying everywhere (this is left for future work). Initially, just add the type. In follow-up, we'll start converting the guts of drm_edid.c to use it, and finally add interfaces around it. Signed-off-by: Jani Nikula Reviewed-by: Ankit Nautiyal --- drivers/gpu/drm/drm_edid.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index dcef92c8887a..480fd9fbe412 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -1567,6 +1567,15 @@ static const struct drm_display_mode edid_4k_modes[] = { /*** DDC fetch and block validation ***/ +/* + * The opaque EDID type, internal to drm_edid.c. + */ +struct drm_edid { + /* Size allocated for edid */ + size_t size; + const struct edid *edid; +}; + static int edid_extension_block_count(const struct edid *edid) { return edid->extensions;