On 09/10/2015 02:53 PM, Ville Syrjälä wrote: > On Thu, Sep 10, 2015 at 02:38:53PM -0700, 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) >> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=91579 >> Signed-off-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> >> --- >> drivers/gpu/drm/i915/i915_irq.c | 21 +++++++++++++++++++++ >> 1 file changed, 21 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c >> index 90bc6c2..97e5d52 100644 >> --- a/drivers/gpu/drm/i915/i915_irq.c >> +++ b/drivers/gpu/drm/i915/i915_irq.c >> @@ -697,6 +697,27 @@ 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 (0x70000) appears to return 0 if we >> + * read it right around 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. >> + */ >> + 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; >> + goto out; >> + } >> + } >> + } > > Hmm. Another idea. If it always happens at start of vbl, maybe have a > look at the ISR. If scanline reads 0, but ISR says we're in vblank, just > return vblank_start. That's assming ISR would in fact show that it's in > vblank when this happens. Sounds a bit racy, though I guess it wouldn't hurt. I'm actually a little dubious about this change anyway since it will mean longer delays when we really are at the top of the field/frame. You sure you don't like the first one better? Thanks, Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx