[Intel-gfx] Write GFX_FLSH_CNT after updating GGTT entries

[Zhi Wang]

Thanks!

OK. Then I check my box:

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd 
Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA 
controller])
	Subsystem: Hewlett-Packard Company Device 3396
	Flags: bus master, fast devsel, latency 0, IRQ 27
	Memory at f7400000 (64-bit, non-prefetchable) [size=4M]

So this should be our own magic to play WC on a non-prefechable BAR 
especially for GGTT MMIOs?

Thanks,
Zhi.

On 11/19/15 21:26, Ville Syrjälä wrote:
> On Thu, Nov 19, 2015 at 09:04:11PM +0800, Zhi Wang wrote:
>> Hi Ville:
>>
>> Thanks for the answer! :) Learned a lot.
>>
>> I think the following scenario should be typical for a general PCI
>> devices(perhaps a dedicated video card). How do other PCI devices handle
>> this kinds of WC MMIO writes without GFX_FLSH_CNT? Only support UC mapping?
>
> The standard rule is that you can't use WC, except for prefetchable BARs.
>
>>
>> Thanks,
>> Zhi.
>>
>> On 11/19/15 18:35, Ville Syrjälä wrote:
>>> On Thu, Nov 19, 2015 at 06:20:23PM +0800, Zhi Wang wrote:
>>>> Hi Gurus:
>>>>        I'm curious about the register GFX_FLSH_CNT(0x101008) in
>>>> i915_gem_gtt.c. Does these register exist in recently generations? After
>>>> digging into b-spec, it looks only BXT and CHV has this register. Does
>>>> the desktop platform also have this register which needs to be written
>>>> after updating GGTT MMIOs?
>>>>
>>>> BTW: Looks windows driver haven't used this MMIO... So whose behavior is
>>>> the right behavior?
>>>
>>> As I understand it that register flushes the CPU GTT TLBs, and we need
>>> to do it because of the WC mapping we have for the GTT PTEs. If we used
>>> UC mapping we wouldn't need it since there's supposedly an automagic
>>> TLB flush that happens on PTE writes.
>>>
>>> BSpec is bad at finding some registers via bxml. Using dtsearch and
>>> looking for both 0x<offset> and <offset>h is the method I use to track
>>> such things down.
>>>
>