]> asedeno.scripts.mit.edu Git - linux.git/commit
drm/i915: Clean up the HWSTAM mess
authorVille Syrjälä <ville.syrjala@linux.intel.com>
Fri, 18 Aug 2017 18:37:03 +0000 (21:37 +0300)
committerVille Syrjälä <ville.syrjala@linux.intel.com>
Fri, 15 Sep 2017 11:42:55 +0000 (14:42 +0300)
commitd420a50c21efa4ec9e43494547de4f2b1826e167
treee2df2809d5be6b5eed640225c469bf74886b7146
parentc5498089463b94690085158eba7dd29835c8c9b8
drm/i915: Clean up the HWSTAM mess

Currently we're unmasking some random looking bits in HWSTAM
on gen3/4/5. The two bits we apparently unmask are 0 and 12,
and also bits 16-31 on gen4/5.
What those bits do depends on the gen as follows:
 bit 0: Breakpoint (gen2), ASLE (gen3), reserved (gen4), render user interrupt (gen5)
 bit 12: Sync flush statusa (gen2-4), reserved (gen5)
 bit 16-31: The ones that can unmasked seem to be mostly some
            display stuff on gen4. Bit 18 is the PIPE_CONTROL notify,
    which might be the only intresting one. On gen5 all the
    bits are reserved.

So I don't know whether we actually depend on that status page write
somehow. Extra seqno coherency by accident perhaps? Except we don't
even unmask the user interrupt bit in HWSTAM except on gen5, and
sync flush isn't something we use normally, so seems unlikely. So
let's just assume we don't need any of this and mask everything in
HWSTAM.

From gen6 onwards there's a separate HWSTAM for each engine, and so
we deal with them during the engine setup.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-15-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
drivers/gpu/drm/i915/i915_irq.c