Quoting Daniel Vetter (2017-10-18 15:47:27) > On Wed, Oct 18, 2017 at 03:19:44PM +0100, Chris Wilson wrote: > > We never declared that we were about to read from the mmap after copying > > into using the BLT (a missed call to prime_sync_start); leaving its > > coherency ill-defined. For completeness, add the missing > > prime_sync_end() as well. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103168 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > --- > > tests/prime_mmap_coherency.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c > > index a213ac0f..064c61a7 100644 > > --- a/tests/prime_mmap_coherency.c > > +++ b/tests/prime_mmap_coherency.c > > @@ -98,6 +98,8 @@ static int test_read_flush(void) > > if (ptr_cpu[i] != 0xc5c5c5c5) > > stale++; > > Shouldn't we add a prime_sync_start/end for the first ptr_cpu access too? > Just for over-the-top correctness? The loop where we check the new buffer is zero? Yup, missed that. That works as an interesting check with the mmap held across the blt, with sync's before/after. I suppose as we repeat the test several times, in addition to different bit values, we should also try different patterns of blts. Another day. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
