Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Ben Widawsky <ben@bwidawsk.net>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 20/26] drm/i915: ValleyView has limited cacheability
Date: Mon, 26 Mar 2012 20:49:45 +0200	[thread overview]
Message-ID: <20120326184945.GZ4014@phenom.ffwll.local> (raw)
In-Reply-To: <20120326183420.GC17740@bolo_yeung.jf.intel.com>

On Mon, Mar 26, 2012 at 11:34:21AM -0700, Ben Widawsky wrote:
> On Thu, Mar 22, 2012 at 02:39:02PM -0700, Jesse Barnes wrote:
> > The GT can snoop CPU writes, but doesn't snoop into the CPU cache when
> > it does writes, so we can't use the cache bits the same way.
> 
> I found this commit message to be confusing. Is it simply saying CPU
> writes are snooped by the GT, but GT writes are not snooped bv the CPU?
> 
> > 
> > So map the status and pipe control pages as uncached on ValleyView, and
> > only set the pages to cached if we're on a supported platform.
> 
> I'd like to see in the commit message why the pipe control page needs to
> be uncached. The only workarounds on the top of my head don't care about
> the coherency.

Afaik we've cleared this up in our mtg yesterday:
- Full coherent gtt mappings work, they simply moved the bit around (we
  need to set bit2 instead of bit1 like on snb/ivb).
- It sounds like all the gpu functions can handle coherent memory, like
  on snb/ivb. But because there's no shared cache between the gpu and the
  cpu you don't gain anything, but only lose due to the required snoop
  traffic.
- Because there's no last level cache it also means that when the gpu does
  a write and snoops the cpu cache, it essentially means the cpu
  completely drops it's cacheline and has to go back to main memory
  (instead of l3 like it does on llc platforms). Gpu reads snoop the cpu
  cache corectly.

I hope this clears up the confusion around coherency on vlv. Let Jesse
only needs to check with a real piece of silicon whether that's true ;-)
-Daniel

> 
> > 
> > v2: add clarifying comments and don't use the LLC flag for ioremap vs
> >     kmap (Daniel)
> > 
> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> > ---
> >  drivers/gpu/drm/i915/intel_ringbuffer.c |   45 ++++++++++++++++++++++++++-----
> >  1 files changed, 38 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index ca3972f..9b26c9d 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -319,6 +319,8 @@ init_pipe_control(struct intel_ring_buffer *ring)
> >  {
> >  	struct pipe_control *pc;
> >  	struct drm_i915_gem_object *obj;
> > +	int cache_level = HAS_LLC(ring->dev) ? I915_CACHE_LLC : I915_CACHE_NONE;
> > +	struct drm_device *dev;
> >  	int ret;
> >  
> >  	if (ring->private)
> > @@ -335,14 +337,24 @@ init_pipe_control(struct intel_ring_buffer *ring)
> >  		goto err;
> >  	}
> >  
> > -	i915_gem_object_set_cache_level(obj, I915_CACHE_LLC);
> > +	i915_gem_object_set_cache_level(obj, cache_level);
> >  
> >  	ret = i915_gem_object_pin(obj, 4096, true);
> >  	if (ret)
> >  		goto err_unref;
> > -
> > +	dev = obj->base.dev;
> >  	pc->gtt_offset = obj->gtt_offset;
> > -	pc->cpu_page =  kmap(obj->pages[0]);
> > +	/*
> > +	 * On ValleyView, only CPU writes followed by GPU reads are snooped,
> > +	 * not GPU writes followed by CPU reads.  So we need to map status
> > +	 * pages as uncached.
> > +	 */
> > +	if (IS_VALLEYVIEW(dev))
> > +		pc->cpu_page = ioremap(dev->agp->base +
> > +				       obj->gtt_offset,
> > +				       PAGE_SIZE);
> 
> Bikeshed: I think ioremap_nocache is a bit better to use. It's more
> self-commenting.
> 
> > +	else
> > +		pc->cpu_page =  kmap(obj->pages[0]);
> >  	if (pc->cpu_page == NULL)
> >  		goto err_unpin;
> >  
> > @@ -364,12 +376,17 @@ cleanup_pipe_control(struct intel_ring_buffer *ring)
> >  {
> >  	struct pipe_control *pc = ring->private;
> >  	struct drm_i915_gem_object *obj;
> > +	struct drm_device *dev;
> >  
> >  	if (!ring->private)
> >  		return;
> >  
> >  	obj = pc->obj;
> > -	kunmap(obj->pages[0]);
> > +	dev = obj->base.dev;
> > +	if (IS_VALLEYVIEW(dev))
> > +		iounmap(pc->cpu_page);
> > +	else
> > +		kunmap(obj->pages[0]);
> >  	i915_gem_object_unpin(obj);
> >  	drm_gem_object_unreference(&obj->base);
> >  
> > @@ -929,7 +946,10 @@ static void cleanup_status_page(struct intel_ring_buffer *ring)
> >  	if (obj == NULL)
> >  		return;
> >  
> > -	kunmap(obj->pages[0]);
> > +	if (IS_VALLEYVIEW(dev_priv->dev))
> > +		iounmap(ring->status_page.page_addr);
> > +	else
> > +		kunmap(obj->pages[0]);
> >  	i915_gem_object_unpin(obj);
> >  	drm_gem_object_unreference(&obj->base);
> >  	ring->status_page.obj = NULL;
> > @@ -942,6 +962,7 @@ static int init_status_page(struct intel_ring_buffer *ring)
> >  	struct drm_device *dev = ring->dev;
> >  	drm_i915_private_t *dev_priv = dev->dev_private;
> >  	struct drm_i915_gem_object *obj;
> > +	int cache_level = HAS_LLC(ring->dev) ? I915_CACHE_LLC : I915_CACHE_NONE;
> >  	int ret;
> >  
> >  	obj = i915_gem_alloc_object(dev, 4096);
> > @@ -951,7 +972,7 @@ static int init_status_page(struct intel_ring_buffer *ring)
> >  		goto err;
> >  	}
> >  
> > -	i915_gem_object_set_cache_level(obj, I915_CACHE_LLC);
> > +	i915_gem_object_set_cache_level(obj, cache_level);
> >  
> >  	ret = i915_gem_object_pin(obj, 4096, true);
> >  	if (ret != 0) {
> > @@ -959,7 +980,17 @@ static int init_status_page(struct intel_ring_buffer *ring)
> >  	}
> >  
> >  	ring->status_page.gfx_addr = obj->gtt_offset;
> > -	ring->status_page.page_addr = kmap(obj->pages[0]);
> > +	/*
> > +	 * On ValleyView, only CPU writes followed by GPU reads are snooped,
> > +	 * not GPU writes followed by CPU reads.  So we need to map status
> > +	 * pages as uncached.
> > +	 */
> > +	if (IS_VALLEYVIEW(dev))
> > +		ring->status_page.page_addr = ioremap(dev->agp->base +
> > +						      obj->gtt_offset,
> > +						      PAGE_SIZE);
> 
> Same bikeshed as above.
> 
> > +	else
> > +		ring->status_page.page_addr = kmap(obj->pages[0]);
> >  	if (ring->status_page.page_addr == NULL) {
> >  		memset(&dev_priv->hws_map, 0, sizeof(dev_priv->hws_map));
> >  		goto err_unpin;
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2012-03-26 18:49 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-22 21:38 [RFCv2] ValleyView support Jesse Barnes
2012-03-22 21:38 ` [PATCH 01/26] drm/i915: move NEEDS_FORCE_WAKE to i915_drv.c Jesse Barnes
2012-03-22 22:20   ` Ben Widawsky
2012-03-23 22:46     ` Daniel Vetter
2012-03-22 21:38 ` [PATCH 02/26] drm/i915: re-order GT IIR bit definitions Jesse Barnes
2012-03-22 22:25   ` Ben Widawsky
2012-03-23 22:46     ` Daniel Vetter
2012-03-22 21:38 ` [PATCH 03/26] drm/i915: add ValleyView driver structs and IS_VALLEYVIEW macro Jesse Barnes
2012-03-22 22:31   ` Ben Widawsky
2012-03-22 21:38 ` [PATCH 04/26] drm/i915: ValleyView watermark support Jesse Barnes
2012-03-23  3:29   ` Ben Widawsky
2012-03-23  9:51     ` Daniel Vetter
2012-03-24  2:46       ` Ben Widawsky
2012-03-22 21:38 ` [PATCH 05/26] drm/i915: PLL defines for VLV Jesse Barnes
2012-03-23  3:35   ` Ben Widawsky
2012-03-22 21:38 ` [PATCH 06/26] drm/i915: interrupt bit definitions " Jesse Barnes
2012-03-22 21:38 ` [PATCH 07/26] drm/i915: add ValleyView clock gating init Jesse Barnes
2012-03-22 23:25   ` Ben Widawsky
2012-03-22 21:38 ` [PATCH 08/26] drm/i915: add DPIO read/write functions for ValleyView Jesse Barnes
2012-03-23  4:03   ` Ben Widawsky
2012-03-23 17:29   ` Eugeni Dodonov
2012-03-22 21:38 ` [PATCH 09/26] drm/i915: split PLL update code out of i9xx_crtc_mode_set Jesse Barnes
2012-03-23  4:16   ` Ben Widawsky
2012-03-23 23:00   ` Daniel Vetter
2012-03-22 21:38 ` [PATCH 10/26] drm/i915: split LVDS " Jesse Barnes
2012-03-23 23:04   ` Daniel Vetter
2012-03-22 21:38 ` [PATCH 11/26] drm/i915: ValleyView mode setting limits and PLL functions Jesse Barnes
2012-03-22 21:38 ` [PATCH 12/26] drm/i915: program drain latency regs on ValleyView Jesse Barnes
2012-03-26  1:50   ` Ben Widawsky
2012-03-22 21:38 ` [PATCH 13/26] drm/i915: Enable DP panel power sequencing for ValleyView Jesse Barnes
2012-03-22 21:38 ` [PATCH 14/26] drm/i915: Enable HDMI on ValleyView Jesse Barnes
2012-03-22 21:38 ` [PATCH 15/26] agp/intel: map more registers for use by the GTT code Jesse Barnes
2012-03-26  2:05   ` Ben Widawsky
2012-03-26  7:06     ` Daniel Vetter
2012-03-22 21:38 ` [PATCH 16/26] agp/intel: add ValleyView AGP driver Jesse Barnes
2012-03-26  2:16   ` Ben Widawsky
2012-03-26  7:08     ` Daniel Vetter
2012-03-26 18:17       ` Ben Widawsky
2012-03-22 21:38 ` [PATCH 17/26] agp/intel: bind " Jesse Barnes
2012-03-22 21:39 ` [PATCH 18/26] drm/i915: add ValleyView specific CRT detect function Jesse Barnes
2012-03-23 17:11   ` Eugeni Dodonov
2012-03-22 21:39 ` [PATCH 19/26] drm/i915: add ValleyView specific force wake get/put functions Jesse Barnes
2012-03-23 17:20   ` Eugeni Dodonov
2012-03-26 18:20     ` Ben Widawsky
2012-03-22 21:39 ` [PATCH 20/26] drm/i915: ValleyView has limited cacheability Jesse Barnes
2012-03-22 23:31   ` Jesse Barnes
2012-03-26 18:34   ` Ben Widawsky
2012-03-26 18:49     ` Daniel Vetter [this message]
2012-03-28 17:43       ` Jesse Barnes
2012-03-22 21:39 ` [PATCH 21/26] drm/i915: ValleyView IRQ support Jesse Barnes
2012-03-22 21:39 ` [PATCH 22/26] drm/i915: display regs are at 0x180000 on ValleyView Jesse Barnes
2012-03-22 21:39 ` [PATCH 23/26] drm/i915: check for disabled interrupts " Jesse Barnes
2012-03-22 21:39 ` [PATCH 24/26] drm/i915: add HDMI and DP port enumeration " Jesse Barnes
2012-03-22 21:39 ` [PATCH 25/26] drm/i915: disable turbo on ValleyView for now Jesse Barnes
2012-03-23 17:04   ` Eugeni Dodonov
2012-03-22 21:39 ` [PATCH 26/26] drm/i915: bind driver to ValleyView chipsets Jesse Barnes

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=20120326184945.GZ4014@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=ben@bwidawsk.net \
    --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