On Wed, 2017-08-30 at 12:26 +0100, Chris Wilson wrote: > Quoting Joonas Lahtinen (2017-08-30 12:13:29) > > On Tue, 2017-08-29 at 16:09 -0700, Rodrigo Vivi wrote: > > > Driver’s CPU access to GTT is via the GTTMMADR BAR. > > > > > > The current HW implementation of that BAR is to only > > > support <= DW (and maybe QW) writes—not 16/32/64B writes > > > that could occur with WC and/or SSE/AVX moves. > > > > > > GTTMMADR must be marked uncacheable (UC). > > > Accesses to GTTMMADR(GTT), must be 64 bits or less (ie. 1 GTT entry). > > > > > > v2: Get clarification on the reasons and spec is getting > > > updated to reflect it now. > > > > > > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> > > > Suggested-by: Ben Widawsky <benjamin.widawsky@xxxxxxxxx> > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > > > Rodrigo, can you double-check how this interacts with the patch from > > Zhi that adds the WB flag to PPAT_CACHE_INDEX on CNL. > > Different issue (or should be). The ioremap concerns access through the > PCI BAR, affecting how fast we insert entries into the GGTT (so > establishing new mmaps following frequent runtime pm, loading of new > contexts + rings, as well as the stressful GGTT thrashing). PPAT affects > how the device accesses the physical pages, not the PTE themselves. Yes, I know it should be :) But Rodrigo also described pretty random hangs, IIRC not much was pinpointing to either of the issues. With these two bugs present, device could be operating without write-back on certain pages, or could be operating on wrong pages altogether. I'd just like one round of testing to try to avoid this change if we can. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
