Finish the recent replacement of 'int pipe' with 'unsigned int pipe'

Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some of the functions are documented inconsistently. Add Returns:
sections where missing and use consistent style to describe the return
value.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Name all references to the pipe number (CRTC index) consistently to make
it easier to distinguish which is a pipe number and which is a pointer
to struct drm_crtc.

While at it also make all references to the pipe number unsigned because
there is no longer any reason why it should ever be negative.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When accessing the array of per-CRTC VBLANK structures we must always
check that the index into the array is valid before dereferencing to
avoid crashing.
Signed-off-by: NThierry Reding <treding@nvidia.com>
[danvet: Squash in my own whitespace ocd fixup in drm_vblank_count.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The drm_send_vblank_event() function treats negative CRTC indices as
meaning that a driver doesn't have proper VBLANK handling. This is the
only place where DRM needs negative CRTC indices, so in order to enable
subsequent cleanup, remove this special case and replace it by the more
obvious check for whether or not VBLANK support was initialized.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In

commit 99264a61
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 15 19:34:43 2015 +0200

    drm/vblank: Fixup and document timestamp update/read barriers

I've switched vblank->count from atomic_t to unsigned long and
accidentally created an integer comparison bug in
drm_vblank_count_and_time since vblanke->count might overflow the u32
local copy and hence the retry loop never succeed.

Fix this by consistently using u32.

Cc: Michel Dänzer <michel@daenzer.net>
Reported-by: NMichel Dänzer <michel@daenzer.net>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This patch fix following warnings.

Warning(.//drivers/gpu/drm/drm_irq.c:1279): No description
found for parameter drm_crtc'
Warning(.//drivers/gpu/drm/drm_irq.c:1279): Excess function
parameter 'crtc' description in 'drm_crtc_vblank_reset'
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

dev->max_vblank_count contains the largest value that can be represented
by the hardware counter. When the hardware counter wraps around, we have
to add that value + 1 to get the same value as if the hardware counter
didn't wrap around.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since commit 844b03f2 we make
sure that after vblank irq off, we return the last valid
(vblank count, vblank timestamp) pair to clients, e.g., during
modesets, which is good.

An overlooked side effect of that commit for kms drivers without
support for precise vblank timestamping is that at vblank irq
enable, when we update the vblank counter from the hw counter, we
can't update the corresponding vblank timestamp, so now we have a
totally mismatched timestamp for the new count to confuse clients.

Restore old client visible behaviour from before Linux 3.17, but
zero out the timestamp at vblank counter update (instead of disable
as in original implementation) if we can't generate a meaningful
timestamp immediately for the new vblank counter. This will fix
this regression, so callers know they need to retry again later
if they need a valid timestamp, but at the same time preserves
the improvements made in the commit mentioned above.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Cc: <stable@vger.kernel.org> #v3.17+

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since commit 844b03f2 we make
sure that after vblank irq off, we return the last valid
(vblank count, vblank timestamp) pair to clients, e.g., during
modesets, which is good.

An overlooked side effect of that commit for kms drivers without
support for precise vblank timestamping is that at vblank irq
enable, when we update the vblank counter from the hw counter, we
can't update the corresponding vblank timestamp, so now we have a
totally mismatched timestamp for the new count to confuse clients.

Restore old client visible behaviour from before Linux 3.18, but
zero out the timestamp at vblank counter update (instead of disable
as in original implementation) if we can't generate a meaningful
timestamp immediately for the new vblank counter. This will fix
this regression, so callers know they need to retry again later
if they need a valid timestamp, but at the same time preserves
the improvements made in the commit mentioned above.

v2: Rebased on top of Daniel Vetter's fixup and documentation
    patch for timestamp updates. Drop request for stable kernel
    backport as this would be more difficult, unless the original
    patch would get applied to stable kernels.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For a kms driver to support immediate disable of vblank
irq's reliably without introducing off by one errors or
other mayhem for clients, it must not only support a
hardware vblank counter query, but also high precision
vblank timestamping, so vblank count and timestamp can be
instantaneously reinitialzed to valid values. Additionally
the exposed hardware counter must behave as if it is
incrementing at leading edge of vblank to avoid off by
one errors during reinitialization of the counter while
the display happens to be inside or close to vblank.

Check during drm_vblank_init that a driver which claims to
be capable of vblank_disable_immediate at least supports
high precision timestamping and prevent use of instant
disable if that isn't present as a minimum requirement.

v2: Changed from DRM_ERROR to DRM_INFO and made message
    more clear, as suggested by Michel Dänzer.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need to be an atomic, writes are always done
  under the protection of dev->vblank_time_lock. Switch to an unsigned
  long instead and update comments. Note that atomic_read is just a
  normal read of a volatile variable, so no need to audit all the
  read-side access specifically.

- The barriers for the vblank counter seqlock weren't complete: The
  read-side was missing the first barrier between the counter read and
  the timestamp read, it only had a barrier between the ts and the
  counter read. We need both.

- Barriers weren't properly documented. Since barriers only work if
  you have them on boths sides of the transaction it's prudent to
  reference where the other side is. To avoid duplicating the
  write-side comment 3 times extract a little store_vblank() helper.
  In that helper also assert that we do indeed hold
  dev->vblank_time_lock, since in some cases the lock is acquired a
  few functions up in the callchain.

Spotted while reviewing a patch from Chris Wilson to add a fastpath to
the vblank_wait ioctl.

v2: Add comment to better explain how store_vblank works, suggested by
Chris.

v3: Peter noticed that as-is the 2nd smp_wmb is redundant with the
implicit barrier in the spin_unlock. But that can only be proven by
auditing all callers and my point in extracting this little helper was
to localize all the locking into just one place. Hence I think that
additional optimization is too risky.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Peter Hurley <peter@hurleysoftware.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-and-tested-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

drm_crtc_vblank_get() is the new drm_vblank_get(), not the new
drm_vblank_off().
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

KMS drivers are in full control of their irq and vblank handling, if
they get a vblank interrupt before drm_vblank_init or after
drm_vblank_cleanup that's just a driver bug.

For ums driver there's only r128 and radeon which support vblank, and
they call drm_vblank_init in their driver load functions. Which again
means that userspace can do whatever it wants with interrupt, vblank
structures will always be there.

So this should never happen, let's catch driver issues with a WARN_ON.
Motivated by some discussions with Imre.

v2: Use WARN_ON_ONCE as suggested by Imre.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

The pipe might already have been shut down, and then it's not a good
idea to call hw accessor functions. Instead use the same logic as
drm_vblank_off which has all the necessary checks to avoid troubles or
inconsistency.

Noticed by Imre while reviewing my patches to remove some sanity
checks from ->get_vblank_counter.

v2: Try harder. disable_and_save can still access the vblank stuff
when vblank->enabled isn't set. It has to, since vlbank irq could be
disable but the pipe is still on when being called from
drm_vblank_off. But we still want to use that code for more code
sharing. So add a check for vblank->enabled on top - if that's not set
we shouldn't have anyone waiting for the vblank. If we have that's a
pretty serious bug.

The other issue that Imre spotted is drm_vblank_cleanup. That code
again calls disable_and_save and so suffers from the same issues. But
really drm_irq_uninstall should have cleaned that all up, so replace
the code with WARN_ON. Note that we can't delete the timer cleanup
since drivers aren't required to use drm_irq_install/uninstall, but
can do their own irq handling.

v3: Make it clear that all that gunk in drm_irq_uninstall is really
just bandaids for UMS races between the irq/vblank code. In UMS
userspace is in control of enabling/disabling interrupts in general
and vblanks specifically.

v4: Imre observed that KMS drivers all call drm_vblank_cleanup before
drm_irq_uninstall (as they should), so again the code in there is dead
for KMS (due to dev->num_crtcs == 0 after drm_vblank_cleanup). Or
should be, so only WARN for KMS - with UMS userspace could try to do
evil things.

v5: After more discussion on irc we've gone back to v3: the
del_timer_sync is required in all cases in drm_vblank_cleanup, but
let's restrict the WARN_ON to kms drivers only. Imre was also
concerned that bad things could happen without the disable_and_save
call. But we immediately free vblank structures afterwards which makes
the save useless. And drm_handle_vblank has a check for dev->num_crtcs
to avoid surprises with ums.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

At driver load we need to tell the vblank code about the state of the
pipes, so that the logic around reject vblank_get when the pipe is off
works correctly.

Thus far i915 used drm_vblank_off, but one of the side-effects of it
is that it also saves the vblank counter. And for that it calls down
into the ->get_vblank_counter hook. Which isn't really a good idea
when the pipe is off for a few reasons:
- With runtime pm the register might not respond.
- If the pipe is off some datastructures might not be around or
  unitialized.

The later is what blew up on gen3: We look at intel_crtc->config to
compute the vblank counter, and for a disabled pipe at boot-up that's
just not there. Thus far this was papered over by a check for
intel_crtc->active, but I want to get rid of that (since it's fairly
race, vblank hooks are called from all kinds of places).

So prep for that by adding a _reset functions which only does what we
really need to be done at driver load: Mark the vblank pipe as off,
but don't do any vblank counter saving or event flushing - neither of
that is required.

v2: Clarify the code flow slightly as suggested by Ville.

v3: Fix kerneldoc spelling, spotted by Laurent.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v2)
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

The .enable_vblank() operation is only called when vblank interrupts are
disabled, but no similar check exists when disabling vblank interrupts.
This leads to .disable_vblank() being called with vblank interrupts
already disabled and the device possibly runtime suspended. As the
operation is called with a spinlock held drivers can't runtime resume
the device there and thus must avoid touching device registers in that
case, requiring vblank refcounting.

As the DRM core tracks whether vblank interrupts are enabled just skip
the .disable_vblank() call when the interrupts are already disabled.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This function is the KMS native variant of drm_vblank_count(). It takes
a struct drm_crtc * instead of a struct drm_device * and an index of the
CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This function is the KMS native variant of drm_handle_vblank(). It takes
a struct drm_crtc * instead of a struct drm_device * and an index of the
CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This function is the KMS native variant of drm_send_vblank_event(). It
takes a struct drm_crtc * instead of a struct drm_device * and an index
of the CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

sizeof(type) is the variant used most commonly and required by
checkpatch.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A couple of whitespace changes required to silent various errors and
warnings flagged by checkpatch.

checkpatch requires that the opening brace be on the same line as a
variable declaration. Furthermore an empty line is required after a
block of variable declarations. Trailing whitespace as well as using
spaces before tabs is considered an error or warning, respectively.
Finally, the closing parenthesis of an if condition and the opening
brace of the conditional block should be separated by a space.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Let's make things a bit easier to debug when things go bad (potentially
under console_lock).
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch fix spelling typos found in drm.xml.
It is because the file is generated from comments in
source codes, I have to fix the typos within source files.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This replicates what we've done in i915 in

commit 31e4b89a
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Mon Aug 18 13:51:00 2014 +0100

    drm/i915: Print the pipe on which the vblank wait times out

to make sure that when we switch i915 to drm_wait_one_vblank that the
debug output doesn't regress.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

If we already have a timestamp for the current vblank counter, don't
update it with a new timestmap. Small errors can creep in between two
timestamp queries for the same vblank count, which could be confusing to
userspace when it queries the timestamp for the same vblank sequence
number twice.

This problem gets exposed when the vblank disable timer is not used
(or is set to expire quickly) and thus we can get multiple vblank
disable<->enable transition during the same frame which would all
attempt to update the timestamp with the latest estimate.

Testcase: igt/kms_flip/flip-vs-expired-vblank
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>

v2:Mario: Trivial rebase on top of current drm-next (13-Sep-2014)
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This allows us to drop 2 header declarations from drmP.h. The 3rd one
is also used in drm_ioctl.c, so for that create a new drm_internal.h
header for non-legacy non-kms (since we have internal headers for
those parts already) declarations private to drm.ko.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've read INVBL as "invalid backlight" and got mightly confused.
The #defines are already fairly long and we can afford to extend
them a bit more without resulting in ugly code all over.

I'm not sure how useful the complicated bitmask return value of these
functions really are since no one checks them. But for now let's keep
things as is.

Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville 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>

Imo u32 hints at a register value, but in reality all callers only
care whether the sampled timestamp is precise or not. So give them
just a bool.

Also move the declaration out of drmP.h, it's only used in drm_irq.c.

v2: Also drop the EXPORT_SYMBOL, spotted by Mario.

Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Drivers without a hardware vblank counter simply can't account for the
vblanks that happened while the vblank interrupt was off. To check
this grab a vblank timestamp and if the result is dubious follow the
normal save-and-disable logic.

Drivers should prevent this by setting vblank_disable_allowed = false,
but since running vblank interrupts constantly is not good for power
consumption most drivers lie. Testing for precise vblank timestamps is
the next best thing we can check for.
Suggested-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

With the new support for immediate vblank disabling we always disabled
the vblank interrupt right away, irrespective of the vblank offdelay
setting.

But being able to let vblanks run forever is fairly useful for
debugging, so restore that behaviour.
Suggested-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Calling vblank_disable_fn() will cause that function to no-op
if !dev->vblank_disable_allowed for some kms drivers, e.g.,
on nouveau-kms. This can cause the gpu vblank irq's to not get
disabled before freeing the dev->vblank array, so if a
vblank irq fires and calls into drm_handle_vblank() after
drm_vblank_cleanup() completes, it will cause use-after-free
access to dev->vblank array.

Call vblank_disable_and_save unconditionally, so vblank irqs
are guaranteed to be off, before we delete the data structures
on which they operate.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Fix subsystem name in patch subject.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As usual in both a crtc index and a struct drm_crtc * version.

The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.

v2: Also check dev->max_vblank_counter since some drivers register a
fake get_vblank_counter function.

v3: Use drm_vblank_count instead of calling the low-level
->get_vblank_counter callback. That way we'll get the sw-cooked
counter for platforms without proper vblank support and so can ditch
the max_vblank_counter check again.

v4: Review from Michel Dänzer:
- Restore lost notes about v3:
- Spelling in kerneldoc.
- Inline wait_event condition.
- s/vblank_wait/wait_one_vblank/

Cc: Michel Dänzer <michel@daenzer.net>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_vblank_cleanup() would operate on non-existent dev->vblank
data structure, as failure to allocate that data structure is
what triggers the error path in the first place.
Signed-off-by: NMario 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>

During vblank disable the code tries to guess based on the
timestamps whether we just missed one vblank or not. And if so
it increments the counter. However it forgets to store the new
timestamp to the approriate slot in our timestamp ring buffer.
So anyone querying the timestamp for the resulting sequence
number would get a stale timestamp. Fix it up by storing the
new timestamp.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that drm_update_vblank_count() can be called even when we're not
about to enable the vblank interrupts we shouldn't print debug messages
stating otherwise.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the user is interested in getting accurate vblank sequence
numbers all the time they may disable the vblank disable timer
entirely. In that case it seems appropriate to kick start the
vblank interrupts already from drm_vblank_on().

v2: Adapt to the drm_vblank_offdelay ==0 vs <0 changes
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a flag to drm_device which will cause the vblank code to bypass the
disable timer and always disable the vblank interrupt immediately when
the last reference is dropped.

v2: Add some notes about the flag to the kernel doc
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>