[Intel-gfx] [PATCH] drm/i915: Don't deref pipe->cpu_transcoder in the hangcheck code
Chris Wilson
chris at chris-wilson.co.uk
Thu Aug 8 15:44:23 CEST 2013
On Thu, Aug 08, 2013 at 03:12:06PM +0200, Daniel Vetter wrote:
> From: Chris Wilson <chris at chris-wilson.co.uk>
>
> If we get an error event really early in the driver setup sequence,
> which gen3 is especially prone to with various display GTT faults we
> Oops. So try to avoid this.
>
> Additionally with Haswell the transcoders are a separate bank of
> registers from the pipes (4 transcoders, 3 pipes). In event of an
> error, we want to be sure we have a complete and accurate picture of
> the machine state, so record all the transcoders in addition to all
> the active pipes.
>
> This regression has been introduced in
>
> commit 702e7a56af3780d8b3a717f698209bef44187bb0
> Author: Paulo Zanoni <paulo.r.zanoni at intel.com>
> Date: Tue Oct 23 18:29:59 2012 -0200
>
> drm/i915: convert PIPECONF to use transcoder instead of pipe
>
> Based on the patch "drm/i915: Dump all transcoder registers on error"
> from Chris Wilson:
>
> v2: Rebase so that we don't try to be clever and try to figure out the
> cpu transcoder from hw state. That exercise should be done when we
> analyze the error state offline.
>
> The actual bugfix is to not call intel_pipe_to_cpu_transcoder in the
> error state capture code in case the pipes aren't fully set up yet.
>
> v3: Simplifiy the err->num_transcoders computation a bit. While at it
> make the error capture stuff save on systems without a display block.
>
> v4: Fix fail, spotted by Jani.
>
> v5: Completely new commit message, cc: stable.
>
> Cc: Paulo Zanoni <paulo.r.zanoni at intel.com>
> Cc: Damien Lespiau <damien.lespiau at intel.com>
> Cc: Jani Nikula <jani.nikula at intel.com>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60021
> Cc: stable at vger.kernel.org
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
Lgtm. We may have to modify transcoders[] to be more dynamic in future,
but for now this works.
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list