Re: [Intel-gfx] [PATCH] drm/i915: workaround bad DSL readout v3

[Jani Nikula]

On Tue, 22 Sep 2015, Jesse Barnes  wrote:
> On HSW at least (still testing other platforms, but should be harmless
> elsewhere), the DSL reg reads back as 0 when read around vblank start
> time.  This ends up confusing the atomic start/end checking code, since
> it causes the update to appear as if it crossed a frame count boundary.
> Avoid the problem by making sure we don't return scanline_offset from
> the get_crtc_scanline function.  In moving the code there, I add to add
> an additional delay since it could be called and have a legitimate 0
> result for some time (depending on the pixel clock).
>
> v2: move hsw dsl read hack to get_crtc_scanline (Ville)
> v3: use break instead of goto (Ville)
> update comment with workaround details (Ville)
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=91579
> Signed-off-by: Jesse Barnes 

Pushed to drm-intel-fixes, thanks for the patch and review.

Sorry for the delay, I failed to notice the patch had been reviewed. It
would have helped if the patch had the Reviewed-by: tag already in
place, or the reviewer (or someone else pointing at the review) had
replied with the Reviewed-by: tag. I spend very little time looking at
individual patches, especially if the appearance is that there's
discussion going on.

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/i915_irq.c | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 1f53061..a8aa797 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -697,6 +697,32 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
> *crtc)
>   position = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) & 
> DSL_LINEMASK_GEN3;
>  
>   /*
> +  * On HSW, the DSL reg (0x7) appears to return 0 if we
> +  * read it just before the start of vblank.  So try it again
> +  * so we don't accidentally end up spanning a vblank frame
> +  * increment, causing the pipe_update_end() code to squak at us.
> +  *
> +  * The nature of this problem means we can't simply check the ISR
> +  * bit and return the vblank start value; nor can we use the scanline
> +  * debug register in the transcoder as it appears to have the same
> +  * problem.  We may need to extend this to include other platforms,
> +  * but so far testing only shows the problem on HSW.
> +  */
> + if (IS_HASWELL(dev) && !position) {
> + int i, temp;
> +
> + for (i = 0; i < 100; i++) {
> + udelay(1);
> + temp = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) &
> + DSL_LINEMASK_GEN3;
> + if (temp != position) {
> + position = temp;
> + break;
> + }
> + }
> + }
> +
> + /*
>* See update_scanline_offset() for the details on the
>* scanline_offset adjustment.
>*/
> -- 
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: workaround bad DSL readout v3

[Jesse Barnes]

On HSW at least (still testing other platforms, but should be harmless
elsewhere), the DSL reg reads back as 0 when read around vblank start
time.  This ends up confusing the atomic start/end checking code, since
it causes the update to appear as if it crossed a frame count boundary.
Avoid the problem by making sure we don't return scanline_offset from
the get_crtc_scanline function.  In moving the code there, I add to add
an additional delay since it could be called and have a legitimate 0
result for some time (depending on the pixel clock).

v2: move hsw dsl read hack to get_crtc_scanline (Ville)
v3: use break instead of goto (Ville)
update comment with workaround details (Ville)

References: https://bugs.freedesktop.org/show_bug.cgi?id=91579
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_irq.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1f53061..a8aa797 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -697,6 +697,32 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
*crtc)
position = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) & 
DSL_LINEMASK_GEN3;
 
/*
+* On HSW, the DSL reg (0x7) appears to return 0 if we
+* read it just before the start of vblank.  So try it again
+* so we don't accidentally end up spanning a vblank frame
+* increment, causing the pipe_update_end() code to squak at us.
+*
+* The nature of this problem means we can't simply check the ISR
+* bit and return the vblank start value; nor can we use the scanline
+* debug register in the transcoder as it appears to have the same
+* problem.  We may need to extend this to include other platforms,
+* but so far testing only shows the problem on HSW.
+*/
+   if (IS_HASWELL(dev) && !position) {
+   int i, temp;
+
+   for (i = 0; i < 100; i++) {
+   udelay(1);
+   temp = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) &
+   DSL_LINEMASK_GEN3;
+   if (temp != position) {
+   position = temp;
+   break;
+   }
+   }
+   }
+
+   /*
 * See update_scanline_offset() for the details on the
 * scanline_offset adjustment.
 */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx