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@xxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
