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 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: 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 ` [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   ` 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 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.