Pull a (much shorter) overview into drm_irq.c, and instead put the
callback documentation into in-line comments in drm_drv.h.

v2: Move the include stanzas back to the split-up patch (Stefan).

Cc: Stefan Agner <stefan@agner.ch>
Reviewed-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170531092253.12833-1-daniel.vetter@ffwll.ch

drm_irq.c contains both the irq helper library (optional) and the
vblank support (optional, but part of the modeset uapi, and doesn't
require the use of the irq helpers at all.

Split this up for more clarity of the scope of the individual bits.

v2: Move misplaced hunks to this patch (Stefan).

Cc: Stefan Agner <stefan@agner.ch>
Reviewed-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170531092146.12528-1-daniel.vetter@ffwll.ch

In the previous patch we've implemented hwmode tracking a la i915 for
the vblank timestamp calculations. But that was just the basic
semantics, i915 has some nice sanity checks to make sure we keep
getting this right. Move them over too.

v2:
- WARN_ON_ONCE to avoid excessive spam (Ville)
- Really only WARN on atomic drivers.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-5-daniel.vetter@ffwll.ch

If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:

- All legacy drivers look at crtc->hwmode. But that is updated already
  at the beginning of the modeset helper, which means when we disable
  a pipe. Hence the final timestamps might be a bit off. But since
  this is an existing bug I'm not going to change it, but just try to
  be bug-for-bug compatible with the current code. This only applies
  to radeon&amdgpu.

- i915 tries to get it perfect by updating crtc->hwmode when the pipe
  is off (i.e. vblank->enabled = false).

- All other atomic drivers look at crtc->state->adjusted_mode. Those
  that look at state->requested_mode simply don't adjust their mode,
  so it's the same. That has two problems: Accessing crtc->state from
  interrupt handling code is unsafe, and it's updated before we shut
  down the pipe. For nonblocking modesets it's even worse.

For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.

For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.

The  benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.

v2: Completely new approach, trying to mimick the i915 solution.

v3: Fixup kerneldoc.

v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.

v5: Fix typos and move misplaced hunks to the right patches (Neil).

v6: Undo hunk movement (kbuild).

Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch

It's overkill to have a flag parameter which is essentially used just
as a boolean. This takes care of core + adjusting drivers.

Adjusting the scanout position callback is a bit harder, since radeon
also supplies it's own driver-private flags in there.

v2: Fixup misplaced hunks (Neil).

v3: kbuild says v1 was better ...

Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-2-daniel.vetter@ffwll.ch

There's really no reason for anything more:
- Calling this while the crtc vblank stuff isn't set up is a driver
  bug. Those places alrready DRM_ERROR.
- Calling this when the crtc is off is either a driver bug (calling
  drm_crtc_handle_vblank at the wrong time) or a core bug (for
  anything else). Again, we DRM_ERROR.
- EINVAL is checked at higher levels already, and if we'd use struct
  drm_crtc * instead of (dev, pipe) it would be real obvious that
  those are again core bugs.

The only valid failure mode is crap hardware that couldn't sample a
useful timestamp, to ask the core to just grab a not-so-accurate
timestamp. Bool is perfectly fine for that.

v2: Also fix up the one caller, I lost that in the shuffling (Jani).

v3: Fixup commit message (Neil).

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Cc: Eric Anholt <eric@anholt.net>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-1-daniel.vetter@ffwll.ch

With the atomic API, it is possible that a single commit affects
multiple crtcs. If the user requests an event with that commit, one
event will be sent for each CRTC, but it is not possible to distinguish
which crtc an event is for in user space. To solve this, the reserved
field in struct drm_vblank_event is repurposed to include the crtc_id
which the event is for.

The DRM_CAP_CRTC_IN_VBLANK_EVENT is added to allow userspace to query if
the crtc field will be set properly.

[daniels: Rebased, using Maarten's forward-port.]
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Stone <daniels@collabora.com>
Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170404165221.28240-2-daniels@collabora.com

ARM v6 (at least) only allows cmpxchg on 32bit variables which doesn't
always include the bool type.

drivers/built-in.o: In function `vblank_disable_and_save':
imx-ocotp.c:(.text+0xb45e8): undefined reference to `__bad_cmpxchg'
Makefile:986: recipe for target 'vmlinux' failed
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Reported-by: NLeonard Crestez <leonard.crestez@nxp.com>
Fixes: 43dc7fe2 ("drm: Mark up accesses of vblank->enabled outside of its spinlock")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170330140832.32377-1-chris@chris-wilson.co.uk

Bypass all the spinlocks and return the last timestamp and counter from
the last vblank if the driver delcares that it is accurate (and stable
across on/off), and the vblank is currently enabled.

This is dependent upon the both the hardware and driver to provide the
proper barriers to facilitate reading our bookkeeping outside of the
vblank interrupt and outside of the explicit vblank locks.
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>
Link: http://patchwork.freedesktop.org/patch/msgid/20170317202030.24410-4-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Move the repeated (a - b) <= (1 << 23) to its own function.

v2: Catch the '1<<23' inside drm_handle_vblank() as well
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Michel Dänzer <michel@daenzer.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170322100650.26082-1-chris@chris-wilson.co.ukReviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Since we cannot enable the vblank if !dev->irq_enabled, we assert that
checking for both !vblank->enabled and !dev->irq_enabled is tautological
and only need the former. The only time it may differ is when racing
with drm_irq_uninstall(), but that will then disable the vblank and
wakeup the waiters.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170317202030.24410-2-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Order the update to vblank->enabled after the timestamp is primed so
that a concurrent unlocked reader will only see the vblank->enabled with
the current timestamp.

v2: vblank->enable is guarded by dev->vbl_lock not
dev->vblank_time_lock, update the READ_ONCE accordingly.

Do not add a READ_ONCE(vblank->enabled) inside the interrupt handler to
avoid missing an interrupt whilst racing with enable_vblank()
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170317202030.24410-1-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

We want to provide the vblank irq shadow for pageflip events as well as
vblank queries. Such events are completed within the vblank interrupt
handler, and so the current check for disabling the irq will disable it
from with the same interrupt as the last pageflip event. If we move the
decision on whether to disable the irq (based on there no being no
remaining vblank events, i.e. vblank->refcount == 0) to before we signal
the events, we will only disable the irq on the interrupt after the last
event was signaled. In the normal course of events, this will keep the
vblank irq enabled for the entire flip sequence whereas before it would
flip-flop around every interrupt.

v2: Move the disable_fn() call outside of the vblank_event_lock.
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: Ville Syrjälä <ville.syrjala@linux.intel.com> #v1
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> #v1
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170324173058.23051-1-chris@chris-wilson.co.uk

The core code doesn't care at all about this, it's entirely dead.

Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170322083617.13361-11-daniel.vetter@ffwll.ch

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