It's racy, creating mmap offsets is a slowpath, so better to remove it
to avoid drivers doing broken things.

The only user is i915, and it's ok there because everything (well
almost) is protected by dev->struct_mutex in i915-gem.

While at it add a note in the create_mmap_offset kerneldoc that
drivers must release it again. And then I also noticed that
drm_gem_object_release entirely lacks kerneldoc.

Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-14-git-send-email-daniel.vetter@ffwll.ch

With the previous two changes it doesn't protect anything any more.

v2: Use _unlocked unreference variant.

v3: Appease gcc noise.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-13-git-send-email-daniel.vetter@ffwll.ch

vgem doesn't have a shrinker or anything like that and drops backing
storage only at object_free time. There's no use in trying to be
clever and allocating backing storage delayed, it only causes trouble
by requiring locking.

Instead grab pages when we allocate the object right away.

v2: Fix compiling.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-12-git-send-email-daniel.vetter@ffwll.ch

The offset manager already checks for existing offsets internally,
while holding suitable locks. We can drop this check.

v2: Fix title (Emil).
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-11-git-send-email-daniel.vetter@ffwll.ch

Doesn't protect anything at all, and probably just here because a long
time ago dev->struct_mutex was required to allocate gem objects.

With this patch exynos is completely struct_mutex free!

Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-10-git-send-email-daniel.vetter@ffwll.ch

The only things this protects is reading ->flags and ->size, both of
which are invariant over the lifetime of an exynos gem bo. So no
locking needed at all (besides that, nothing protects the writers
anyway).

Aside: exynos_gem_obj->size is redundant with
exynos_gem_obj->base.size and probably should be removed.

v2: Use _unlocked unreference (Daniel Stone).

Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-9-git-send-email-daniel.vetter@ffwll.ch

The sg table isn't refcounted, there's no corresponding locking for
unmapping and drm_map_sg is ok with being called concurrently.

So drop the locking since it doesn't protect anything.

Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-8-git-send-email-daniel.vetter@ffwll.ch

Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.

Aside: DRM_ERROR for userspace controlled input isn't great, but
that's for another patch.

v2: Use _unlocked unreference (Daniel Stone).

Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-7-git-send-email-daniel.vetter@ffwll.ch

Doesn't protect anything at all.

With this patch nouveau is completely dev->struct_mutex free!

Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-6-git-send-email-daniel.vetter@ffwll.ch

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 15 09:36:25 2015 +0200

    drm/gem: Check locking in drm_gem_object_unreference

Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-4-git-send-email-daniel.vetter@ffwll.ch
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-5-git-send-email-daniel.vetter@ffwll.ch

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 15 09:36:25 2015 +0200

    drm/gem: Check locking in drm_gem_object_unreference

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-3-git-send-email-daniel.vetter@ffwll.ch

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 15 09:36:25 2015 +0200

    drm/gem: Check locking in drm_gem_object_unreference

Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-2-git-send-email-daniel.vetter@ffwll.ch

Both cases produce the same result. Kill the junk code.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

Fix possible out of bounds read, by adding missing comma.
The code may read pass the end of the dsi_errors array
when the most significant bit (bit #31) in the intr_stat register
is set.
This bug has been detected using CppCheck (static analysis tool).

Cc: stable@vger.kernel.org
Signed-off-by: NItai Handler <itai_handler@hotmail.com>
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

We are allocating backing using psbfb_alloc() and so
backing->stolen is always true. So we were freeing backing two times.
Moreover if we follow the execution path then we should be freeing
backing after we have released the helper. So remove the one which frees
backing before the helper is released.
While at it the error labels are also renamed to give a meaningful
name.

[Patrik: Fixed conflict with removal of struct_mutex]
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>

It may caused a dead lock if we flush the hpd work in bridge disable time.

The normal flow would like:
  IN --> DRM IOCTL
        1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
        2. Acquire hpd work lock (Flush hpd work)
        3. HPD work already in idle, no need to run the work function.
  OUT <-- analogix_dp_bridge
  OUT <-- DRM IOCTL

The dead lock flow would like:
  IN --> DRM IOCTL
        1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
        2. Acquire hpd work lock (Flush hpd work)
  IN --> analogix_dp_hotplug
  IN --> drm_helper_hpd_irq_event
        3. Acquire mode_config lock (This lock already have been acquired in previous step 1)
** Dead Lock Now **

It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.

The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

Turn off the panel power in suspend time would help to reduce
power waste.
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
	drm/exynos: do not start enabling DP at bind() phase

But for now driver need to read edid message in .get_modes()
function, so controller must be inited in bind time, so we
need to add controller init back.
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
	drm/exynos: do not start enabling DP at bind() phase

But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.

This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Acked-by: NRob Herring <robh@kernel.org>
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Acked-by: NMark Yao <mark.yao@rock-chips.com>
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.

Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.
Acked-by: NJingoo Han <jingoohan1@gmail.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

In the original split we kept the register constants intact to keep the

diff small. Still the constants are Analogix-specific, so rename them now.
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

The core functionality now resides in the generic bridge part so the
exynos-specific implementation details can get a more suitable nameing.
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>

Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.

Beside the new analogix_dp driver would export six hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_suspned()" and "analogix_dp_resume()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"

The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.

They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.
Acked-by: NInki Dae <inki.dae@samsung.com>
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>

For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with

commit ef4c6270
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Oct 15 09:36:25 2015 +0200

    drm/gem: Check locking in drm_gem_object_unreference

Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

1) don't let other threads trying to bang on aux channel interrupt the
defer timeout/logic
2) don't let other threads interrupt the i2c over aux logic

Technically, according to people who actually have the DP spec, this
should not be required.  In practice, it makes some troublesome Dell
monitor (and perhaps others) work, so probably a case of "It's compliant
if it works with windows" on the hw vendor's part..

v2: rebased to come before DPCD/AUX logging patch for easier backport
to stable branches.
Reported-by: NDave Wysochanski <dwysocha@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274157
Cc: stable@vger.kernel.org
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458342904-23326-3-git-send-email-robdclark@gmail.com

This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset
drivers.

v2: Make the dummy function actually return a sane value, spotted by
Ville.

v3: Because the patch is still in limbo there's no more drivers to
convert, noticed by Emil.

v4: Rebase once more, because hooray. I'll just go ahead an apply this
one later on to drm-misc.

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This goes all the way back to the original KMS commit aeons ago

commit f453ba04
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Nov 7 14:05:41 2008 -0800

    DRM: add mode setting support

But it seems to be completely unused. Only i915 and nouveau even
register these properties, and the corresponding DDX don't even look
at them. Also the sysfs files are read-only, so not useful to
configure anything.

I suspect that this was added with the goal to have read-only access
to all properties in sysfs, but we never followed through on that.
Also, that should be done in a more generic fashion.

Since it would be real work to fix up the locking (with atomic we're
now chasing pointers when reading properties) and it seems unused lets
just nuke this all. It's easier. Of course we'll keep the properties
themselves, those are still exposed through the KMS ioctls.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459331120-27864-5-git-send-email-daniel.vetter@ffwll.ch

It tries to do fancy things with excluding agp support if ttm is
built-in, but agp isn't. Instead just express this depency like drm
does and use CONFIG_AGP everywhere.

Also use the neat Makefile magic to make the entire ttm_agp_backend
file optional.

v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville

v3: Review from Emil.

v4: Actually get it right as spotted by 0-day.

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1459337046-25882-1-git-send-email-daniel.vetter@ffwll.ch

We don't need to keep empty callbacks for the (pre/post) enable/disable
drm_bridge ops anymore. Remove the nop callback used here for
pre_enable and post_disable ops.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1459329804-10488-1-git-send-email-architt@codeaurora.org

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

This reverts commit e91abf80.

Since

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

    ktime: Kill non-scalar ktime_t implementation for 2038

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

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

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

Since we need MST devices ready before we try to resume displays,
calling this after intel_display_resume() can result in some issues with
various laptop docks where the monitor won't turn back on after
suspending the system.

This order was originally changed in

	commit e7d6f7d7 ("drm/i915: resume MST after reading back hw state")

In order to fix some unclaimed register errors, however the actual cause
of those has since been fixed.

CC: stable@vger.kernel.org
Signed-off-by: NLyude <cpaul@redhat.com>
[danvet: Resolve conflicts with locking changes.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The ->lastclose callback invokes intel_fbdev_restore_mode() and has
been witnessed to run before intel_fbdev_initial_config_async()
has finished.

We might likewise receive hotplug events before we've had a chance to
fully set up the fbdev.

Fix by waiting for the asynchronous thread to finish.

v2:
An async_synchronize_full() was also added to intel_fbdev_set_suspend()
in v1 which turned out to be entirely gratuitous. It caused a deadlock
on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela
for CI support) and was unnecessary since a device is never suspended
until its ->probe callback (and all asynchronous tasks it scheduled)
have finished. See dpm_prepare(), which calls wait_for_device_probe(),
which calls async_synchronize_full().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580Reported-by: NGustav Fägerlind <gustav.fagerlind@gmail.com>
Reported-by: N"Li, Weinan Z" <weinan.z.li@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160309115147.67B2B6E0D3@gabe.freedesktop.org