From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 1/3] drm/i915: add asserts for cursor state in crtc mode set
Date: Wed, 4 Sep 2013 15:11:22 +0300 [thread overview]
Message-ID: <20130904121122.GQ11428@intel.com> (raw)
In-Reply-To: <1378293610-26631-1-git-send-email-jani.nikula@intel.com>
On Wed, Sep 04, 2013 at 02:20:08PM +0300, Jani Nikula wrote:
> The cursor is supposed to be disabled during crtc mode set (disabled by
> ctrc disable). Assert this is the case.
>
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/i915/intel_display.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index d88057e..89243cc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1069,6 +1069,26 @@ static void assert_panel_unlocked(struct drm_i915_private *dev_priv,
> pipe_name(pipe));
> }
>
> +static void assert_cursor(struct drm_i915_private *dev_priv,
> + enum pipe pipe, bool state)
> +{
> + struct drm_device *dev = dev_priv->dev;
> + bool cur_state;
> +
> + if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
This could be (gen >=7 && !VLV), but we have the same check in
intel_crtc_update_cursor() so that should be changed as well. Can
be left for another patch I suppose.
> + cur_state = I915_READ(CURCNTR_IVB(pipe)) & CURSOR_MODE;
> + else if (IS_845G(dev) || IS_I865G(dev))
> + cur_state = I915_READ(_CURACNTR) & CURSOR_ENABLE;
> + else
> + cur_state = I915_READ(CURCNTR(pipe)) & CURSOR_MODE;
First I was thingking that can't be right, but looks like it is. Weird
how they stuffed the cursor registers differently on mobile and desktop
during the gen2 days.
> +
> + WARN(cur_state != state,
> + "cursor on pipe %c assertion failure (expected %s, current %s)\n",
> + pipe_name(pipe), state_string(state), state_string(cur_state));
> +}
> +#define assert_cursor_enabled(d, p) assert_cursor(d, p, true)
> +#define assert_cursor_disabled(d, p) assert_cursor(d, p, false)
I guess we don't really need assert_cursor_enabled() but no real harm in
having it.
> +
> void assert_pipe(struct drm_i915_private *dev_priv,
> enum pipe pipe, bool state)
> {
> @@ -4856,6 +4876,8 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
> const intel_limit_t *limit;
> int ret;
>
> + assert_cursor_disabled(dev_priv, pipe);
> +
> for_each_encoder_on_crtc(dev, crtc, encoder) {
> switch (encoder->type) {
> case INTEL_OUTPUT_LVDS:
> @@ -5754,6 +5776,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
> struct intel_shared_dpll *pll;
> int ret;
>
> + assert_cursor_disabled(dev_priv, pipe);
> +
> for_each_encoder_on_crtc(dev, crtc, encoder) {
> switch (encoder->type) {
> case INTEL_OUTPUT_LVDS:
> @@ -6270,6 +6294,8 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
> int plane = intel_crtc->plane;
> int ret;
>
> + assert_cursor_disabled(dev_priv, intel_crtc->pipe);
> +
> if (!intel_ddi_pll_mode_set(crtc))
> return -EINVAL;
I'd slap the asserts to the same places as the asserts for other planes.
But maybe we'd want to have pipe and plane asserts in mode_set as well,
just in case we manage to mess things up and call mode_set w/o disabling
the pipe first.
Also looks like the plane assert should be killed from
ironlake_fdi_link_train(). We shouldn't need a plain to train the FDI
link as the pipe will anyway pump out pixels.
--
Ville Syrjälä
Intel OTC
prev parent reply other threads:[~2013-09-04 12:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-04 11:20 [PATCH v2 1/3] drm/i915: add asserts for cursor state in crtc mode set Jani Nikula
2013-09-04 11:20 ` [PATCH v2 2/3] drm/i915: do not update cursor " Jani Nikula
2013-09-04 18:32 ` Ville Syrjälä
2013-09-04 11:20 ` [PATCH v2 3/3] drm/i915: clean up and simplify i9xx_crtc_mode_set wrt PLL handling Jani Nikula
2013-09-05 11:04 ` Ville Syrjälä
2013-09-04 12:11 ` Ville Syrjälä [this message]
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=20130904121122.GQ11428@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
/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