Dynamic context pinning for LRCs introduced a leak in legacy mode.
Reinstate context unreference in i915_gem_free_request for legacy contexts.

Leak reported by i-g-t/drv_module_reload fixed by this patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86507Signed-off-by: NThomas Daniel <thomas.daniel@intel.com>
Reviewed-by: John Harrison<John.C.Harrison@Intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Updates in forcewake range for Render/Media/Common
power wells for Gen9.
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Signed-off-by: NZhe Wang <zhe1.wang@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Before testing if the panel VDD is enabled on eDP cancel any pending
disable worker. This makes sure the worker will be triggered with a
delay from the last time edp_panel_vdd_schedule_off() is called, not
the first time. This avoids unnecessary overhead.

https://bugs.freedesktop.org/show_bug.cgi?id=86201

v2: use cancel_delayed_work() instead of cancel_delayed_work_sync()
as the pps_mutexes will provide the required serialization with
edp_panel_vdd_work() while the sync variant may deadlock. Suggested
by Ville Syrjälä <ville.syrjala@linux.intel.com>.
Made commit message a bit clearer.
Signed-off-by: NEgbert Eich <eich@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The crc code doesn't handle anything really that could drop the
register state (by design so that we have less complexity). Which
means userspace may only start crc capture once the pipe is fully set
up.

With an i-g-t patch this will be the case, but there's still the
problem that this results in obscure unclaimed register write
failures. Which is a pain to debug.

So instead make sure we don't have the basic unclaimed register write
failure by grabbing runtime pm references. And reject completely
invalid requests with -EIO. This is still racy of course, but for a
test library we don't really care - if userspace shuts down the pipe
right afterwards the entire setup will be lost anyway.

v2: Put instead of get, spotted by Damien. Also explain the runtime pm
dance.

v3: There's really no need for rpm get/put since power_is_enabled only
checks software state (Damien).

References: https://bugs.freedesktop.org/show_bug.cgi?id=86092
Cc: Damien Lespiau <damien.lespiau@intel.com> (v2)
Tested-by: Nlu hua <huax.lu@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

The GPU reset also resets the display on gen3/4. The g33 docs say we
should disable all planes before flipping the reset switch. Just
disable all the crtcs instead. That seems a nicer thing to do anyway.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On gen4 and earlier the GPU reset also resets the display, so we should
protect against concurrent modeset operations. Grab all the modeset locks
around the entire GPU reset dance, remebering first ti dislogde any
pending page flip to make sure we don't deadlock. Any pageflip coming
in between these two steps should fail anyway due to reset_in_progress,
so this should be safe.

This fixes a lot of failed asserts in the modeset code when there's a
modeset racing with the reset. Naturally the asserts aren't happy when
the expected state has disappeared.

v2: Drop UMS checks, complete pending flips after the reset (Daniel)

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

g33 seems to sit somewhere between the 915/945/965 style and the
g4x style. The bits look like g4x, but we still need to do a full
reset including display.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

915/945 have the same reset registers as 965, so share the code.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On pre-ctg GPU reset also resets the display hardware. Force a mode
restore after the GPU reset, and also re-init clock gating.

v2: Use intel_modeset_init_hw() instead of intel_init_clock_gating()
    in case more relevant stuff gets added there at some point
    Restore interrupts after the reset as well
Tested-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On pre-ctg the reset bit directly controls the reset signal. We must
assert it for >=20usec and then deassert it. Bit 1 is a RO status bit
which should also go down when the reset is no longer asserted.
Tested-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's quite a few bug reports with error states where the error
reasons makes just about no sense at all. Like dying on tlbs for a
display plane that's not even there. Also users don't really report a
lot of bad side effects generally, just the error states.

Furthermore we don't even enable these interrupts any more on gen5+
(though the handling code is still there). So this mostly concerns old
platforms.

Given all that lets make our lives a bit easier and stop capturing
error states, in the hopes that we can just ignore them. In case
that's not true and the gpu indeed dies the hangcheck should
eventually kick in. And I've left some debug log in to make this case
noticeble. Referenced bug is just an example.

v2: Fix missing \n Jani spotted.

References: https://bugs.freedesktop.org/show_bug.cgi?id=82095
References: https://bugs.freedesktop.org/show_bug.cgi?id=85944Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The problem here is that SNA pins batchbuffers to etch out a bit more
performance. Iirc it started out as a w/a for i830M (which we've
implemented in the kernel since a long time already). The problem is
that the pin ioctl wasn't added in

commit d23db88c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri May 23 08:48:08 2014 +0200

    drm/i915: Prevent negative relocation deltas from wrapping

Fix this by simply disallowing pinning from userspace so that the
kernel is in full control of batch placement again. Especially since
distros are moving towards running X as non-root, so most users won't
even be able to see any benefits.

UMS support is dead now, but we need this minimal patch for
backporting. Follow-up patch will remove the pin ioctl code
completely.

Note to backporters: You must have both

commit b45305fc
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Dec 17 16:21:27 2012 +0100

    drm/i915: Implement workaround for broken CS tlb on i830/845

which laned in 3.8 and

commit c4d69da1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Sep 8 14:25:41 2014 +0100

    drm/i915: Evict CS TLBs between batches

which is also marked cc: stable. Otherwise this could introduce a
regression by disabling the userspace w/a without the kernel w/a being
fully functional on i830/45.

References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116
Cc: stable@vger.kernel.org # requires c4d69da1 and v3.8
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

In all likelihood we will do a few hundred errnoneous register
operations if we do a single invalid register access whilst the device
is suspended. As each instance causes a WARN, this floods the system
logs and can make the system unresponsive.

The warning was first introduced in
commit b2ec142c
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Feb 21 13:52:25 2014 -0300

    drm/i915: call assert_device_not_suspended at gen6_force_wake_work

and despite the claims the WARN is still encountered in the wild today.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

CHV infoframes were not being enabled.
Signed-off-by: NClint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When doing a nop modeset we currently leave crtc->new_config point at
the already freed temporary pipe_config. That will anger the sanity
checks in intel_modeset_update_state() when the nop modeset gets
followed by a GPU reset on gen3/4 where the display block gets fully
reinitialized during the reset.

So leave crtc->new_config alone until we know a modeset is actually
required.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

LRC object does not need to be mapped into the GGTT when dumping. A side-effect
of this patch is that a compiler warning goes away (not checking return value
of i915_gem_obj_ggtt_pin).

v2: Broke out individual context dumping into a new function as the indentation
was getting a bit crazy.  Added notification of contexts with no gem object for
debugging purposes.  Removed unnecessary pin_pages and unpin_pages, replaced
with explicit get_pages for the context object as there may be no backing store
allocated at this time (Comment for get_pages says "Ensure that the associated
pages are gathered from the backing storage and pinned into our object").
Improved error checking - get_pages and get_page are checked for failure.
Signed-off-by: NThomas Daniel <thomas.daniel@intel.com>
[danvet: Align paramter continuation lines properly. Also add some
braces to the nested loops again for readability.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we just make sure vdd is off before suspending, but we don't
cancel the vdd off work. The work wil not touch vdd if
want_panel_vdd==false so in theory this is fine.

In the past that was perfectly fine since the vdd off work didn't do
anything when want_panel_vdd==false, so even if the work would have been
run during system resume before i915 has resumed, nothing would happen.

However since pps_lock() will now grab the power domain references before
it can check want_panel_vdd, we may end up toggling the power wells on/off
already before the driver has resumed. That is not really acceptable, so
cancel the vdd off work when suspending the encoder.

The problem appeared when pps_lock() was introduced in:
 commit 773538e8
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Thu Sep 4 14:54:56 2014 +0300

    drm/i915: Reset power sequencer pipe tracking when disp2d is off
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

During a GPU reset we need to get pending page flip cleared out
since the ring contents are gone and flip will never complete
on its own. This used to work until the mmio vs. CS flip race
detection came about. That piece of code is looking for a
specific surface address in the SURFLIVE register, but as
a flip to that address may never happen the check may never
pass. So we should just skip the SURFLIVE and flip counter
checks when the GPU gets reset.

intel_display_handle_reset() tries to effectively complete
the flip anyway by calling .update_primary_plane(). But that
may not satisfy the conditions of the mmio vs. CS race
detection since there's no guarantee that a modeset didn't
sneak in between the GPU reset and intel_display_handle_reset().
Such a modeset will not wait for pending flips due to the ongoing GPU
reset, and then the primary plane updates performed by
intel_display_handle_reset() will already use the new surface
address, and thus the surface address the flip is waiting for
might never appear in SURFLIVE. The result is that the flip
will never complete and attempts to perform further page flips
will fail with -EBUSY.

During the GPU reset intel_crtc_has_pending_flip() will return
false regardless, so the deadlock with a modeset vs. the error
work acquiring crtc->mutex was avoided. And the reset_counter
check in intel_crtc_has_pending_flip() actually made this bug
even less severe since it allowed normal modesets to go through
even though there's a pending flip.

This is a regression introduced by me here:
 commit 75f7f3ec
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Tue Apr 15 21:41:34 2014 +0300

    drm/i915: Fix mmio vs. CS flip race on ILK+

Testcase: igt/kms_flip/flip-vs-panning-vs-hang
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It happens on occasion that developers of generic user-space applications
abuse the dumb buffer API to get hold of drm buffers that they can both
mmap() and use for GPU acceleration, using the assumptions that dumb buffers
and buffers available for GPU are
a) The same type and can be aribtrarily type-casted.
b) fully coherent.

This patch makes the most widely used drivers warn nicely when that happens,
the next step will be to fail.

v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Need to check the port too.
Reported-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The final arrangement of updating timer->expires and calling mod_timer()
used in

commit 672e7b7c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Nov 19 09:47:19 2014 +0000

    drm/i915: Don't continually defer the hangcheck

turns out to be very unsafe. Try again.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

encoder->type can change underneath us and doesn't need to reflect
actual hw state (since we don't construct it from hw state like
e.g. encoder->crtc crtc->config).

And this can indeed happen:
1) Boot with plugged-in hdmi screen. Since we only set ->type in the
   probe functions this means we won't detect any infoframes since
   type is still unkown.
2) First probe sets type to HDMI.
3) If the first modeset now does _not_ happen on the HDMI pipe with
   infoframes encoder->get_config suddenly sees infoframes and the
   state checker gets angry.

Fix this by only relying on actual hw state when figuring out whether
the ddi port is in hdmi mode and sends infoframes.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reported-by: NPaulo Zanoni <przanoni@gmail.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This function can be called now with i915 interrupts enabled, so the
corresponding WARN is incorrect, remove it. I think this was spotted by
Paulo during his review, but since I already removed the same WARN
from intel_suspend_gt_powersave() I missed then his point.
Spotted-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Spotted while reading and trying to understand how our error capture
code deals with full ppgtt.

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

I saw punit timeouts in vlv_set_rps_idle() while running various
subtests of pm_rpm. Increasing the timeout to 100ms got rid of the
issue.

Testcase: igt/pm_rpm
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: NGuo Jinxian <jinxianx.guo@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently after doing DPMS-OFF on all outputs CDCLK won't be set to its
minimum value as it should. A subsequent modeset to turn off all outputs
will thus run with all power domains disabled, and notice that it needs
to change CDCLK to its minimum value. Since the power domains are
disabled this will emit a register-access-while-suspended WARN and fail
to set the minimum freq.

The proper solution for this is to set the minimum frequency during
DPMS-OFF. That needs a bigger rework that would take into account the
user DPMS setting too during the calculation of the new modesetting
configuration. Until that's done this stop-gap solution gets the PIPE-A
power domain during setting the CDCLK; this domain covers the HW blocks
needed for this.

Idea to use PIPE-A domain from Ville.

Testcase: igt/pm_rpm
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Makes it easier to debug infoframe mismatches.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

For MMIO registers which are shadowed, force wake is not needed to
write to these registers.

v2: Rebase on top of nightly (Damien)

v3: Rebase on top of "Gen9 multiple-engine forcewake" changes

v4: (Mika, Bob, done by Damien)
- Reorder the shadowed registers by popularity
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NZhe Wang <zhe1.wang@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Enable multi-engine forcewake for Gen9.

v2: (Damien)
- Rebase on top of nightly
- Move the register range definitions to intel_uncore.c
- Whitespace fixes

v3: (Addressing Mika's comment, done by Damien)
- Use REG_RANGE() (introduced after the patch was written)
- Add a SKL_NEEDS_FORCE_WAKE() macro that gets rid of a useless
  comparison to FORCEWAKE (reg 0xa18c is not used on SKL)

v4: (Damien)
- Use newly introduced ASSIGN_READ/WRITE_MMIO_VFUNCS() macros
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NZhe Wang <zhe1.wang@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Trying to read the status of the power wells right after taking forcewake
for the other register reads makes little sense. Most of the time the
power wells will still be up due to the recent forcewake. Instead do the
power well status read first, and only then read the register needing
forcewake. This way the reported power well status can actually reflect
what's going on in the system.

Cc: Deepak S <deepak.s@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak S <deepak.s@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Let's just throw in the towel on this one and take the cheap way out.

Based on a patch from Chris Wilson, but checking for a different bit.
Chris' patch checked for even bank layout, this one here for a magic
bit. Given the evidence we've gathered (not much) both work I think,
but checking for the magic bit might be more accurate.

Anyway, works on my gm45 here.

For paranoi restrict to gen4 (and mobile), since we've only ever seen
this on gm45 and i965gm.

Also add some debugfs output so that we can skip the tiled swapping
tests properly in these cases.

v2: Clean up the quirk'ed pin count in free_object to avoid upsetting
the WARN_ON. Spotted by Chris.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28813
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45092Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In __gen6_update_ring_freq, use the full range of
possible gpu frequencies from max_freq to min_freq.
The actual gpu frequency could be outside the range
from max_freq_softlimit to min_freq_softlimit due
to power/thermal constraints.
Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In gen8_enable_rps, change the initial rps setting
to the min_freq_softlimit (same as gen6_enable_rps).
Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Set the min_freq_softlimit to max(RPe, 450MHz).

Setting a floor can ensure a minimum experience
level.  The 450MHz value came from a power and
performance study of various types of workloads
(3D, Media, GPGPU, idle, etc).

v2: rebased
Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Added gen6_init_rps_frequencies() to initialize
the rps frequency values.  This function replaces
parse_rp_state_cap().  In addition to reading RPn,
RP0, and RP1 from RP_STATE_CAP register, the new
function reads efficient frequency (aka RPe) from
pcode for Haswell and Broadwell and sets the turbo
softlimits.  The turbo minimum frequency softlimit
is set to RPe for Haswell and Broadwell and to RPn
otherwise.

For RPe, the efficiency is based on the frequency/power
ratio (MHz/W); this is considering GT power and not
package power.  The efficent frequency is the highest
frequency for which the frequency/power ratio is within
some threshold of the highest frequency/power ratio.
A fixed decrease in frequency results in smaller
decrease in power at frequencies less than RPe than
at frequencies above RPe.

v2: Following suggestions from Chris Wilson and
Daniel Vetter to extend and rename parse_rp_state_cap
and to open-code a poorly named function.
Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Remove unused variables.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Found one more!

With this we can clear up the ggtt init code a bit, yay!
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

With this all the ums nonsense around gem setup/teardown has
disappeared, yay!
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Again just complicates gem init functions and makes a general mess out
of everything.

Good riddance!

v2: In my enthusiasm to start removing dri1/ums crud I went overboard a
bit and killed parts of hangcheck. Resurrect it.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

We've killed ums support by now, it's time to reap the benefits. This
one here is getting in the way of doing some ring init cleanup.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>