[Intel-gfx] [PATCH 1/2] drm/i915: Use Write-Through cacheing for the display plane on Iris

[Chris Wilson]

On Fri, Aug 02, 2013 at 12:47:05PM -0700, Andy Lutomirski wrote:
> On Fri, Aug 2, 2013 at 12:21 PM, Ben Widawsky <ben at bwidawsk.net> wrote:
> > On Fri, Aug 02, 2013 at 11:45:22AM -0700, Andy Lutomirski wrote:
> >> On 08/01/2013 10:39 AM, Chris Wilson wrote:
> >> > Haswell GT3e has the unique feature of supporting Write-Through cacheing
> >> > of objects within the eLLC/LLC. The purpose of this is to enable the display
> >> > plane to remain coherent whilst objects lie resident in the eLLC/LLC - so
> >> > that we, in theory, get the best of both worlds, perfect display and fast
> >> > access.
> >> >
> >> > However, we still need to be careful as the CPU does not see the WT when
> >> > accessing the cache. In particular, this means that we need to flush the
> >> > cache lines after writing to an object through the CPU, and on
> >> > transitioning from a cached state to WT.
> >> >
> >>
> >> I'm planning on adding ioremap_wt, etc sometime soon (for an unrelated
> >> reason).  Would this be useful here?
> >
> > I don't think so. We should never be ioremapping the buffers with these
> > mappings.
> >
> >>
> >> If so, do you need it for real RAM (i.e. pages that the kernel considers
> >> to be direct-mappable RAM) or just for MMIO space?
> >>
> >> --Andy
> >
> > It is for real RAM, but again, not something we should ever be
> > ioremapping.
> 
> I asked the question poorly.  The change I'm planning to make would be
> to add WT mappings on a roughly equal footing with WC.  You could use
> mmap protection bits (assuming there's a free bit in there),
> set_memory_wt, or whatever the appropriate API is here.

No, the WT bit here is only applied to the GPU. From the CPU side, we
maintain our usual WB view of the physical pages, and a WC alias through
the aperture.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre