In

commit c6df39b5
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Apr 14 20:24:29 2014 +0300

    drm/i915: get a runtime PM ref for the deferred GT powersave enabling

I added an RPM get-ref when enabling RPS from a deferred work, but forgot
to add the corresponding put-ref when canceling the work. This may leave
RPM disabled.

Note that the race is real since we run the rps enabling with a
delayed work item after resume, so leaves enough time (in contrived
examples) to fit a quick autoresum in.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRobert Beckett <robert.beckett@intel.com>
Testecase: igt/pm_rpm/system-suspend
[danvet: Mention testcase and add note.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such accesses, remove the mappings before calling
the handlers. Spotted by Ville.

Also Chris pointed out that the lists that i915_gem_release_all_mmaps()
walks through need dev->struct_mutex, so take this lock. There is a
potential deadlock against a concurrent RPM resume, resolve this by
aborting and rescheduling the suspend (Daniel).

v2:
- take struct_mutex around i915_gem_release_all_mmaps() (Chris, Daniel)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRobert Beckett <robert.beckett@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Apparently we need to disable VCP unit clock gating around media reset
on g4x.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On gen2 the scanline counter behaves a bit differently from the
later generations. Instead of adding one to the raw scanline
counter value, we must subtract one.

On HSW/BDW the scanline counter requires a +2 adjustment on HDMI
outputs. DP outputs on the on the other require the typical +1
adjustment.

As the fixup we must apply to the hardware scanline counter
depends on several factors, compute the desired offset at modeset
time and tuck it away for when it's needed.

v2: Clarify HSW+ situation
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: "Akash Goel <akash.goels@gmail.com>"
Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78997Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The docs are a bit lacking when it comes to describing when certain
timing related events occur in the hardware. Draw a picture which
tries to capture the most important ones.

v2: Clarify a few details (Imre)
v3: Add HSW+ HDMI scanline counter numbers
Acked-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NAkash Goel <akash.goels@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>"
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently the logic to fix up the frame counter on gen3/4 assumes that
start of vblank occurs at vblank_start*htotal pixels, when in fact
it occurs htotal-hsync_start pixels earlier. Apply the appropriate
adjustment to make the frame counter more accurate.

Also fix the vblank start position for interlaced display modes.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: "Akash Goel <akash.goels@gmail.com>"
Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>"
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In interlaced modes, the pixel counter counts all pixels,
so one field will have htotal more pixels. In order to avoid
the reported position from jumping backwards when the pixel
counter is beyond the length of the shorter field, just
clamp the position the length of the shorter field. This
matches how the scanline counter based position works since
the scanline counter doesn't count the two half lines.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: "Akash Goel <akash.goels@gmail.com>"
Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>"
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Daniel keeps on ramping up the warning level of the DRM and our display
core to make it complain whenever the locking rules are not followed.
This caught

commit 24576d23
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Mar 26 09:25:45 2013 -0700

    drm/i915: enable VT switchless resume v3

introducing an unlocked access to the CRTC whilst disabling it for
suspend.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78114Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Before purging our pages (as opposed to copying back the contents from
the GPU), make sure that there is not an exposed CPU mmapping through
which the user can inspect the results.

Regression from

commit 5537252b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Mar 25 13:23:06 2014 +0000

    drm/i915: Invalidate our pages under memory pressure

Testcase: igt/gem_mmap/new-object
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79005Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NGuo Jinxian <jinxianx.guo@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have to write to the primary plane base address registrer when we
enable/disable the primary plane in response to sprite coverage. Those
writes will cause the flip counter to increment which could interfere
with the detection of CS flip completion. We could end up completing
CS flips before the CS has even executed the commands from the ring.

To avoid such issues, wait for CS flips to finish before we toggle the
primary plane on/off.

v2: Rebased due to atomic sprite update changes

Testcase: igt/kms_mmio_vs_cs_flip/setplane_vs_cs_flip
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the current code, we unconditionally touch
HSW_AUD_PIN_ELD_CP_VLD, which means we can touch it when the power
well is off, and that will trigger an "Unclaimed register" message.

Just adding the intel_crtc->config.has_audio should already avoid the
unclaimed register messsages, but since we actually need the power
well to make the Audio code work, it makes sense to also grab the
audio power domain reference, and release it when it's not needed
anymore.

I used IGT's pm_rpm to reproduce this bug, but it can probably be
reproduced on other tests that do modesets. I'm using a machine with
eDP+HDMI connected.

Regression introduced by:

commit acfa75b0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Apr 24 23:54:51 2014 +0200
    drm/i915: Simplify audio handling on DDI ports

Credits to Daniel for suggesting this implementation.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because this will trigger "Unclaimed register" messages. All I need to
reproduce this problem is to boot my HSW machine with eDP+HDMI
connected.

Regression introduced by:

commit 9ed109a7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Apr 24 23:54:52 2014 +0200
    drm/i915: Track has_audio in the pipe config

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Adding stuff at the bottom is really no how this should be done, since
that's the place for ums/dri dungeons.

This was added in

commit a8ebba75
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Thu Apr 17 10:37:40 2014 +0800

    drm/i915: Use the coarse ping-pong mechanism based on drm fd to dispatch the BSD command on BDW GT3

Also add a note to prevent this from happening again - people really
should be less lazy and take more time to look for a good home of
their new driver-global state.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Gen2 reports FIFO underruns whenever no planes are enabled on the pipe.
So in order to avoid false positives we must enable the FIFO underrun
reporting only when at least one plane is enabled on the pipe. For
now just move the underrun reporting enable/disable points to the
other side of the plane enable/disable point. That doesn't cover cases
when we turn off all the planes for the pipe but leave the pipe running
on purpose, but it's better than the current situation.

On gen4+ we can actually move the underrun reporting enable/disable to
the opposite ends of the crtc enable/disable hooks. I suppose in theory
we could leave the underrun reporting enabled all the time, except on
VLV where PIPESTAT stops working when the display power well is down.
If we ever get around to unifying the PIPESTAT irq handling for all
gmch platforms, we should still follow the VLV route for other platforms.
It would also micro-optimize the irq handler a bit since we could then
skip the PIPESTAT reads for all disabled pipes.

Gen3 is still a mystery, but for now I'm going to assume it behaves
like gen4+.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThomas Wood <thomas.wood@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Checking whether the error interrupt was enabled or not isn't really
necessary when we check for uncleared FIFO underruns. If it was enabled
we'll race with the interrupt handler a bit, but that seems OK as we
still claim the interrupt.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThomas Wood <thomas.wood@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

FIFO underruns don't generate interrupts on gmch platforms, so
if we want to know whether a modeset triggered FIFO underruns we
need to explicitly check for them.

As a modeset on one pipe could cause underruns on other pipes,
check for underruns on all pipes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThomas Wood <thomas.wood@intel.com>
[danvet: Fix up merge error, kudos to Ville for noticing it.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

FIFO underruns don't generate an interrupt on gmch platforms, so we
should check whether there were any that we failed to notice when
we're disabling FIFO underrun reporting.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThomas Wood <thomas.wood@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Noticed by Thierry Reding in his review, but I've merged the drm
vblank rework topic branch a bit too quickly. So separate fixup.

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The ascii art version of the DPIO diagram gets mangled by docbook, so
we can't use it there. Insted provide another version built using
<table>.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Document the internal structure of the VLV display PHY a bit to help
people understand how the different register blocks relate to each
other.

v2: Add a bit more text
    Make it a DOC: comment, but leave the ascii art out since
    it would get mangled
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

for proper refcounting to take place as we use
i915_add_request() for it.

i915_add_request() also takes the context for the request
from ring->last_context so move the null state batch
submission after the ring context has been set.

v2: we need to check for correct ring now (Ville Syrjälä)
v3: no need to expose i915_gem_move_object_to_active (Chris Wilson)
v4: cargoculted vma/active/inactive error handling removed (Chris Wilson)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If a pipe is already active when we init/resume there might not be a
full modeset afterwards so drm_vblank_on() may not get called. In such
a case if someone is holding a vblank reference across a suspend/resume
cycle drm_vblank_get() called after resuming won't re-enable the vblank
interrupts.

So in order to make sure vblank interrupts get re-enabled post-resume,
call drm_vblank_on() in intel_sanitize_crtc() if the crtc is already
active.

v2: Also drm_vblank_off() if the pipe got disabled magically
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Testecase: igt/kms_flip/vblank-vs-suspend
Tested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pull in the drm vblank rework from Ville and me. drm core parts acked
by Dave Airlie

Conflicts:
	drivers/gpu/drm/i915/intel_display.c

Just a bit of fun around the placement of drm_vblank_on. This merge
resolution has been tested in drm-intel-nightly for a while already.
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't have hardware based disable bits on gmch platforms, so need
to block spurious underrun reports in software. Which means that we
_must_ start out with fifo underrun reporting disabled everywhere.

This is in big contrast to ilk/hsw/cpt where there's only _one_
disable bit for all platforms and hence we must allow underrun
reporting on disabled pipes. Otherwise nothing really works,
especially the CRC support since that's key'ed off the same irq
disable bit.

This allows us to ditch the fifo underrun reporting hack from the vlv
runtime pm code and unexport the internal function from i915_irq.c
again. Yay!

v2: Keep the display irq disabling, spotted by Imre.

Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we unconditionally dtrt when disabling/enabling crtcs we
don't need any hacks any longer to keep the vblank logic sane when
all the registers go poof. So let's rip it all out.

This essentially undoes

commit 9dbd8feb
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Jul 23 10:48:11 2013 -0300

    drm/i915: update last_vblank when disabling the power well

Apparently igt/kms_flip is already powerful enough to exercise this
properly, yay! See the reference regression report for details.

v2: Update testcase name

References: https://bugs.freedesktop.org/show_bug.cgi?id=66808
Testcase: igt/kms_flip/vblank-vs-*-rpm
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only the low-level irq handling functions still use integer crtc
indices with this. But fixing that will require a lot more sugery
and some good ideas for backwards compat with old ums userspace.
Both in drivers and in the drm core.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to start somewhere ... With this the only places left in i915
where we use pipe integers is in the interrupt handling code. And
there it actually makes some amount of sense.

v2:
- Polish kerneldoc a bit (Thierry).
- Drop "dev" parameter since it's unecessary.
- Split out i915 changes (Thierry).

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

- Integrate into the drm DocBook
- Disable kerneldoc for functions not exported to drivers.
- Properly document the new drm_vblank_on|off and add cautious
  comments explaining when drm_vblank_pre|post_modesets shouldn't be
  used.
- General polish and OCD.

v2: Polish as suggested by Thierry.

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

Leftover from the old days of ums and should be used any longer. Since

commit 29935554
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Wed May 30 00:58:09 2012 +0200

    drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers

it is a complete no-Op for kms drivers.

v2: Fix up mangled sentence spotted by Michel.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Michel Dänzer <michel@daenzer.net>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Originally these functions have been for user modesetting drivers to
ensure vblank processing doesn't fall over completely around modeset
changes. This has been carried over ever since then.

Now that Ville cleaned our vblank handling with an explicit
drm_vblank_off/on braket when disabling/enabling crtcs. So this seems
to be unnecessary now. The most important side effect was that due to
the delayed vblank disabling we have been pretty much guaranteed to
receive a vblank interrupt soonish after a crtc was enabled.

Note that our vblank handling across modeset is still fairly decent
fubar - we don't actually handle vblank counter all to well.
drm_update_vblank_count will make sure that the frame counter always
rolls forward, but userspace isn't really all to ready to cope with
the big jumps this causes.

This isn't a big mostly because the hardware retains the frame
counter. But with runtime pm and also across suspend/resume we fall
over.

Fixing this is a lot more involved and also needs som i-g-ts. So
material for another patch series.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All of the .queue_flip() callbacks duplicate the same code to pin the
buffers and calculate the gtt_offset. Move that code to
intel_crtc_page_flip(). In order to do that we must also move the ring
selection logic there.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we've plugged the mmio vs. ring flip race, we shouldn't need
these vblank waits in the modeset codepaths anymore. So get rid of
them.

v2: gen2 needs to wait for planes to turn off before disabling pipe
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that the vblank wait is gone from intel_enable_primary_plane(),
hsw_enable_ips() needs to do the vblank wait itself.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Starting from ILK, mmio flips also cause a flip done interrupt to be
signalled. This means if we first do a set_base and follow it
immediately with the CS flip, we might mistake the flip done interrupt
caused by the set_base as the flip done interrupt caused by the CS
flip.

The hardware has a flip counter which increments every time a mmio or
CS flip is issued. It basically counts the number of DSPSURF register
writes. This means we can sample the counter before we put the CS
flip into the ring, and then when we get a flip done interrupt we can
check whether the CS flip has actually performed the surface address
update, or if the interrupt was caused by a previous but yet
unfinished mmio flip.

Even with the flip counter we still have a race condition of the CS flip
base address update happens after the mmio flip done interrupt was
raised but not yet processed by the driver. When the interrupt is
eventually processed, the flip counter will already indicate that the
CS flip has been executed, but it would not actually complete until the
next start of vblank. We can use the DSPSURFLIVE register to check
whether the hardware is actually scanning out of the buffer we expect,
or if we managed hit this race window.

This covers all the cases where the CS flip actually changes the base
address. If the base address remains unchanged, we might still complete
the CS flip before it has actually completed. But since the address
didn't change anyway, the premature flip completion can't result in
userspace overwriting data that's still being scanned out.

CTG already has the flip counter and DSPSURFLIVE registers, and
although the flip done interrupt is still limited to CS flips alone,
the code now also checks the flip counter on CTG as well.

v2: s/dspsurf/gtt_offset/ (Chris)

Testcase: igt/kms_mmio_vs_cs_flip/setcrtc_vs_cs_flip
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73027Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add g4x_ prefix to flip_count_after_eq.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We really just want to go detect displays again and fire off a hotplug
event if things have changed, not go through full hotplug processing.
Requested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since

commit 2e82a720
Author: Imre Deak <imre.deak@intel.com>
Date:   Fri Jan 17 15:46:43 2014 +0200

    drm/i915: don't disable DP port after a failed link training

and

commit 5d6a1116
Author: Imre Deak <imre.deak@intel.com>
Date:   Thu Jan 16 18:35:57 2014 +0200

    drm/i915: don't disable the DP port if the link is lost

we no longer call intel_dp_link_down from generic DP code, but only
from the !HAS_DDI dp encoder functions. hsw/bdw have their own encoder
disabling callback in intel_ddi.c.

Hence the early return is no longer needed and the big comment just
confusing, so let's rip it out. To ensure what we don't accidentally
use this again on ddi encoders add a WARN_ON instead.

Spotted while reading through intel_dp.c

Cc: Imre Deak <imre.deak@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_vblank_off() will turn off vblank interrupts, but as long as the
refcount is elevated drm_vblank_get() will not re-enable them. This
is a problem is someone is holding a vblank reference while a modeset is
happening, and the driver requires vblank interrupt to work during that
time.

Add drm_vblank_on() as a counterpart to drm_vblank_off() which will
re-enabled vblank interrupts if the refcount is already elevated. This
will allow drivers to choose the specific places in the modeset sequence
at which vblank interrupts get disabled and enabled.

Testcase: igt/kms_flip/*-vs-suspend
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add Testcase tag for the igt I've written.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If there's a blocking vblank wait in progress while the vblank interrupt
gets disabled, the current code will just let the vblank wait time out.
Instead make it return immediately when vblank interrupts get disabled.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently there's one per-device vblank disable timer, and it gets
reset wheneven the vblank refcount for any crtc drops to zero. That
means that one crtc could accidentally be keeping the vblank interrupts
for other crtcs enabled even if there are no users for them. Make the
disable timer per-crtc to avoid this issue.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>