From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/i915: Sanity check PPS HW state
Date: Thu, 16 Jun 2016 17:01:24 +0300 [thread overview]
Message-ID: <20160616140124.GD4329@intel.com> (raw)
In-Reply-To: <1466084243-5388-5-git-send-email-imre.deak@intel.com>
On Thu, Jun 16, 2016 at 04:37:23PM +0300, Imre Deak wrote:
> The wait for panel status helper will only function correctly if the
> HW panel timings are programmed correctly. Returning prematurely from
> this helper may lead to obscure bugs later, so sanity check the HW
> timing registers.
>
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 40 ++++++++++++++++++++++++++++++++++++----
> 1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index caad825..163dcad 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1772,6 +1772,9 @@ static void intel_dp_prepare(struct intel_encoder *encoder)
> #define IDLE_CYCLE_MASK (PP_ON | PP_SEQUENCE_MASK | PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK)
> #define IDLE_CYCLE_VALUE (0 | PP_SEQUENCE_NONE | 0 | PP_SEQUENCE_STATE_OFF_IDLE)
>
> +static void intel_pps_verify_state(struct drm_i915_private *dev_priv,
> + struct intel_dp *intel_dp);
> +
> static void wait_panel_status(struct intel_dp *intel_dp,
> u32 mask,
> u32 value)
> @@ -1782,6 +1785,8 @@ static void wait_panel_status(struct intel_dp *intel_dp,
>
> lockdep_assert_held(&dev_priv->pps_mutex);
>
> + intel_pps_verify_state(dev_priv, intel_dp);
> +
> pp_stat_reg = _pp_stat_reg(intel_dp);
> pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
>
> @@ -4821,6 +4826,35 @@ intel_pps_readout_hw_state(struct drm_i915_private *dev_priv,
> }
>
> static void
> +intel_pps_dump_state(const char *state_name, const struct edp_power_seq *seq)
> +{
> + DRM_DEBUG_KMS("%s t1_t3 %d t8 %d t9 %d t10 %d t11_t12 %d\n",
> + state_name,
> + seq->t1_t3, seq->t8, seq->t9, seq->t10, seq->t11_t12);
> +}
> +
> +static void
> +intel_pps_verify_state(struct drm_i915_private *dev_priv,
> + struct intel_dp *intel_dp)
> +{
> + struct edp_power_seq hw;
> + struct edp_power_seq *sw = &intel_dp->pps_delays;
> +
> + intel_pps_readout_hw_state(dev_priv, intel_dp, &hw);
> +
> + /*
> + * We don't use/program the HW T8 and T9 timings as we use SW based
> + * delays for these, so the HW state of these fields are dont-care.
> + */
I don't think they should be treated as "don't care". We want them to
be 1 to avoid needless delays.
> + if (hw.t1_t3 != sw->t1_t3 || hw.t10 != sw->t10 ||
> + hw.t11_t12 != sw->t11_t12) {
> + DRM_ERROR("PPS state mismatch\n");
> + intel_pps_dump_state("sw", sw);
> + intel_pps_dump_state("hw", &hw);
> + }
> +}
> +
> +static void
> intel_dp_init_panel_power_sequencer(struct drm_device *dev,
> struct intel_dp *intel_dp)
> {
> @@ -4836,8 +4870,7 @@ intel_dp_init_panel_power_sequencer(struct drm_device *dev,
>
> intel_pps_readout_hw_state(dev_priv, intel_dp, &cur);
>
> - DRM_DEBUG_KMS("cur t1_t3 %d t8 %d t9 %d t10 %d t11_t12 %d\n",
> - cur.t1_t3, cur.t8, cur.t9, cur.t10, cur.t11_t12);
> + intel_pps_dump_state("cur", &cur);
>
> vbt = dev_priv->vbt.edp.pps;
>
> @@ -4853,8 +4886,7 @@ intel_dp_init_panel_power_sequencer(struct drm_device *dev,
> * too. */
> spec.t11_t12 = (510 + 100) * 10;
>
> - DRM_DEBUG_KMS("vbt t1_t3 %d t8 %d t9 %d t10 %d t11_t12 %d\n",
> - vbt.t1_t3, vbt.t8, vbt.t9, vbt.t10, vbt.t11_t12);
> + intel_pps_dump_state("vbt", &vbt);
>
> /* Use the max of the register settings and vbt. If both are
> * unset, fall back to the spec limits. */
> --
> 2.5.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-06-16 14:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 13:37 [PATCH 0/4] drm/i915/bxt: Fix eDP link training after suspend Imre Deak
2016-06-16 13:37 ` [PATCH 1/4] drm/i915/bxt: Fix PPS lost state after suspend breaking eDP link training Imre Deak
2016-06-16 13:58 ` Ville Syrjälä
2016-06-16 14:39 ` Imre Deak
2016-06-16 14:48 ` Ville Syrjälä
2016-06-16 13:37 ` [PATCH 2/4] drm/i915: Deduplicate PPS register retrieval Imre Deak
2016-06-16 13:37 ` [PATCH 3/4] drm/i915: Factor out helper to read out PPS HW state Imre Deak
2016-06-16 13:37 ` [PATCH 4/4] drm/i915: Sanity check " Imre Deak
2016-06-16 14:01 ` Ville Syrjälä [this message]
2016-06-16 15:56 ` Imre Deak
2016-06-16 17:01 ` [PATCH v2 " Imre Deak
2016-06-16 13:56 ` ✗ Ro.CI.BAT: warning for drm/i915/bxt: Fix eDP link training after suspend Patchwork
2016-06-16 18:37 ` [PATCH 0/4] " Ville Syrjälä
2016-06-17 5:21 ` ✗ Ro.CI.BAT: failure for drm/i915/bxt: Fix eDP link training after suspend (rev2) Patchwork
2016-06-22 16:45 ` Imre Deak
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=20160616140124.GD4329@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=imre.deak@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