All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 02/15] drm/i915: Extract intel_edp_fixup_vbt_bpp()
Date: Tue, 10 May 2022 13:42:29 +0300	[thread overview]
Message-ID: <20220510104242.6099-3-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20220510104242.6099-1-ville.syrjala@linux.intel.com>

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

We have the same "override eDP VBT bpp with the current bpp" code
duplciated in two places. Extract it to a helper function.

TODO: Having this in .get_config() is pretty ugly. Should probably
try to move it somewhere else (setup_hw_state()/etc.)...

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/g4x_dp.c    | 22 ++-------------------
 drivers/gpu/drm/i915/display/intel_ddi.c | 22 ++-------------------
 drivers/gpu/drm/i915/display/intel_dp.c  | 25 ++++++++++++++++++++++++
 drivers/gpu/drm/i915/display/intel_dp.h  |  1 +
 4 files changed, 30 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c b/drivers/gpu/drm/i915/display/g4x_dp.c
index 5a957acebfd6..82ad8fe7440c 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -395,26 +395,8 @@ static void intel_dp_get_config(struct intel_encoder *encoder,
 		intel_dotclock_calculate(pipe_config->port_clock,
 					 &pipe_config->dp_m_n);
 
-	if (intel_dp_is_edp(intel_dp) && dev_priv->vbt.edp.bpp &&
-	    pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
-		/*
-		 * This is a big fat ugly hack.
-		 *
-		 * Some machines in UEFI boot mode provide us a VBT that has 18
-		 * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
-		 * unknown we fail to light up. Yet the same BIOS boots up with
-		 * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
-		 * max, not what it tells us to use.
-		 *
-		 * Note: This will still be broken if the eDP panel is not lit
-		 * up by the BIOS, and thus we can't get the mode at module
-		 * load.
-		 */
-		drm_dbg_kms(&dev_priv->drm,
-			    "pipe has %d bpp for eDP panel, overriding BIOS-provided max %d bpp\n",
-			    pipe_config->pipe_bpp, dev_priv->vbt.edp.bpp);
-		dev_priv->vbt.edp.bpp = pipe_config->pipe_bpp;
-	}
+	if (intel_dp_is_edp(intel_dp))
+		intel_edp_fixup_vbt_bpp(encoder, pipe_config->pipe_bpp);
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9e6fa59eabba..333871cf3a2c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3433,26 +3433,8 @@ static void intel_ddi_get_config(struct intel_encoder *encoder,
 	pipe_config->has_audio =
 		intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
 
-	if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.bpp &&
-	    pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
-		/*
-		 * This is a big fat ugly hack.
-		 *
-		 * Some machines in UEFI boot mode provide us a VBT that has 18
-		 * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
-		 * unknown we fail to light up. Yet the same BIOS boots up with
-		 * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
-		 * max, not what it tells us to use.
-		 *
-		 * Note: This will still be broken if the eDP panel is not lit
-		 * up by the BIOS, and thus we can't get the mode at module
-		 * load.
-		 */
-		drm_dbg_kms(&dev_priv->drm,
-			    "pipe has %d bpp for eDP panel, overriding BIOS-provided max %d bpp\n",
-			    pipe_config->pipe_bpp, dev_priv->vbt.edp.bpp);
-		dev_priv->vbt.edp.bpp = pipe_config->pipe_bpp;
-	}
+	if (encoder->type == INTEL_OUTPUT_EDP)
+		intel_edp_fixup_vbt_bpp(encoder, pipe_config->pipe_bpp);
 
 	ddi_dotclock_get(pipe_config);
 
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 8637959b5de2..7db71bcd4c4a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2710,6 +2710,31 @@ static void intel_edp_mso_mode_fixup(struct intel_connector *connector,
 		    DRM_MODE_ARG(mode));
 }
 
+void intel_edp_fixup_vbt_bpp(struct intel_encoder *encoder, int pipe_bpp)
+{
+	struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+	if (dev_priv->vbt.edp.bpp && pipe_bpp > dev_priv->vbt.edp.bpp) {
+		/*
+		 * This is a big fat ugly hack.
+		 *
+		 * Some machines in UEFI boot mode provide us a VBT that has 18
+		 * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
+		 * unknown we fail to light up. Yet the same BIOS boots up with
+		 * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
+		 * max, not what it tells us to use.
+		 *
+		 * Note: This will still be broken if the eDP panel is not lit
+		 * up by the BIOS, and thus we can't get the mode at module
+		 * load.
+		 */
+		drm_dbg_kms(&dev_priv->drm,
+			    "pipe has %d bpp for eDP panel, overriding BIOS-provided max %d bpp\n",
+			    pipe_bpp, dev_priv->vbt.edp.bpp);
+		dev_priv->vbt.edp.bpp = pipe_bpp;
+	}
+}
+
 static void intel_edp_mso_init(struct intel_dp *intel_dp)
 {
 	struct drm_i915_private *i915 = dp_to_i915(intel_dp);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h
index d457e17bdc57..e794d910df56 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -63,6 +63,7 @@ enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
 void intel_edp_backlight_on(const struct intel_crtc_state *crtc_state,
 			    const struct drm_connector_state *conn_state);
 void intel_edp_backlight_off(const struct drm_connector_state *conn_state);
+void intel_edp_fixup_vbt_bpp(struct intel_encoder *encoder, int pipe_bpp);
 void intel_dp_mst_suspend(struct drm_i915_private *dev_priv);
 void intel_dp_mst_resume(struct drm_i915_private *dev_priv);
 int intel_dp_max_link_rate(struct intel_dp *intel_dp);
-- 
2.35.1


  parent reply	other threads:[~2022-05-10 10:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 10:42 [Intel-gfx] [PATCH 00/15] drm/i915/bios: PNPID->panel_type matching Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 01/15] drm/i915: Pass intel_connector to intel_vrr_is_capable() Ville Syrjala
2022-05-10 10:42 ` Ville Syrjala [this message]
2022-05-10 10:42 ` [Intel-gfx] [PATCH 03/15] drm/i915/pps: Split pps_init_delays() into distinct parts Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 04/15] drm/i915/pps: Introduce pps_delays_valid() Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 05/15] drm/i915/pps: Don't apply quirks/etc. to the VBT PPS delays if they haven't been initialized Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 06/15] drm/i915/pps: Stash away original BIOS programmed PPS delays Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 07/15] drm/i915/pps: Split PPS init+sanitize in two Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 08/15] drm/i915/pps: Reinit PPS delays after VBT has been fully parsed Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 09/15] drm/i915/pps: Keep VDD enabled during eDP probe Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 10/15] drm/i915/bios: Split parse_driver_features() into two parts Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 11/15] drm/i915/bios: Split VBT parsing to global vs. panel specific parts Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 12/15] drm/i915/bios: Split VBT data into per-panel vs. global parts Ville Syrjala
2022-05-25  8:44   ` Jani Nikula
2022-05-25 10:40     ` Ville Syrjälä
2022-05-25 10:55       ` Jani Nikula
2022-05-10 10:42 ` [Intel-gfx] [PATCH 13/15] drm/i915/bios: Determine panel type via PNPID match Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 14/15] drm/edid: Extract drm_edid_decode_mfg_id() Ville Syrjala
2022-05-10 10:42   ` Ville Syrjala
2022-05-10 10:42 ` [Intel-gfx] [PATCH 15/15] drm/i915/bios: Dump PNPID and panel name Ville Syrjala
2022-05-11 16:03 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/bios: PNPID->panel_type matching (rev2) Patchwork
2022-05-11 16:23 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-05-11 21:11 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-05-25  8:47 ` [Intel-gfx] [PATCH 00/15] drm/i915/bios: PNPID->panel_type matching Jani Nikula

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=20220510104242.6099-3-ville.syrjala@linux.intel.com \
    --to=ville.syrjala@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.