[PATCH] drm/i915: Decode RING_BUFFER_HEAD in error state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 22, 2013 at 05:17:41PM +0200, Daniel Vetter wrote:
> On Mon, Apr 22, 2013 at 02:16:34PM +0100, Chris Wilson wrote:
> > On Sun, Apr 21, 2013 at 04:01:19PM -0700, Ben Widawsky wrote:
> > > I consistently forget how to decode the HEAD pointer. If we put it in
> > > the error state, one doesn't need to look in docs to find the relevant
> > > info.
> > > 
> > > Signed-off-by: Ben Widawsky <ben at bwidawsk.net>
> > 
> > Turn the offset into an address and that would be really useful - then
> > once can do a quick search on the value and jump straight into the right
> > point in the ring.
> >   error->head[ring] & (0x7ffff << 2) + error->ring[ring].batchbuffer->gtt_offset
> 
> Also, shouldn't that kind of decode magic be done in intel_error_decode,
> where we have all the other stuff? Or is there a special reason?
> -Daniel

Originally, I had 4 excuses, but 2 turned out to false.
1. I usually don't use error decode, and I suspect others don't as well.
2. HEAD decoding hasn't changed for as long as I can tell.
3. (false) I thought we already decoded other registers in the error
4. (false) It's easier to add this to the error dump than the tool.

Personally, I felt Chris' suggestion is something along the lines of
what belongs in IGT, whereas this patch was the level of decoding worth
doing in error dump.

Personally, I'm not opposed to decoding more registers that improve the
usefulness of the error state without needing a tool, but I also
understand why you wouldn't take it, and how it's a fuzzy line about
which registers are appropriate to add vs. not.

I'm willing to add it to error dumper.

-- 
Ben Widawsky, Intel Open Source Technology Center


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux