[Intel-gfx] Updated drm-intel-testing

Ville Syrjälä ville.syrjala at linux.intel.com
Tue Apr 12 09:21:39 UTC 2016


On Mon, Apr 11, 2016 at 09:45:11PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> New -testing cycle with cool stuff:
> - make modeset hw state checker atomic aware (Maarten)
> - close races in gpu stuck detection/seqno reading (Chris)
> - tons&tons of small improvements from Chris Wilson all over the gem code
> - more dsi/bxt work from Ramalingam&Jani
> - macro polish from Joonas
> - guc fw loading fixes (Arun&Dave)
> - vmap notifier (acked by Andrew) + i915 support by Chris Wilson
> - create bottom half for execlist irq processing (Chris Wilson)
> - vlv/chv pll cleanup (Ville)
> - rework DP detection, especially sink detection (Shubhangi Shrivastava)
> - make color manager support fully atomic (Maarten)
> - avoid livelock on chv in execlist irq handler (Chris)

The chv irq handler change needs to be backed out, or more preferably
fixed in another way. Currently chv isn't in the best shape due to this.

I'm trying to figure out how it actually fails. My only theory right now
is that if a display interrupt happens just as we've started processing a
GT interrupt, there might not be an edge for the CPU interrupt generation
logic (assuming the input there is an OR of the GT and display
interrupts), so the CPU interrupt won't be re-raised and thus we fail
to process the display interrupt. I'll need to figure out a decent way to
test that theory though. If this is the case, one potential way to fix
it would be to clear VLV_IER around irq processing, as that combined
with the GEN8_MASTER_IRQ disabling should guarantee an edge at the top
level. So it would be similar to the PCH SDE trick we're doing on some
platforms.

One interesting detail I've already noticed is that, unlike gen4, IIR
isn't actually double buffered on VLV/CHV.

-- 
Ville Syrjälä
Intel OTC


More information about the Intel-gfx mailing list