linux-toradex.git/drivers/gpu/drm/drm_irq.c, branch v4.9.114

drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)

2018-03-22T08:17:39+00:00

[ Upstream commit 608b20506941969ea30d8c08dc9ae02bb87dbf7d ]

On vblank instant-off systems, we can get into a situation where the cost
of enabling and disabling the vblank IRQ around a drmWaitVblank query
dominates. And with the advent of even deeper hardware sleep state,
touching registers becomes ever more expensive.  However, we know that if
the user wants the current vblank counter, they are also very likely to
immediately queue a vblank wait and so we can keep the interrupt around
and only turn it off if we have no further vblank requests queued within
the interrupt interval.

After vblank event delivery, this patch adds a shadow of one vblank where
the interrupt is kept alive for the user to query and queue another vblank
event. Similarly, if the user is using blocking drmWaitVblanks, the
interrupt will be disabled on the IRQ following the wait completion.
However, if the user is simply querying the current vblank counter and
timestamp, the interrupt will be disabled after every IRQ and the user
will enabled it again on the first query following the IRQ.

v2: Mario Kleiner -
After testing this, one more thing that would make sense is to move
the disable block at the end of drm_handle_vblank() instead of at the
top.

Turns out that if high precision timestaming is disabled or doesn't
work for some reason (as can be simulated by echo 0 >
/sys/module/drm/parameters/timestamp_precision_usec), then with your
delayed disable code at its current place, the vblank counter won't
increment anymore at all for instant queries, ie. with your other
"instant query" patches. Clients which repeatedly query the counter
and wait for it to progress will simply hang, spinning in an endless
query loop. There's that comment in vblank_disable_and_save:

"* Skip this step if there isn't any high precision timestamp
 * available. In that case we can't account for this and just
 * hope for the best.
 */

With the disable happening after leading edge of vblank (== hw counter
increment already happened) but before the vblank counter/timestamp
handling in drm_handle_vblank, that step is needed to keep the counter
progressing, so skipping it is bad.

Now without high precision timestamping support, a kms driver must not
set dev->vblank_disable_immediate = true, as this would cause problems
for clients, so this shouldn't matter, but it would be good to still
make this robust against a future kms driver which might have
unreliable high precision timestamping, e.g., high precision
timestamping that intermittently doesn't work.

v3: Patch before coffee needs extra coffee.

Testcase: igt/kms_vblank
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Michel Dänzer 
Cc: Laurent Pinchart 
Cc: Dave Airlie ,
Cc: Mario Kleiner 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@chris-wilson.co.uk
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm: avoid uninitialized timestamp use in wait_vblank

2017-01-19T19:18:06+00:00

commit cff52e5fc4cfc978b7df898dc14a0492c7ef0ae8 upstream.

gcc warns about the timestamp in drm_wait_vblank being possibly
used without an initialization:

drivers/gpu/drm/drm_irq.c: In function 'drm_crtc_send_vblank_event':
drivers/gpu/drm/drm_irq.c:992:24: error: 'now.tv_usec' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpu/drm/drm_irq.c:1069:17: note: 'now.tv_usec' was declared here
drivers/gpu/drm/drm_irq.c:991:23: error: 'now.tv_sec' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This can happen if drm_vblank_count_and_time() returns 0 in its
error path. To sanitize the error case, I'm changing that function
to return a zero timestamp when it fails.

Fixes: e6ae8687a87b ("drm: idiot-proof vblank")
Reviewed-by: David Herrmann 
Cc: Rob Clark 
Cc: Daniel Vetter 
Signed-off-by: Arnd Bergmann 
Reviewed-by: Mario Kleiner 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20161017221355.1861551-6-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman

drm: Document caveats around atomic event handling

2016-10-04T06:23:15+00:00

It's not that obvious how a driver can all race the atomic commit with
handling the completion event. And there's unfortunately a pile of
drivers with rather bad event handling which misdirect people into the
wrong direction.

Try to remedy this by documenting everything better.

v2: Type fixes Alex spotted.

v3: More typos Alex spotted.

Cc: Andrzej Hajda 
Cc: Alex Deucher 
Reviewed-by: Alex Deucher 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1475229896-6047-1-git-send-email-daniel.vetter@ffwll.ch

drm/doc: Fix more kerneldoc/sphinx warnings

2016-08-16T14:09:58+00:00

These are the leftovers I could only track down using keep_warnings =
True. For some of them we might want to update our style guide on how
to reference structures and constants, not sure ...

Cc: Markus Heiser 
Cc: Jonathan Corbet 
Cc: linux-doc@vger.kernel.org
Reviewed-by: Sean Paul 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-1-git-send-email-daniel.vetter@ffwll.ch

drm: Make sure drm_vblank_no_hw_counter isn't abused

2016-08-08T18:34:05+00:00

Shouldn't be possible since everyone kzallocs this, but better safe
than sorry. Random drive-by-idea really.

Cc: Rodrigo Vivi 
Signed-off-by: Daniel Vetter 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Sean Paul 
Link: http://patchwork.freedesktop.org/patch/msgid/1470673493-14304-1-git-send-email-daniel.vetter@ffwll.ch

drm: Used DRM_LEGACY for all legacy functions

2016-08-08T08:05:23+00:00

Except for nouveau, only legacy drivers need this really. And nouveau
is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special
case.

I've tried to be careful to leave everything related to modeset still
using the DRIVER_MODESET flag. Otherwise it's a direct replacement of
!DRIVER_MODESET with DRIVER_LEGACY checks. Also helps readability
since fewer negative checks overall.

Reviewed-by: David Herrmann 
Reviewed-by: Frank Binns 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-2-git-send-email-daniel.vetter@ffwll.ch

drm: Avoid printing negative values for unsigned variables.

2016-08-08T08:05:15+00:00

It was really strange to see negative vblank seqs on debug
messages. It is rare to have that big number, but when it
happens it is confusing and misleading.

Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1470243226-2750-1-git-send-email-rodrigo.vivi@intel.com

drm: Extract&Document drm_irq.h

2016-07-19T08:29:47+00:00

The drm_irq docs want one function from drmP.h, but that one is a
serious mess. Extract it, and while at it improve the docs a bit.
There's a bit a header loop issue since core data structures like
drm_device and drm_driver aren't in their own headers yet, which means
the drm_irq.h include in drmP.h needs to be in just the right spot :(

Also noticed that drm_vblank_crtc->last_wait is entirely unused,
remove it.

v2: git add drm_irq.h ...

Acked-by: Chris Wilson 
Signed-off-by: Daniel Vetter

drm: make drm_vblank_count_and_time() static

2016-07-12T13:40:45+00:00

As they are not used anywhere outside drm_irq.c make them static.

Signed-off-by: Gustavo Padovan 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1467677092-5089-1-git-send-email-gustavo@padovan.org

drm: Only handle _DRM_VBLANK_NEXTONMISS once

2016-07-12T10:54:50+00:00

Consolidate the _DRM_VBLANK_NEXTONMISS handling between drm_wait_vblank
and drm_queue_vblank_event.

This is a cleanup spotted while working on other changes.

(The way it was previously handled could also theoretically result in
drm_queue_vblank_event unnecessarily bumping vblwait->request.sequence,
if the vblank counter happened to increment between the
drm_vblank_count(_and_time) calls in each function, but that's unlikely)

Signed-off-by: Michel Dänzer 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1466755187-29418-1-git-send-email-michel@daenzer.net