Intel-GFX Archive on 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 03/15] drm/i915/pps: Split pps_init_delays() into distinct parts
Date: Tue, 10 May 2022 13:42:30 +0300	[thread overview]
Message-ID: <20220510104242.6099-4-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>

Split each of the hw/vbt/spec PPS delay initialization into
separate functions to make the whole thing less cluttered.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_pps.c | 66 +++++++++++++++++-------
 1 file changed, 48 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_pps.c b/drivers/gpu/drm/i915/display/intel_pps.c
index 5a598dd06039..5b72c892a6f2 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -1159,53 +1159,83 @@ intel_pps_verify_state(struct intel_dp *intel_dp)
 	}
 }
 
-static void pps_init_delays(struct intel_dp *intel_dp)
+static void pps_init_delays_cur(struct intel_dp *intel_dp,
+				struct edp_power_seq *cur)
 {
 	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-	struct edp_power_seq cur, vbt, spec,
-		*final = &intel_dp->pps.pps_delays;
 
 	lockdep_assert_held(&dev_priv->pps_mutex);
 
-	/* already initialized? */
-	if (final->t11_t12 != 0)
-		return;
+	intel_pps_readout_hw_state(intel_dp, cur);
 
-	intel_pps_readout_hw_state(intel_dp, &cur);
+	intel_pps_dump_state(intel_dp, "cur", cur);
+}
 
-	intel_pps_dump_state(intel_dp, "cur", &cur);
+static void pps_init_delays_vbt(struct intel_dp *intel_dp,
+				struct edp_power_seq *vbt)
+{
+	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+	*vbt = dev_priv->vbt.edp.pps;
 
-	vbt = dev_priv->vbt.edp.pps;
 	/* On Toshiba Satellite P50-C-18C system the VBT T12 delay
 	 * of 500ms appears to be too short. Ocassionally the panel
 	 * just fails to power back on. Increasing the delay to 800ms
 	 * seems sufficient to avoid this problem.
 	 */
 	if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
-		vbt.t11_t12 = max_t(u16, vbt.t11_t12, 1300 * 10);
+		vbt->t11_t12 = max_t(u16, vbt->t11_t12, 1300 * 10);
 		drm_dbg_kms(&dev_priv->drm,
 			    "Increasing T12 panel delay as per the quirk to %d\n",
-			    vbt.t11_t12);
+			    vbt->t11_t12);
 	}
+
 	/* T11_T12 delay is special and actually in units of 100ms, but zero
 	 * based in the hw (so we need to add 100 ms). But the sw vbt
 	 * table multiplies it with 1000 to make it in units of 100usec,
 	 * too. */
-	vbt.t11_t12 += 100 * 10;
+	vbt->t11_t12 += 100 * 10;
+
+	intel_pps_dump_state(intel_dp, "vbt", vbt);
+}
+
+static void pps_init_delays_spec(struct intel_dp *intel_dp,
+				 struct edp_power_seq *spec)
+{
+	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+	lockdep_assert_held(&dev_priv->pps_mutex);
 
 	/* Upper limits from eDP 1.3 spec. Note that we use the clunky units of
 	 * our hw here, which are all in 100usec. */
-	spec.t1_t3 = 210 * 10;
-	spec.t8 = 50 * 10; /* no limit for t8, use t7 instead */
-	spec.t9 = 50 * 10; /* no limit for t9, make it symmetric with t8 */
-	spec.t10 = 500 * 10;
+	spec->t1_t3 = 210 * 10;
+	spec->t8 = 50 * 10; /* no limit for t8, use t7 instead */
+	spec->t9 = 50 * 10; /* no limit for t9, make it symmetric with t8 */
+	spec->t10 = 500 * 10;
 	/* This one is special and actually in units of 100ms, but zero
 	 * based in the hw (so we need to add 100 ms). But the sw vbt
 	 * table multiplies it with 1000 to make it in units of 100usec,
 	 * too. */
-	spec.t11_t12 = (510 + 100) * 10;
+	spec->t11_t12 = (510 + 100) * 10;
 
-	intel_pps_dump_state(intel_dp, "vbt", &vbt);
+	intel_pps_dump_state(intel_dp, "spec", spec);
+}
+
+static void pps_init_delays(struct intel_dp *intel_dp)
+{
+	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+	struct edp_power_seq cur, vbt, spec,
+		*final = &intel_dp->pps.pps_delays;
+
+	lockdep_assert_held(&dev_priv->pps_mutex);
+
+	/* already initialized? */
+	if (final->t11_t12 != 0)
+		return;
+
+	pps_init_delays_cur(intel_dp, &cur);
+	pps_init_delays_vbt(intel_dp, &vbt);
+	pps_init_delays_spec(intel_dp, &spec);
 
 	/* Use the max of the register settings and vbt. If both are
 	 * unset, fall back to the spec limits. */
-- 
2.35.1


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

Thread overview: 23+ 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 ` [Intel-gfx] [PATCH 02/15] drm/i915: Extract intel_edp_fixup_vbt_bpp() Ville Syrjala
2022-05-10 10:42 ` Ville Syrjala [this message]
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 ` [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-4-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox