[Intel-gfx] [PATCH 10/15] drm/i915: check the power well when capturing error state

Daniel Vetter daniel at ffwll.ch
Sun Mar 17 21:51:29 CET 2013


On Sun, Mar 17, 2013 at 09:46:37PM +0100, Daniel Vetter wrote:
> On Wed, Mar 06, 2013 at 08:03:17PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni <paulo.r.zanoni at intel.com>
> > 
> > This solves many "unclaimed register" messages when the power well is
> > down and we get a GPU hang.
> > 
> > Also print the power well register and each pipe's CPU transcoder on
> > the error state to allow proper interpratation of the registers. And
> > kzalloc the error state structure since we may not read some of the
> > registers (to avoid the "unclaimed register" messages).
> > 
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> 
> Ok, I've thought some more about all and you're all going to hate me.
> 
> Essentially I don't like that we have rather invasive patches for a minor
> feature with _very_ delicate limits as to what hits the debug yelling and
> what doesn't. Furthermore the debug feature isn't that clear-cut since
> interrupts get in the way (and we cant fix that since that would also
> disable underrun interrupts, which we want). And the audio driver also
> randomly inteferes.
> 
> Now where it's justified that a register doesn't exist I don't mind
> merging the patches - it's always good to have accurate documentation of
> what's really used by the hw. But for debug features I'm really uneasy
> with runtime checks, since it might very well be that those are wrong.
> 
> Hence I vote for a I915_READ_NOCHECK to avoid all this madness. This one
> will never check for errors, but silently clear them after a read. Note
> that we don't need a I915_WRITE_NOCHECK, and imo that's good since writing
> random crap could indeed be a serious bug.
> 
> So I'll punt on this patch since imo it's too messy for future
> maintenance. Same for the other debug patches (e.g. the assert_pipe_enabled
> check).

Forgotten to add: I like the powerwell related additions to the error
state, but that's imo a separate patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list