[Intel-gfx] [PATCH] drm/i915: Disable all outputs early, before KMS takeover

[Chris Wilson]

On Tue, 5 Apr 2011 18:11:37 +0300, Pekka Enberg <penberg at kernel.org> wrote:
> Hi Chris,
> 
> On Tue, Apr 5, 2011 at 5:34 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > If the outputs are active and continuing to access the GATT when we
> > teardown the PTEs, then there is a potential for us to hang the GPU.
> > The hang tends to be a PGTBL_ER with either an invalid host access or
> > an invalid display plane fetch.
> >
> > v2: Reorder IRQ initialisation to defer until after GEM is setup.
> >
> > Reported-by: Pekka Enberg <penberg at kernel.org>
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Tested-by: Daniel Vetter <daniel.vetter at ffwll.ch> (855GM)
> 
> I no longer get a blank screen after boot but flicker got more
> aggressive during boot (it calms down after I've logged in). I see
> tons of these in dmesg that don't appear with 2.6.39-rc1:

Well the PGTBL_ER is still there. I'm thinking it might worth a check to
see if that is asserted even before we start...

> [   10.175843] [drm:intel_update_fbc],
> [   10.183100] [drm:i915_driver_irq_handler], pipe A underrun
> [   10.185085] [drm:i915_driver_irq_handler], pipe A underrun
> [   10.186082] [drm:i915_driver_irq_handler], pipe A underrun
> [   10.187087] [drm:i915_driver_irq_handler], pipe A underrun
> [   10.189082] [drm:i915_driver_irq_handler], pipe A underrun
> [   10.190085] [drm:i915_driver_irq_handler], pipe A underrun

If I'm understanding the dmesg correctly, then these start even before we
setup the first crtc.

Whether that means we're not completely disabling all outputs or that we
set a register incorrectly I don't know. Comparing an intel_reg_dumper
with and without the patch applied might give a clue if it is a register
that is set differently due to the reordering.

The other question is of course whether you see those in 2.6.39-rc1 as
well... Probably not since they will correspond with the increased
flicker.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre