Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [RFC 04/15] drm/i915: Extract opregion vbt capture to its own function
Date: Mon,  8 Jan 2024 15:05:06 -0800	[thread overview]
Message-ID: <20240108230517.1497504-5-radhakrishna.sripada@intel.com> (raw)
In-Reply-To: <20240108230517.1497504-1-radhakrishna.sripada@intel.com>

As part of opregion setup, vbt is extracted from the opregion. Move
the vbt parts of opregion setup into its own function.

Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
---
 drivers/gpu/drm/i915/display/intel_opregion.c | 143 ++++++++++--------
 1 file changed, 76 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c b/drivers/gpu/drm/i915/display/intel_opregion.c
index bd654d773ca7..cf7312cfd94a 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -877,6 +877,81 @@ static int intel_load_vbt_firmware(struct drm_i915_private *dev_priv)
 	return ret;
 }
 
+static int intel_load_opregion_vbt(struct drm_i915_private *i915,
+				   struct intel_opregion *opregion,
+				   struct intel_vbt *vbt)
+{
+	const void *vbt_data;
+	u32 vbt_size;
+	void *base = opregion->header;
+
+	if (intel_load_vbt_firmware(i915) == 0)
+		goto out;
+
+	if (dmi_check_system(intel_no_opregion_vbt))
+		goto out;
+
+	if (opregion->header->over.major >= 2 && opregion->asle &&
+	    opregion->asle->rvda && opregion->asle->rvds) {
+		resource_size_t rvda = opregion->asle->rvda;
+
+		/*
+		 * opregion 2.0: rvda is the physical VBT address.
+		 *
+		 * opregion 2.1+: rvda is unsigned, relative offset from
+		 * opregion base, and should never point within opregion.
+		 */
+		if (opregion->header->over.major > 2 ||
+		    opregion->header->over.minor >= 1) {
+			drm_WARN_ON(&i915->drm, rvda < OPREGION_SIZE);
+
+			rvda += opregion->asls;
+		}
+
+		opregion->rvda = memremap(rvda, opregion->asle->rvds,
+					  MEMREMAP_WB);
+
+		vbt_data = opregion->rvda;
+		vbt_size = opregion->asle->rvds;
+		if (intel_bios_is_valid_vbt(vbt_data, vbt_size)) {
+			drm_dbg_kms(&i915->drm,
+				    "Found valid VBT in ACPI OpRegion (RVDA)\n");
+			vbt->vbt = vbt_data;
+			vbt->vbt_size = vbt_size;
+			goto out;
+		} else {
+			drm_dbg_kms(&i915->drm,
+				    "Invalid VBT in ACPI OpRegion (RVDA)\n");
+			memunmap(opregion->rvda);
+			opregion->rvda = NULL;
+		}
+	}
+
+	vbt_data = base + OPREGION_VBT_OFFSET;
+	/*
+	 * The VBT specification says that if the ASLE ext mailbox is not used
+	 * its area is reserved, but on some CHT boards the VBT extends into the
+	 * ASLE ext area. Allow this even though it is against the spec, so we
+	 * do not end up rejecting the VBT on those boards (and end up not
+	 * finding the LCD panel because of this).
+	 */
+	vbt_size = (opregion->header->mboxes & MBOX_ASLE_EXT) ?
+		OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
+	vbt_size -= OPREGION_VBT_OFFSET;
+	if (intel_bios_is_valid_vbt(vbt_data, vbt_size)) {
+		drm_dbg_kms(&i915->drm,
+			    "Found valid VBT in ACPI OpRegion (Mailbox #4)\n");
+		vbt->vbt = vbt_data;
+		vbt->vbt_size = vbt_size;
+	} else {
+		drm_dbg_kms(&i915->drm,
+			    "Invalid VBT in ACPI OpRegion (Mailbox #4)\n");
+	}
+
+out:
+	return 0;
+}
+
 int intel_opregion_setup(struct drm_i915_private *dev_priv)
 {
 	struct intel_opregion *opregion = &dev_priv->display.opregion;
@@ -886,8 +961,6 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
 	char buf[sizeof(OPREGION_SIGNATURE)];
 	int err = 0;
 	void *base;
-	const void *vbt_data;
-	u32 vbt_size;
 
 	BUILD_BUG_ON(sizeof(struct opregion_header) != 0x100);
 	BUILD_BUG_ON(sizeof(struct opregion_acpi) != 0x100);
@@ -968,71 +1041,7 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
 		drm_dbg(&dev_priv->drm, "Mailbox #2 for backlight present\n");
 	}
 
-	if (intel_load_vbt_firmware(dev_priv) == 0)
-		goto out;
-
-	if (dmi_check_system(intel_no_opregion_vbt))
-		goto out;
-
-	if (opregion->header->over.major >= 2 && opregion->asle &&
-	    opregion->asle->rvda && opregion->asle->rvds) {
-		resource_size_t rvda = opregion->asle->rvda;
-
-		/*
-		 * opregion 2.0: rvda is the physical VBT address.
-		 *
-		 * opregion 2.1+: rvda is unsigned, relative offset from
-		 * opregion base, and should never point within opregion.
-		 */
-		if (opregion->header->over.major > 2 ||
-		    opregion->header->over.minor >= 1) {
-			drm_WARN_ON(&dev_priv->drm, rvda < OPREGION_SIZE);
-
-			rvda += opregion->asls;
-		}
-
-		opregion->rvda = memremap(rvda, opregion->asle->rvds,
-					  MEMREMAP_WB);
-
-		vbt_data = opregion->rvda;
-		vbt_size = opregion->asle->rvds;
-		if (intel_bios_is_valid_vbt(vbt_data, vbt_size)) {
-			drm_dbg_kms(&dev_priv->drm,
-				    "Found valid VBT in ACPI OpRegion (RVDA)\n");
-			vbt->vbt = vbt_data;
-			vbt->vbt_size = vbt_size;
-			goto out;
-		} else {
-			drm_dbg_kms(&dev_priv->drm,
-				    "Invalid VBT in ACPI OpRegion (RVDA)\n");
-			memunmap(opregion->rvda);
-			opregion->rvda = NULL;
-		}
-	}
-
-	vbt_data = base + OPREGION_VBT_OFFSET;
-	/*
-	 * The VBT specification says that if the ASLE ext mailbox is not used
-	 * its area is reserved, but on some CHT boards the VBT extends into the
-	 * ASLE ext area. Allow this even though it is against the spec, so we
-	 * do not end up rejecting the VBT on those boards (and end up not
-	 * finding the LCD panel because of this).
-	 */
-	vbt_size = (mboxes & MBOX_ASLE_EXT) ?
-		OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
-	vbt_size -= OPREGION_VBT_OFFSET;
-	if (intel_bios_is_valid_vbt(vbt_data, vbt_size)) {
-		drm_dbg_kms(&dev_priv->drm,
-			    "Found valid VBT in ACPI OpRegion (Mailbox #4)\n");
-		vbt->vbt = vbt_data;
-		vbt->vbt_size = vbt_size;
-	} else {
-		drm_dbg_kms(&dev_priv->drm,
-			    "Invalid VBT in ACPI OpRegion (Mailbox #4)\n");
-	}
-
-out:
-	return 0;
+	return intel_load_opregion_vbt(dev_priv, opregion, vbt);
 
 err_out:
 	memunmap(base);
-- 
2.34.1


  parent reply	other threads:[~2024-01-08 23:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-08 23:05 [RFC 00/15] VBT read Cleanup Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 01/15] drm/i915: Extract display->vbt_data to a new vbt structure Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 02/15] drm/i915: Move vbt fields from opregion to its own structure Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 03/15] drm/i915: Cache opregion asls pointer Radhakrishna Sripada
2024-01-08 23:05 ` Radhakrishna Sripada [this message]
2024-01-08 23:05 ` [RFC 05/15] drm/i915: Init vbt fields when read from oprom/spi Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 06/15] drm/i915: Classify vbt type based on its residence Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 07/15] drm/i915: Collate vbt cleanup for different types Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 08/15] drm/i915: Make intel_bios_init operate on intel_vbt Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 09/15] drm/i915: Move vbt load from opregion to bios init Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 10/15] drm/i915: Move vbt firmware load into intel_bios_init Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 11/15] drm/i915: Make oprom_get_vbt operate on intel_vbt Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 12/15] drm/i915: Make spi_oprom_get_vbt " Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 13/15] drm/i915: Make intel_load_vbt_firmware " Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 14/15] drm/i915: Kill reduntant vbt_firmware from intel_vbt Radhakrishna Sripada
2024-01-08 23:05 ` [RFC 15/15] drm/i915: Use vbt type to determine its validity Radhakrishna Sripada
2024-01-09  1:58 ` ✗ Fi.CI.SPARSE: warning for VBT read Cleanup Patchwork
2024-01-09  2:17 ` ✓ Fi.CI.BAT: success " Patchwork
2024-01-09 11:57 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-01-10 12:33 ` [RFC 00/15] " Jani Nikula
2024-01-11 22:46   ` Sripada, Radhakrishna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240108230517.1497504-5-radhakrishna.sripada@intel.com \
    --to=radhakrishna.sripada@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox