looking for cOherEnCY

["Bob Schulman" <bob@rexdog.net>]

Folks,

I understand that the normal method of debugging the GEM driver code is by
use of various debug functions conditionally included if/when various WATCH
manifests are defined.

So I set WATCH_COHERENCY for a port I am doing and that meant that
i915_gem_object_check_coherency() got called...but that function gagged on
me on an object...and after some looking, it appeared that I was checking
the coherency of the frame buffer object.

That doesn't appear to be a good idea as fence registers are set up to
diddle the tiling setup for the frame buffer. And the kind of coherency
check performed by i915_gem_object_check_coherency() is bound to fail for
objects which have used the fence registers to set up tiling.

The question is: is use of i915_gem_object_check_coherency() a bit too
aggressive in the driver code? It seems to me we ask it to check coherency
of areas of memory that are not "coherent" in the manner effectively defined
by the tests in i915_gem_object_check_coherency() (for those who don't know,
"coherence" as defined by this function is that a 32-bit read at offset "c"
in CPU VM space (ie. Only through the CPU's MMU and NOT through BAR2) of an
object results in the same value as a 32-bit read at the same offset when
read through BAR2 of the graphics device...for each page whose coherence is
tested, the first quarter of the page is read and compared through both the
CPU's MMU and through BAR2).

Or am I just plain Missing Something?

Thanks.

bob