[RFC PATCH 0/1] drm: ensure that vblank diff is never negative

[Aaron Erhardt <aer@tuxedocomputers.com>]

I observed a rare freeze on a device and was able to track the cause down
to incorrect reporting of timestamps in the vblank code. The
drm_vlank_restore code expects that one timestamp is always larger than the
other, but not all drivers fulfill this assumption. This allows the
difference between the two timestamps to become negative. Most of the time,
this is not fatal, because the value is rounded after dividing through the
frame duration. Therefore, small negative values are converted into zeros.
However, if the value is sufficiently negative, the calculation might end
up reporting that -1 frames were missed. The negative result is stored in
an unsigned integer, causing a wrap-around.

So far, this behavior has been observed on some newer Intel devices (e.g.
using the Intel Core Ultra 7 155H) with the i915 driver and the patch has
been tested successfully as a fix. While the root cause is in the driver, I
think that handling this case with drm_WARN_ON_ONCE is a good idea. Without
the warning, driver issues can remain unnoticed for a long time because
they only cause problems under very specific (seemingly random)
cirucumstances.

Normal (expected) log example:
i915 0000:00:02.0: [drm:drm_vblank_restore] missed 1 vblanks in 4165983 ns, frame duration=4166666 ns, hw_diff=1

Abnormal (but non-fatal) log example:
i915 0000:00:02.0: [drm:drm_vblank_restore] missed 0 vblanks in -1135 ns, frame duration=4166666 ns, hw_diff=0

Abnormal and fatal log example:
i915 0000:00:02.0: [drm:drm_vblank_restore] missed -891996132 vblanks in -4118209 ns, frame duration=4166666 ns, hw_diff=0

Aaron Erhardt (1):
  drm: ensure that vblank diff is never negative

 drivers/gpu/drm/drm_vblank.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

-- 
2.43.0