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

[Andy Lutomirski]

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.

(I know approximately nothing about what's going on in i915 -- I just
noticed someone else mentioning WT mappings.  For my use, I can get
away with skipping this on real ram, although it would be nice.  The
tricky part about using real ram is finding some space in struct
page.)

--Andy