<div dir="ltr"><div class="gmail_extra"> </div><div class="gmail_extra"> We went through all the 5 patches. Already patches have undergone multiple revisions and a thorough review has been done for them. So we couldn’t find any anomalies as such & all patches seems to be fine. Reviewed-by: "Akash Goel <<a href="mailto:akash.goels@gmail.com">akash.goels@gmail.com</a>>" for all the patches in the series. </div> <div class="gmail_quote">On Thu, Feb 13, 2014 at 9:12 PM, <<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"> From: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com" target="_blank">ville.syrjala@linux.intel.com</a>> OK, so Daniel convinced me that the check+wait thing I used earlier wasn't really safe. I then decided that the only to make it safe it open coding the wait_for_event() mysefl, and after doing that I realized that we don't even need the silly vbl_received thingy, and just a wait queue + DSL check is enough. Let's see if Daniel can tear this one to shreds too :) </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"> Oh and I also did some more digging to the scanline counter + vblank interrupt mess, and decided that all my earlier hacks were crap. The solution was so simple once I started to look at the pixel counter values on gen4. I got inspired to have another look at this mess after Imre did some clock based vblank interrupt timing measurements on his VLV. Art confirmed my findings, so it should all be good now, no ugly hacks included. There is one tiny race window on gen2. That's caused by the fact that we only have the frame start interrupt there, and scanline counter increments slightly after the interrupt is triggered. So if we would extremely unlucky we might wake up, check the DSL, and determine we need to sleep more. But at this time we don't use the atomic update mechanism on gen2, and I think the windows is so small that we should be able to ignore it. Also the 1ms timeout would anyway prevent us from sleeping another full frame. So if it ever becomes a problem, we can try to think of something to overcome it, but at this point it doesn't seem worth the effort. Ville Syrjälä (5): drm/i915: Fix scanout position for real drm/i915: Add intel_get_crtc_scanline() drm/i915: Make sprite updates atomic drm/i915: Perform primary enable/disable atomically with sprite updates drm/i915: Add pipe update trace points drivers/gpu/drm/i915/i915_irq.c | 137 ++++++++++++------------ drivers/gpu/drm/i915/i915_trace.h | 77 ++++++++++++++ drivers/gpu/drm/i915/intel_display.c | 2 + drivers/gpu/drm/i915/intel_drv.h | 3 + drivers/gpu/drm/i915/intel_sprite.c | 195 ++++++++++++++++++++++++++++------- 5 files changed, 306 insertions(+), 108 deletions(-) -- 1.8.3.2 _______________________________________________ Intel-gfx mailing list <a href="mailto:Intel-gfx@lists.freedesktop.org" target="_blank">Intel-gfx@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/intel-gfx" target="_blank">http://lists.freedesktop.org/mailman/listinfo/intel-gfx</a> </blockquote></div><div class="gmail_extra"> </div></div>