1. 12 Jun, 2019 2 commits
  2. 11 Jun, 2019 8 commits
  3. 10 Jun, 2019 18 commits
  4. 09 Jun, 2019 1 commit
  5. 08 Jun, 2019 3 commits
  6. 07 Jun, 2019 7 commits
  7. 06 Jun, 2019 1 commit
    • Daniel Vetter's avatar
      drm/vkms: Forward timer right after drm_crtc_handle_vblank · 7355965d
      Daniel Vetter authored
      In
      
      commit def35e7c
      Author: Shayenne Moura <shayenneluzmoura@gmail.com>
      Date:   Wed Jan 30 14:06:36 2019 -0200
      
          drm/vkms: Bugfix extra vblank frame
      
      we fixed the vblank counter to give accurate results outside of
      drm_crtc_handle_vblank, which fixed bugs around vblank timestamps
      being off-by-one and causing the vblank counter to jump when it
      shouldn't.
      
      The trouble is that this completely broke crc generation. Shayenne and
      Rodrigo tracked this down to the vblank timestamp going backwards in
      time somehow. Which then resulted in an underflow in drm_vblank.c
      code, which resulted in all kinds of things breaking really badly.
      
      The reason for this is that once we've called drm_crtc_handle_vblank
      and the hrtimer isn't forwarded yet, we're returning a vblank
      timestamp in the past. This race is really hard to hit since it's
      small, except when you enable crc generation: In that case there's a
      call to drm_crtc_accurate_vblank right in-betwen, so we're guaranteed
      to hit the bug.
      
      The fix is to roll the hrtimer forward _before_ we do the vblank
      processing (which has a side-effect of incrementing the vblank
      counter), and we always subtract one frame from the hrtimer - since
      now it's always one frame in the future.
      
      To make sure we don't hit this again also add a WARN_ON checking for
      whether our timestamp is somehow moving into the past, which is never
      should.
      
      This also aligns more with how real hw works:
      1. first all registers are updated with the new timestamp/vblank
      counter values.
      2. then an interrupt is generated
      3. kernel interrupt handler eventually fires.
      
      So doing this aligns vkms closer with what drm_vblank.c expects.
      Document this also in a comment.
      
      Cc: Shayenne Moura <shayenneluzmoura@gmail.com>
      Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Tested-by: default avatarRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Reviewed-by: default avatarRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Signed-off-by: default avatarRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190606084404.12014-1-daniel.vetter@ffwll.ch
      7355965d