drm/i915/dsb: Correct DSB command buffer cache coherency settings
authorVille Syrjälä <ville.syrjala@linux.intel.com>
Mon, 9 Oct 2023 13:22:02 +0000 (16:22 +0300)
committerVille Syrjälä <ville.syrjala@linux.intel.com>
Fri, 13 Oct 2023 13:25:30 +0000 (16:25 +0300)
commit631b117ea8c3b7d4ec21ece69be6c465e79330fa
treecce01549b710899fd513584e2bb001e3cd91c9eb
parentbcdcae63274047dea5acf27432bbceb8191d012e
drm/i915/dsb: Correct DSB command buffer cache coherency settings

The display engine does not snoop the caches so we should mark
the DSB command buffer as I915_CACHE_NONE.
i915_gem_object_create_internal() always gives us I915_CACHE_LLC
on LLC platforms. And to make things 100% correct we should also
clflush at the end, if necessary.

Note that currently this is a non-issue as we always write the
command buffer through a WC mapping, so a cache flush is not actually
needed. But we might actually want to consider a WB mapping since
we also end up reading from the command buffer (in the indexed
reg write handling). Either that or we should do something else
to avoid those reads (might actually be even more sensible on DGFX
since we end up reading over PCIe). But we should measure the overhead
first...

Anyways, no real harm in adding the belts and suspenders here so
that the code will work correctly regardless of how we map the
buffer. If we do get a WC mapping (as we request)
i915_gem_object_flush_map() will be a nop. Well, apart form
a wmb() which may just flush the WC buffer a bit earlier
than would otherwise happen (at the latest the mmio accesses
would trigger the WC flush).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231009132204.15098-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
drivers/gpu/drm/i915/display/intel_dsb.c