[Intel-gfx] [PATCH] drm/i915: setup workarounds on reset

Daniel Vetter daniel at ffwll.ch
Mon Nov 18 17:24:01 CET 2013


On Mon, Nov 18, 2013 at 04:34:44PM +0200, Mika Kuoppala wrote:
> Large parts of hw initialization is behind per gen
> clock gating functions. Including workarounds.
> 
> Call intel_modeset_init_hw after reset so that we
> set these up correctly.
> 
> Signed-off-by: Mika Kuoppala <mika.kuoppala at intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index c2e00ed..2908f7f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -798,6 +798,8 @@ int i915_reset(struct drm_device *dev)
>  		drm_irq_uninstall(dev);
>  		drm_irq_install(dev);
>  		intel_hpd_init(dev);
> +
> +		intel_modeset_init_hw(dev);

Currently the idea is that w/as which get nuked by the gt reset should be
put into the respective ring_init function in intel_ringbuffer.c. This
disdinction is important since init_clock_gating gets called fairly early
in the resume/load sequence before most of the gem stuff is set up. And
the w/a in the ring_init functions are carefully ordered wrt the ring (re)
enabling.

So which bit/register is the culprit here?
-Daniel

>  	} else {
>  		mutex_unlock(&dev->struct_mutex);
>  	}
> -- 
> 1.7.9.5
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list