On 02/09/2016 11:09 AM, Daniel Vetter wrote:
On Mon, Feb 08, 2016 at 02:13:28AM +0100, Mario Kleiner wrote:
The changes to drm_update_vblank_count() in Linux 4.4 added a
method to emulate a hardware vblank counter by use of high
precision vblank timestamps if a kms driver supports those,
but doesn't suppport hw vblank counters.
That method assumes that the old timestamp from a previous
invocation is valid, but that is not always the case. E.g.,
if drm_reset_vblank_timestamp() gets called during drm_vblank_on()
or drm_update_vblank_count() gets called outside vblank irq and
the high precision timestamping can't deliver a precise timestamp,
ie. drm_get_last_vbltimestamp() delivers a return value of false,
then those functions will initialize the old timestamp to zero
to mark it as invalid.
A following call to drm_update_vblank_count() would then calculate
elapsed time with vblank irqs off as current vblank timestamp minus
the zero old timestamp and compute a software vblank counter increment
that corresponds to system uptime, causing a large forward jump of the
software vblank counter. That jump in turn can cause too long waits
in drmWaitVblank and very long delays in delivery of vblank events,
resulting in hangs of userspace clients.
This problem can be observed on nouveau-kms during machine
suspend->resume cycles, where drm_vblank_off is called during
suspend, drm_vblank_on is called during resume and the first
queries to drm_get_last_vbltimestamp() don't deliver high
precision timestamps, resulting in a large harmful counter jump.
Why does nouveau enable vblank interrupts before it can get valid
timestamps? That sounds like the core bug here, and papering over that in
the vblank code feels very wrong to me. Maybe we should instead just not
sample the vblank at all if the timestamp fails and splat a big WARN_ON
about this, to give driver writers a chance to fix up their mess?
-Daniel
The high precision timestamping is allowed to fail for a kms driver
under some conditions which are not implementation errors of the driver,
or getting disabled by user override, so we should handle that robustly.
We handle it robustly everywhere else in the drm, so we should do it
here as well.
E.g., nouveau generally supports timestamping/scanout position queries,
but can't support it on old pre NV-50 hardware with some output type
(either on analog VGA, or DVI-D, can't remember atm. which one is
unsupported).
There are also new Soc drivers showing up which support those methods,
but at least i didn't verify or test if their implementations are good
enough for the needs of the new drm_udpate_vblank_count() which is more
sensitive to kms drivers being even slightly off.
-mario
Fix this by checking if the old timestamp used for this calculations
is zero == invalid. If so, perform a counter increment of +1 to
prevent large counter jumps and reinitialize the timestamps to
sane values.
Signed-off-by: Mario Kleiner <mario.kleiner.de@xxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx> # 4.4+
Cc: michel@xxxxxxxxxxx
Cc: vbabka@xxxxxxx
Cc: ville.syrjala@xxxxxxxxxxxxxxx
Cc: daniel.vetter@xxxxxxxx
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Cc: alexander.deucher@xxxxxxx
Cc: christian.koenig@xxxxxxx
---
drivers/gpu/drm/drm_irq.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index fb17c45..88bdf19 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -216,6 +216,13 @@ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe,
DRM_DEBUG_VBL("crtc %u: Redundant vblirq ignored."
" diff_ns = %lld, framedur_ns = %d)\n",
pipe, (long long) diff_ns, framedur_ns);
+
+ /* No valid t_old to calculate diff? Bump +1 to force reinit. */
+ if (t_old->tv_sec == 0 && t_old->tv_usec == 0) {
+ DRM_DEBUG_VBL("crtc %u: No baseline ts. Bump +1.\n",
+ pipe);
+ diff = 1;
+ }
} else {
/* some kind of default for drivers w/o accurate vbl timestamping */
diff = (flags & DRM_CALLED_FROM_VBLIRQ) != 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html