All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/5] drm/i915: Call i915_pipe_update_start with uncore.lock held.
Date: Mon, 12 Feb 2018 15:19:56 +0000	[thread overview]
Message-ID: <151844879607.18923.15930170017428937869@mail.alporthouse.com> (raw)
In-Reply-To: <20180209095404.76418-4-maarten.lankhorst@linux.intel.com>

Quoting Maarten Lankhorst (2018-02-09 09:54:02)
> This requires being able to read the vblank counter with the
> uncore.lock already held. This is also a preparation for
> being able to run the entire vblank update sequence with
> the uncore lock held.
> 
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/i915_irq.c     | 66 ++++++++++++++++++++++++++++++-------
>  drivers/gpu/drm/i915/i915_trace.h   |  5 ++-
>  drivers/gpu/drm/i915/intel_drv.h    |  1 +
>  drivers/gpu/drm/i915/intel_sprite.c |  3 +-
>  4 files changed, 60 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index eda9543a0199..6c491e63e07c 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -736,13 +736,12 @@ static void i915_enable_asle_pipestat(struct drm_i915_private *dev_priv)
>  /* Called from drm generic code, passed a 'crtc', which
>   * we use as a pipe index
>   */
> -static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
> +static u32 __i915_get_vblank_counter(struct intel_crtc *crtc)
>  {
> -       struct drm_i915_private *dev_priv = to_i915(dev);
> +       struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>         i915_reg_t high_frame, low_frame;
>         u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
> -       const struct drm_display_mode *mode = &dev->vblank[pipe].hwmode;
> -       unsigned long irqflags;
> +       const struct drm_display_mode *mode = &crtc->base.dev->vblank[crtc->pipe].hwmode;

lockdep_assert_held(&dev_priv->uncore.lock);

>  
>         htotal = mode->crtc_htotal;
>         hsync_start = mode->crtc_hsync_start;
> @@ -756,10 +755,8 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
>         /* Start of vblank event occurs at start of hsync */
>         vbl_start -= htotal - hsync_start;
>  
> -       high_frame = PIPEFRAME(pipe);
> -       low_frame = PIPEFRAMEPIXEL(pipe);
> -
> -       spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> +       high_frame = PIPEFRAME(crtc->pipe);
> +       low_frame = PIPEFRAMEPIXEL(crtc->pipe);
>  
>         /*
>          * High & low register fields aren't synchronized, so make sure
> @@ -772,8 +769,6 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
>                 high2 = I915_READ_FW(high_frame) & PIPE_FRAME_HIGH_MASK;
>         } while (high1 != high2);
>  
> -       spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
> -
>         high1 >>= PIPE_FRAME_HIGH_SHIFT;
>         pixel = low & PIPE_PIXEL_MASK;
>         low >>= PIPE_FRAME_LOW_SHIFT;
> @@ -786,11 +781,60 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
>         return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xffffff;
>  }
>  
> +static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
> +{
> +       struct drm_i915_private *dev_priv = to_i915(dev);
> +       unsigned long irqflags;
> +       u32 ret;
> +
> +       spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> +       ret = i915_get_vblank_counter(dev, pipe);
> +       spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
> +
> +       return ret;
> +}
> +
> +static u32 __g4x_get_vblank_counter(struct intel_crtc *crtc)
> +{
> +       struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);

lockdep_assert_held(&dev_priv->uncore.lock); ?

Ok, why do we need uncore.lock held here at all? Serialisation of mmio
access to the same cacheline is the age old reason, can we guarantee
that doesn't happen anyway? (Probably not, but really most callers do
not need the mmio w/a.)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-02-12 15:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-09  9:53 [PATCH 0/5] drm/i915: Grab the vblank evasion lock around the entire evasion Maarten Lankhorst
2018-02-09  9:54 ` [PATCH 1/5] drm/i915: Keep vblank irq enabled during vblank evasion Maarten Lankhorst
2018-02-12 15:10   ` Chris Wilson
2018-02-12 15:16     ` Maarten Lankhorst
2018-02-12 15:22       ` Chris Wilson
2018-02-12 15:27         ` Maarten Lankhorst
2018-02-12 15:31           ` Chris Wilson
2018-02-12 15:41             ` Maarten Lankhorst
2018-02-12 16:55               ` Ville Syrjälä
2018-02-12 17:24                 ` Chris Wilson
2018-02-12 18:06                   ` Ville Syrjälä
2018-02-12 20:55                     ` Chris Wilson
2018-02-13  8:59                       ` Maarten Lankhorst
2018-02-09  9:54 ` [PATCH 2/5] drm/i915: Grab uncore.lock around enabling " Maarten Lankhorst
2018-02-12 15:16   ` Chris Wilson
2018-02-09  9:54 ` [PATCH 3/5] drm/i915: Call i915_pipe_update_start with uncore.lock held Maarten Lankhorst
2018-02-09 23:08   ` James Ausmus
2018-02-10  8:46     ` Maarten Lankhorst
2018-02-10  9:05       ` Chris Wilson
2018-02-12 15:19   ` Chris Wilson [this message]
2018-02-12 15:39     ` Maarten Lankhorst
2018-02-12 15:44       ` Chris Wilson
2018-02-12 16:41         ` Maarten Lankhorst
2018-02-09  9:54 ` [PATCH 4/5] drm/i915: Move all locking for plane updates to caller Maarten Lankhorst
2018-02-09  9:54 ` [PATCH 5/5] drm/i915: Use DOUBLE_BUFFER_CTL on top of vblank evasion for GEN9+ Maarten Lankhorst
2018-02-09 10:04 ` [PATCH 0/5] drm/i915: Grab the vblank evasion lock around the entire evasion Chris Wilson
2018-02-09 17:21   ` Maarten Lankhorst
2018-02-12 17:01     ` Ville Syrjälä
2018-02-13 10:19       ` Maarten Lankhorst
2018-02-13 10:40         ` Chris Wilson
2018-02-09 14:24 ` ✗ Fi.CI.BAT: failure for " Patchwork
2018-02-12 15:02 ` ✓ Fi.CI.BAT: success " Patchwork
2018-02-12 16:56 ` ✗ Fi.CI.IGT: warning " Patchwork

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=151844879607.18923.15930170017428937869@mail.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=maarten.lankhorst@linux.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 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.