Avoid adding to the waitqueue and reprobing the current vblank if the
caller is only querying the current vblank sequence and timestamp, where
we know that the wait would return immediately.

v2: Add CRTC identifier to debug messages
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Dave Airlie <airlied@redhat.com>,
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NMichel Dänzer <michel@daenzer.net>
Reviewed-and-tested-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-2-chris@chris-wilson.co.uk

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: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Dave Airlie <airlied@redhat.com>,
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170315204027.20160-1-chris@chris-wilson.co.uk

We might as well dump the drm_file pointer, that's about as useful
a cookie as the pid. Noticed while typing docs for drm_file and friends.

Since the only consumer of this is the tracepoints I think we can safely
change this - those tracepoints should not be uapi relevant at all. It
all goes back to

commit b9c2c9ae
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jul 1 16:48:09 2010 -0700

    drm: add per-event vblank event trace points

which doesn't give a special justification for using pid over a pointer.

Also note that the nouveau code setting it is entirely pointless:
Since this isn't a vblank event, it will never hit the vblank
tracepoints.

Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Reviewed-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-11-daniel.vetter@ffwll.ch

The function drm_vblank_no_hw_counter() is now only used in core vblank
wrapper code.  Let's unexport it by making it a static function.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1486458995-31018-4-git-send-email-shawnguo@kernel.org

The vblank is mostly CRTC specific and implemented as part of CRTC
driver.  Let's keep the vblank hooks struct drm_driver for legacy
drivers, and add corresponding hooks in struct drm_crtc_funcs.  These
hooks take struct drm_crtc pointer as argument, and will be called by
core vblank handling code for DRIVER_MODESET drivers.

The new hooks get plugged into core by adding wrapper functions for
vblank handling code.  The .get_vblank_counter hook is effectively
optional, as we provide drm_vblank_no_hw_counter() as the default
fallback in the wrapper function.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1486458995-31018-2-git-send-email-shawnguo@kernel.org

i915, nouveau (ever since merged to upstream) and radeon all lack ums
support in upstream. No point keeping the ums vgaarb support around.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-12-daniel.vetter@ffwll.ch

I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).

Also some minor drive-by polish where it makes sense, I read a lot
of docs ...

v2: Review from Gustavo.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-6-daniel.vetter@ffwll.ch

sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i

Originally I wasnt a friend of this style because I thought a
line-break between the "&struct" and "foo" part would break it. But a
quick test shows that " * &struct \n * foo\n" works pefectly well with
current kernel-doc. So time to mass-apply these changes!

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-6-git-send-email-daniel.vetter@ffwll.ch

Spotted while auditing our ioctl table. Also nuke the
not-really-kerneldoc comments, we don't document internals and
definitely don't want to mislead people with the old dragons.

I think with this all the legacy ioctls now have proper drm_legacy_
prefixes.
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161213230814.19598-2-daniel.vetter@ffwll.ch

Only remaining use was in amdgpu, and trivial to convert over to
drm_crtc_vblank_* variants.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161114090255.31595-5-daniel.vetter@ffwll.ch

No one outside of drm_irq.c should ever need this. The correct way to
implement get_vblank_count for hw lacking a vblank counter is
drm_vblank_no_hw_counter. Fix this up in mtk, which is the only
offender left over.

Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161114090255.31595-4-daniel.vetter@ffwll.ch

Now that all drivers are switched over to drm_crtc_vblank_on/off we
can relegate pre/post_modeset to the purely drm_irq.c internal role of
supporting old ums userspace.

As usual switch to the drm_legacy_ prefix to make it clear this is
for old drivers only.

v2: Rebase on top of Thierry's s/int crtc/unsigned int pipe/ changes.

Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

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: e6ae8687 ("drm: idiot-proof vblank")
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161017221355.1861551-6-arnd@arndb.de

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 <a.hajda@samsung.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475229896-6047-1-git-send-email-daniel.vetter@ffwll.ch

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 <markus.heiser@darmarit.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-1-git-send-email-daniel.vetter@ffwll.ch

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

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NRodrigo Vivi <rdorigo.vivi@intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470673493-14304-1-git-send-email-daniel.vetter@ffwll.ch

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: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NFrank Binns <frank.binns@imgtec.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-2-git-send-email-daniel.vetter@ffwll.ch

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: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470243226-2750-1-git-send-email-rodrigo.vivi@intel.com

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: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

As they are not used anywhere outside drm_irq.c make them static.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1467677092-5089-1-git-send-email-gustavo@padovan.org

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: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466755187-29418-1-git-send-email-michel@daenzer.net

Signed-off-by: NFrank Binns <frank.binns@imgtec.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466763337-27428-1-git-send-email-frank.binns@imgtec.com

The drm_pending_event can be freed by drm_send_event_locked, as a
result we should call trace_drm_vblank_event_delivered before this
to avoid hitting a user-after-free error when accessing the pid member:

[  378.438497] BUG: KASAN: use-after-free in send_vblank_event+0xf0/0x310 [drm] at addr ffff8801ac7e50a0
[  378.438500] Read of size 4 by task Xorg/1562
[  378.438501] =============================================================================
[  378.438504] BUG kmalloc-128 (Tainted: G    B          ): kasan: bad access detected
[  378.438506] -----------------------------------------------------------------------------

[  378.438509] INFO: Freed in 0x10001309c age=18446737369265680575 cpu=0 pid=0
[  378.438541]  drm_send_event_locked+0x207/0x2f0 [drm]
[  378.438544]  __slab_free+0x24c/0x650
[  378.438546]  kfree+0x3a2/0x760
[  378.438578]  drm_send_event_locked+0x207/0x2f0 [drm]
[  378.438610]  send_vblank_event+0xb7/0x310 [drm]
[  378.438643]  drm_crtc_send_vblank_event+0x130/0x1f0 [drm]
[  378.438722]  intel_atomic_commit_tail+0x23b5/0x53f0 [i915]
[  378.438802]  intel_atomic_commit+0xbae/0x12f0 [i915]
[  378.438839]  drm_atomic_commit+0xb0/0x120 [drm]
[  378.438855]  drm_atomic_helper_connector_dpms+0x339/0x5d0 [drm_kms_helper]
[  378.438891]  drm_mode_obj_set_property_ioctl+0x8f1/0xcc0 [drm]
[  378.438927]  drm_mode_connector_property_set_ioctl+0xf3/0x170 [drm]
[  378.438959]  drm_ioctl+0x2d7/0xae0 [drm]
[  378.438962]  do_vfs_ioctl+0x1c9/0x1280
[  378.438964]  SyS_ioctl+0x79/0x90
[  378.438967]  entry_SYSCALL_64_fastpath+0x1a/0xa4

Cc: dri-devel@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466440966-5410-1-git-send-email-matthew.auld@intel.com

As they are not used anywhere outside drm_irq.c make them static.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-4-git-send-email-gustavo@padovan.org

We don't have any user of this function anymore, let's remove it.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-3-git-send-email-gustavo@padovan.org

We don't have any user of this function anymore, let's remove it.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-2-git-send-email-gustavo@padovan.org

At least in drm core we only document the driver interfaces using
kerneldoc. For internals an unstructured comment is good enough.

Fixes a warning from kernel-doc, too.
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1464729075-22243-5-git-send-email-daniel.vetter@ffwll.ch

This patch aims to replace the roll-your-own seqlock implementation with
full-blown seqlock'. We also remove the timestamp ring-buffer in favour
of single timestamp/count pair protected by a seqlock. In turn this
means we can now increment the vblank freely without the need for
clamping.

v2:
  - reduce the scope of the seqlock, keeping vblank_time_lock
  - make the seqlock per vblank_crtc, so multiple readers aren't blocked by
    the writer

Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1462890088-18194-1-git-send-email-matthew.auld@intel.com

This was added in

commit 0a3e67a4
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Sep 30 12:14:26 2008 -0700

    drm: Rework vblank-wait handling to allow interrupt reduction.

to stay backwards-compatible with old UMS code that didn't even tell
the kernel when it did a modeset, so that the kernel could
save/restore vblank counters. At worst this means vblanks will be
somewhat funky on a setup that very likely no one still runs.

So let's just nuke it.

Plan B would be to set it unconditionally in drm_vblank_init for kms
drivers, instead of in each driver separately. So if this patch breaks
anything please only restore the hunks in drmP.h and drm_irq.c, plus
add a check for DRIVER_MODESET in drm_vblank_init.

Stumbled over this in a discussion on irc with Chris.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.

intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vblank handler has
run to completion. This function uses the timestamps to determine
when the last vblank has happened, and interpolates from there.

Changes since v1:
- Take vblank_time_lock and don't use drm_vblank_count_and_time.
Changes since v2:
- Don't return time of last vblank.
Changes since v3:
- Change pipe to unsigned int. (Ville)
- Remove unused documentation for tv_ret. (kbuild)
Changes since v4:
- Add warning to docs when the function is useful.
- Add a WARN_ON when get_vblank_timestamp is unavailable.
- Use drm_vblank_count.

Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v4
Acked-by: David Airlie <airlied@linux.ie> #irc, v4
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-2-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>

This reverts commit e91abf80.

Since

commit 24e4a8c3
Author: John Stultz <john.stultz@linaro.org>
Date:   Wed Jul 16 21:03:53 2014 +0000

    ktime: Kill non-scalar ktime_t implementation for 2038

there is no longer a 32bit version that's unsigned, and we don't have
to jump through ridiculous hoops to make the calculations correct.

I didn't look whether there's more of this pattern in the kernel.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459249942-21589-1-git-send-email-daniel.vetter@ffwll.ch

drm_vblank_offdelay can have three different types of values:

< 0 is to be always treated the same as dev->vblank_disable_immediate
= 0 is to be treated as "never disable vblanks"
> 0 is to be treated as disable immediate if kms driver wants it
    that way via dev->vblank_disable_immediate. Otherwise it is
    a disable timeout in msecs.

This got broken in Linux 3.18+ for the implementation of
drm_vblank_on. If the user specified a value of zero which should
always reenable vblank irqs in this function, a kms driver could
override the users choice by setting vblank_disable_immediate
to true. This patch fixes the regression and keeps the user in
control.

v2: Only reenable vblank if there are clients left or the user
    requested to "never disable vblanks" via offdelay 0. Enabling
    vblanks even in the "delayed disable" case (offdelay > 0) was
    specifically added by Ville in commit cd19e52a
    ("drm: Kick start vblank interrupts at drm_vblank_on()"),
    but after discussion it turns out that this was done by accident.

    Citing Ville: "I think it just ended up as a mess due to changing
    some of the semantics of offdelay<0 vs. offdelay==0 vs.
    disable_immediate during the review of the series. So yeah, given
    how drm_vblank_put() works now, I'd just make this check for
    offdelay==0."
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cc: <stable@vger.kernel.org> # 3.18+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: NDave Airlie <airlied@redhat.com>

Changes to drm_update_vblank_count() in Linux 4.4 broke the
behaviour of the pre/post modeset functions as the new update
code doesn't deal with hw vblank counter resets inbetween calls
to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it
should.

This causes mistreatment of such hw counter resets as counter
wraparound, and thereby large forward jumps of the software
vblank counter which in turn cause vblank event dispatching
and vblank waits to fail/hang --> userspace clients hang.

This symptom was reported on radeon-kms to cause a infinite
hang of KDE Plasma 5 shell's login procedure, preventing users
from logging in.

Fix this by detecting when drm_update_vblank_count() is called
inside a pre->post modeset interval. If so, clamp valid vblank
increments to the safe values 0 and 1, pretty much restoring
the update behavior of the old update code of Linux 4.3 and
earlier. Also reset the last recorded hw vblank count at call
to drm_vblank_post_modeset() to be safe against hw that after
modesetting, dpms on etc. only fires its first vblank irq after
drm_vblank_post_modeset() was already called.
Reported-by: NVlastimil Babka <vbabka@suse.cz>
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NVlastimil Babka <vbabka@suse.cz>

Cc: <stable@vger.kernel.org> # 4.4+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes a regression introduced by the new drm_update_vblank_count()
implementation in Linux 4.4:

Restrict the bump of the software vblank counter in drm_update_vblank_count()
to a safe maximum value of +1 whenever there is the possibility that
concurrent readers of vblank timestamps could be active at the moment,
as the current implementation of the timestamp caching and updating is
not safe against concurrent readers for calls to store_vblank() with a
bump of anything but +1. A bump != 1 would very likely return corrupted
timestamps to userspace, because the same slot in the cache could
be concurrently written by store_vblank() and read by one of those
readers in a non-atomic fashion and without the read-retry logic
detecting this collision.

Concurrent readers can exist while drm_update_vblank_count() is called
from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank-
irq callers. However, all those calls are happening with the vbl_lock
locked thereby preventing a drm_vblank_get(), so the vblank refcount
can't increase while drm_update_vblank_count() is executing. Therefore
a zero vblank refcount during execution of that function signals that
is safe for arbitrary counter bumps if called from outside vblank irq,
whereas a non-zero count is not safe.

Whenever the function is called from vblank irq, we have to assume concurrent
readers could show up any time during its execution, even if the refcount
is currently zero, as vblank irqs are usually only enabled due to the
presence of readers, and because when it is called from vblank irq it
can't hold the vbl_lock to protect it from sudden bumps in vblank refcount.
Therefore also restrict bumps to +1 when the function is called from vblank
irq.

Such bumps of more than +1 can happen at other times than reenabling
vblank irqs, e.g., when regular vblank interrupts get delayed by more
than 1 frame due to long held locks, long irq off periods, realtime
preemption on RT kernels, or system management interrupts.

A better solution would be to rewrite the timestamp caching to use
full seqlocks to allow concurrent writes and reads for arbitrary
vblank counter increments.

v2: Add code comment that this is essentially a hack and should
    be replaced by a full seqlock implementation for caching of
    timestamps.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Cc: <stable@vger.kernel.org> # 4.4+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: NDave Airlie <airlied@redhat.com>

Otherwise if a kms driver calls into drm_vblank_off() more than once
before calling drm_vblank_on() again, the redundant calls to
vblank_disable_and_save() will call drm_update_vblank_count()
while hw vblank counters and vblank timestamping are in a undefined
state during modesets, dpms off etc.

At least with the legacy drm helpers it is not unusual to
get multiple calls to drm_vblank_off and drm_vblank_on, e.g.,
half a dozen calls to drm_vblank_off and two calls to drm_vblank_on
were observed on radeon-kms during dpms-off -> dpms-on transition.

We don't no-op calls from atomic modesetting drivers, as they
should do a proper job of tracking hw state.

Fixes large jumps of the software maintained vblank counter due to
the hardware vblank counter resetting to zero during dpms off or
modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on
instead of drm_vblank_pre/post_modeset().

This fixes a regression caused by the changes made to
drm_update_vblank_count() in Linux 4.4.

v2: Don't no-op on atomic modesetting drivers, per suggestion
    of Daniel Vetter.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: NDave Airlie <airlied@redhat.com>

Well we can't use that directly since that code must hold
dev->event_lock already. Extract an _unlocked version.

Embarrassingly I've totally forgotten about this patch and any kind of
event-based vblank wait totally blew up, killing the kernel.

v2: Pick the right base struct, someone didn't noticed that gcc was
unhappy. No bug since the addresses at least matched (Daniel Stone)

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453978864-1513-1-git-send-email-daniel.vetter@ffwll.ch

Use them in the core vblank code and exynos/vmwgfx drivers.

Note that the difference between wake_up_all and _interruptible in
vmwgfx doesn't matter since the only waiter is the core code in
drm_fops.c. And that is interruptible.

v2: Adjust existing kerneldoc too.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Acked-by: NDaniel Stone <daniels@collabora.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Inki Dae <inki.dae@samsung.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452548477-15905-6-git-send-email-daniel.vetter@ffwll.chReviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
[danvet: Squash in compile fixup, spotted by 0-day.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We moved the module options from drm_drv.c to drm_irq.c in 18882995
('drm: Move vblank related module options into drm_irq.c').  Let's move
the MODULE_PARM_DESC()s as well so they're together.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160108110045.GF32195@mwandaSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Apparently pre-nv50 pageflip events happen before the actual vblank
period. Therefore that functionality got semi-disabled in

commit af4870e4
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Tue May 13 00:42:08 2014 +0200

    drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.

Unfortunately that hack got uprooted in

commit cc1ef118
Author: Thierry Reding <treding@nvidia.com>
Date:   Wed Aug 12 17:00:31 2015 +0200

    drm/irq: Make pipe unsigned and name consistent

Triggering a warning when trying to sample the vblank timestamp for a
non-existing pipe. There's a few ways to fix this:

- Open-code the old behaviour, which just enshrines this slight
  breakage of the userspace ABI.

- Revert Mario's commit and again inflict broken timestamps, again not
  pretty.

- Fix this for real by delaying the pageflip TS until the next vblank
  interrupt, thereby making it accurate.

This patch implements the third option. Since having a page flip
interrupt that happens when the pageflip gets armed and not when it
completes in the next vblank seems to be fairly common (older i915 hw
works very similarly) create a new helper to arm vblank events for
such drivers.

v2 (Mario Kleiner):
- Fix function prototypes in drmP.h
- Add missing vblank_put() for pageflip completion without
  pageflip event.
- Initialize sequence number for queued pageflip event to avoid
  trouble in drm_handle_vblank_events().
- Remove dead code and spelling fix.

v3 (Mario Kleiner):
- Add a signed-off-by and cc stable tag per Ilja's advice.

v4 (Thierry Reding):
- Fix kerneldoc typo, discovered by Michel Dänzer
- Rearrange tags and changelog

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
Cc: Thierry Reding <treding@nvidia.com>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Cc: stable@vger.kernel.org # v4.3
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Seems the crtc helpers call drm_calc_timestamping_constants()
unconditionally even if the driver didn't initialize vblank support by
calling drm_vblank_init(). That used to be OK since the constants were
stored under drm_crtc.

However I broke this with
commit eba1f35d ("drm: Move timestamping constants into drm_vblank_crtc")
when I moved the constants to live inside the drm_vblank_crtc struct
instead. If drm_vblank_init() isn't called, we don't allocate these
structures, and so drm_calc_timestamping_constants() will oops.

Fix it by adding a check into drm_calc_timestamping_constants() to see
if vblank support was initialized at all. And to keep in line with other
such checks, also toss in a check and warn for the case where vblank
support was initialized, but the wrong number of crtcs was specified.

Fixes the following sort of oops:
 BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
 IP: [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
 PGD 0
 Oops: 0002 [#1] SMP
 Modules linked in: sr_mod cdrom mgag200(+) i2c_algo_bit drm_kms_helper ahci syscopyarea sysfillrect sysimgblt libahci fb_sys_fops bnx2x ttm tg3(+) mdio drm ptp sd_mod libata i2c_core pps_core libcrc32c hpsa dm_mirror dm_region_hash dm_log dm_mod
 CPU: 0 PID: 418 Comm: kworker/0:2 Not tainted 4.3.0+ #1
 Hardware name: HP ProLiant DL380 Gen9, BIOS P89 06/09/2015
 Workqueue: events work_for_cpu_fn
 task: ffff88046ca95500 ti: ffff88007830c000 task.ti: ffff88007830c000
 RIP: 0010:[<ffffffffa014b266>]  [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
 RSP: 0018:ffff88007830f4e8  EFLAGS: 00010246
 RAX: 0000000000fe4c00 RBX: ffff88006a849160 RCX: 0000000000000540
 RDX: 0000000000000000 RSI: 000000000000fde8 RDI: ffff88006a849000
 RBP: ffff88007830f518 R08: ffff88007830c000 R09: 00000001b87e3712
 R10: 00000000000050c4 R11: 0000000000000000 R12: 0000000000fe4c00
 R13: ffff88006a849000 R14: 0000000000000000 R15: 000000000000fde8
 FS:  0000000000000000(0000) GS:ffff88046f800000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00000000000000b0 CR3: 00000000019d6000 CR4: 00000000001406f0
 Stack:
  ffff88007830f518 ffff88006a849000 ffff880c69b90340 ffff880c69b90000
  ffff880c69b90348 ffff880c69b90340 ffff88007830f748 ffffffffa042f7e7
  ffff88006a849090 0000000000000000 ffff88006a849160 0000000000000000
 Call Trace:
  [<ffffffffa042f7e7>] drm_crtc_helper_set_mode+0x3d7/0x4b0 [drm_kms_helper]
  [<ffffffffa04307d4>] drm_crtc_helper_set_config+0x8d4/0xb10 [drm_kms_helper]
  [<ffffffffa01548d4>] drm_mode_set_config_internal+0x64/0x100 [drm]
  [<ffffffffa043c342>] drm_fb_helper_pan_display+0xa2/0x280 [drm_kms_helper]
  [<ffffffff81392c7b>] fb_pan_display+0xbb/0x170
  [<ffffffff8138cf70>] bit_update_start+0x20/0x50
  [<ffffffff8138b81b>] fbcon_switch+0x39b/0x590
  [<ffffffff8140a3d0>] redraw_screen+0x1a0/0x240
  [<ffffffff8140b30e>] do_bind_con_driver+0x2ee/0x310
  [<ffffffff8140b651>] do_take_over_console+0x141/0x1b0
  [<ffffffff81387377>] do_fbcon_takeover+0x57/0xb0
  [<ffffffff8138c98b>] fbcon_event_notify+0x60b/0x750
  [<ffffffff810a5599>] notifier_call_chain+0x49/0x70
  [<ffffffff810a58dd>] __blocking_notifier_call_chain+0x4d/0x70
  [<ffffffff810a5916>] blocking_notifier_call_chain+0x16/0x20
  [<ffffffff8139282b>] fb_notifier_call_chain+0x1b/0x20
  [<ffffffff81394881>] register_framebuffer+0x1f1/0x330
  [<ffffffffa043d9aa>] drm_fb_helper_initial_config+0x27a/0x3d0 [drm_kms_helper]
  [<ffffffffa0469b4d>] mgag200_fbdev_init+0xdd/0xf0 [mgag200]
  [<ffffffffa0468586>] mgag200_modeset_init+0x176/0x1e0 [mgag200]
  [<ffffffffa0464659>] mgag200_driver_load+0x3f9/0x580 [mgag200]
  [<ffffffffa014e067>] drm_dev_register+0xa7/0xb0 [drm]
  [<ffffffffa015054f>] drm_get_pci_dev+0x8f/0x1e0 [drm]
  [<ffffffffa046937b>] mga_pci_probe+0x9b/0xc0 [mgag200]
  [<ffffffff813662d5>] local_pci_probe+0x45/0xa0
  [<ffffffff8109afe4>] work_for_cpu_fn+0x14/0x20
  [<ffffffff8109e13c>] process_one_work+0x14c/0x3c0
  [<ffffffff8109eaa4>] worker_thread+0x244/0x470
  [<ffffffff8168bfba>] ? __schedule+0x2aa/0x760
  [<ffffffff8109e860>] ? rescuer_thread+0x310/0x310
  [<ffffffff810a4438>] kthread+0xd8/0xf0
  [<ffffffff810a4360>] ? kthread_park+0x60/0x60
  [<ffffffff8169030f>] ret_from_fork+0x3f/0x70
  [<ffffffff810a4360>] ? kthread_park+0x60/0x60
 Code: f6 31 d2 41 89 c2 8b 83 b4 00 00 00 0f af c1 48 98 48 69 c0 40 42 0f 00 48 f7 f6 f6 43 74 10 41 89 c4 75 26 f6 05 9a 6f 03 00 01 <45> 89 96 b0 00 00 00 45 89 a6 ac 00 00 00 75 35 48 83 c4 08 5b
 RIP  [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
  RSP <ffff88007830f4e8>
 CR2: 00000000000000b0

Cc: Jeff Moyer <jmoyer@redhat.com>
Reported-by: NJeff Moyer <jmoyer@redhat.com>
References: http://lists.freedesktop.org/archives/dri-devel/2015-November/094217.html
Fixes: eba1f35d ("drm: Move timestamping constants into drm_vblank_crtc")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>