summaryrefslogtreecommitdiffstats
path: root/drivers/char/tpm
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2019-06-06 10:44:04 +0200
committerRodrigo Siqueira <rodrigosiqueiramelo@gmail.com>2019-06-06 20:36:21 -0300
commit7355965da22b8d9ebac8bce4b776399fb0bb9d32 (patch)
treeceb83974969ce187530327d151b5f5be1dd8a83e /drivers/char/tpm
parent1ae752bf390c84250b702bd7d983c94d6eda42e2 (diff)
downloadlinux-stable-7355965da22b8d9ebac8bce4b776399fb0bb9d32.tar.gz
linux-stable-7355965da22b8d9ebac8bce4b776399fb0bb9d32.tar.bz2
linux-stable-7355965da22b8d9ebac8bce4b776399fb0bb9d32.zip
drm/vkms: Forward timer right after drm_crtc_handle_vblank
In commit def35e7c592616bc09be328de8795e5e624a3cf8 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: Daniel Vetter <daniel.vetter@intel.com> Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606084404.12014-1-daniel.vetter@ffwll.ch
Diffstat (limited to 'drivers/char/tpm')
0 files changed, 0 insertions, 0 deletions