drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.

Cc: tomi.valkeinen@ti.com
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-12-noralf@tronnes.org

drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.

Cc: liviu.dudau@arm.com
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-9-noralf@tronnes.org

drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.

Cc: l.stach@pengutronix.de
Cc: linux+etnaviv@armlinux.org.uk
Cc: christian.gmeiner@gmail.com
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-8-noralf@tronnes.org

Make it possible to compile test the driver on other platforms.

Cc: l.stach@pengutronix.de
Cc: linux+etnaviv@armlinux.org.uk
Cc: christian.gmeiner@gmail.com
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-7-noralf@tronnes.org

drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so no need to call drm_debugfs_remove_files().
Also remove empty drm_driver.debugfs_cleanup callback.

Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-5-noralf@tronnes.org

From the description of the "DMA-BUF/GEM Object references
and lifetime overview" it is not clear when exactly
dma_buf gets destroyed and memory freed: only driver
.release function mentioned which makes confusion on the
real buffer's lifetime.

Add more description so all the paths are covered.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NOleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
[danvet: Minor spelling fixes, and some clarification of the 2nd
paragraph.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1485500665-27690-1-git-send-email-andr2000@gmail.com

The current caching state may not be tt_cached, even though the
placement contains TTM_PL_FLAG_CACHED, because placement can contain
multiple caching flags. Trying to swap out such a BO would trip up the

	BUG_ON(ttm->caching_state != tt_cached);

in ttm_tt_swapout.

Cc: stable@vger.kernel.org
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>.
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>

drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so no need to call drm_debugfs_remove_files().
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-4-noralf@tronnes.org

Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to
cover for failure in the drm_driver.debugfs_init callback.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-3-noralf@tronnes.org

Instead of having the drivers call drm_debugfs_remove_files() in
their drm_driver->debugfs_cleanup hook, do it automatically by
traversing minor->debugfs_list.
Also use debugfs_remove_recursive() so drivers who add their own
debugfs files don't have to keep track of them for removal.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-2-noralf@tronnes.org

Vivante GC hardware uses simple 4x4 tiled and nested 64x64 supertiled
formats as well as so-called split-tiled variants for dual-pipe
hardware, where even and odd tiles start at different base addresses.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-By: NWladimir J. van der Laan <laanwj@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126153217.26916-1-p.zabel@pengutronix.de

CEA-861-F tells us:
"When transmitting any RGB colorimetry, the Source should set the
 YQ-field to match the RGB Quantization Range being transmitted
 (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
 set YQ=1) and the Sink shall ignore the YQ-field."

So let's go ahead and do that. Perhaps there are sinks that don't
ignore the YQ as they should for RGB?

I wasn't able to find similar text in CEA-861-E, so it would seem
to be a fairly "recent" addition.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

HDMI 2.0 recommends that we set the Q bits in the AVI infoframe
even when the sink does not support quantization range selection (QS=0).
According to CEA-861 we can do that as long as the Q we send matches
the default quantization range for the mode.

Previously I think I had misread the spec as saying that you can't
send a non-zero Q at all when QS=0. But that's not what the spec
actually says.

v2: Fix typo in commit message (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

Pull the logic to populate the quantization range information
in the AVI infoframe into a small helper. We'll be adding a bit
more logic to it, and having it in a central place seems like a
good idea since it's based on the CEA-861 spec.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

Make the code selecting the RGB quantization range a little less magicy
by wrapping it up in a small helper.

v2: s/adjusted_mode/mode in vc4 to make it actually compile
v3: Add a comment proposed by Eric
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111141835.25369-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

drm_edid.h depends on hdmi.h on account of enum hdmi_picture_aspect,
so let's just include hdmi.h and drop some useless struct declarations.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler
has been able to get smarter and spots that drm_mode_copy() is trying to
preserve garbage from the stack.

Fixes: 196cd5d3 ("drm: s/drm_crtc_get_hv_timings/drm_mode_get_hv_timings/")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126114409.9115-1-chris@chris-wilson.co.uk

There's no late_unregister. While at it switch to the new canonical
reference style.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-14-daniel.vetter@ffwll.ch

The function operates on modes, not CRTCs. Also move it into
drm_modes.[hc]. Spotted while reviewing CRTC docs.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-15-daniel.vetter@ffwll.ch

No point in documenting these, they only confuse.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-13-daniel.vetter@ffwll.ch

i915, nouveau (ever since merged to upstream) and radeon all lack ums
support in upstream. No point keeping the ums vgaarb support around.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-12-daniel.vetter@ffwll.ch

With that the drm_pci_device_is_agp function becomes trivial, so
inline that too. And while at it, move the drm_pci_agp_destroy
declaration into drm-internal.h, since it's not used by drivers.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-11-daniel.vetter@ffwll.ch

It's only for a device quirk, and we might as well do that in the load
callback.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-10-daniel.vetter@ffwll.ch

Use the same trick we used for i915 when we still had ums support:
Just initialize the agp support unconditionally in the driver load
function.

Unfortunately that means we need to export drm_agp_init again, but I
think that's a lesser evil.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-9-daniel.vetter@ffwll.ch

There was a bit of mix-up between initialization and registering.

v2: Review from Gustavo.
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-7-daniel.vetter@ffwll.ch
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-8-daniel.vetter@ffwll.ch

After going through all the trouble of splitting out parts from
drm_crtc.[hc] and then properly documenting each I've entirely
forgotten to show the same TLC for CRTCs themselves!

Let's make amends asap.

v2: Review from Eric.
Reviewed-by: NEric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Returning 0 for an on-chip gpu doesn't change anything at all.

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-8-daniel.vetter@ffwll.ch

I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).

Also some minor drive-by polish where it makes sense, I read a lot
of docs ...

v2: Review from Eric.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-4-daniel.vetter@ffwll.ch

I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).

Also some minor drive-by polish where it makes sense, I read a lot
of docs ...

v2: Review from Gustavo.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-6-daniel.vetter@ffwll.ch

I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).

Also some minor drive-by polish where it makes sense, I read a lot
of docs ...

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-5-daniel.vetter@ffwll.ch

I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).

Also some minor drive-by polish where it makes sense, I read a lot
of docs ...

v2: Comments from Gustavo.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Rewiewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-2-daniel.vetter@ffwll.ch

struct drm_dp_mst_topology_mgr currently stores a pointer to struct dev.
Changing this to instead hold a pointer to drm_device is more useful as it
gives access to DRM structures. This also makes it consistent with other
DRM structures like drm_crtc, drm_connector etc.
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1485301777-3465-2-git-send-email-dhinakaran.pandiyan@intel.com

For the convenience of encapsulation the reservation object's ww_mutex
was wrapped in pair of lock/unlock helpers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170123095357.29514-1-chris@chris-wilson.co.uk

Add missing includes to pull in definitions for drm_crtc,
drm_plane and drm_encoder.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170122181117.8210-4-noralf@tronnes.org

Add a CMA version of drm_fb_helper_set_suspend_unlocked().

Cc: laurent.pinchart@ideasonboard.com
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170122181117.8210-2-noralf@tronnes.org

The prototypes were moved to a new header, but the function definitions
were not updated to pull in the declarations.

drivers/gpu/drm/drm_cache.c:79:1: warning: no previous prototype for ‘drm_clflush_pages’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_cache.c:120:1: warning: no previous prototype for ‘drm_clflush_sg’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_cache.c:152:1: warning: no previous prototype for ‘drm_clflush_virt_range’ [-Wmissing-prototypes]

Fixes: f9a87bd7 ("drm: Move drm_clflush prototypes to drm_cache header file")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170121181944.24672-1-chris@chris-wilson.co.uk

The of_node member in struct drm_bridge is hidden when CONFIG_OF
is disabled, causing a build error:

drivers/gpu/drm/bridge/dw-hdmi.c: In function '__dw_hdmi_probe':
drivers/gpu/drm/bridge/dw-hdmi.c:2063:14: error: 'struct drm_bridge' has no member named 'of_node'

We could fix this either using a Kconfig dependency on CONFIG_OF
or making the one line conditional. The latter gives us better
compile test coverage, so this is what I'm doing here.

Fixes: 69497eb9 ("drm: bridge: dw-hdmi: Implement DRM bridge registration")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170123122312.3290934-1-arnd@arndb.de

While the Kconfig entries of FIMD and DECON7 both select
FB_MODE_HELPERS, the code doesn't use any of the functionality.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1484928172-16784-1-git-send-email-tjakobi@math.uni-bielefeld.de

After warning that the connector list is not empty on device
unregistration (i.e. module unload) also print out which connectors are
still hanging around to aide finding the leak.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170119090513.4154-1-chris@chris-wilson.co.uk

The allocation for the bitmap may become very large, larger than
MAX_ORDER, for large requests. We fail gracefully by falling back to
trail-division, so disable the warning from kmalloc:

  521.961092] WARNING: CPU: 0 PID: 30637 at mm/page_alloc.c:3548 __alloc_pages_slowpath+0x237/0x9a0
[  521.961105] Modules linked in: i915(+) drm_kms_helper intel_gtt prime_numbers [last unloaded: drm_kms_helper]
[  521.961126] CPU: 0 PID: 30637 Comm: drv_selftest Tainted: G     U  W       4.10.0-rc3+ #321
[  521.961137] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[  521.961148] Call Trace:
[  521.961161]  dump_stack+0x4d/0x6f
[  521.961172]  __warn+0xc1/0xe0
[  521.961181]  warn_slowpath_null+0x18/0x20
[  521.961189]  __alloc_pages_slowpath+0x237/0x9a0
[  521.961200]  ? sg_init_table+0x1a/0x40
[  521.961208]  ? get_page_from_freelist+0x3fa/0x910
[  521.961275]  ? i915_gem_object_get_sg+0x272/0x2b0 [i915]
[  521.961285]  __alloc_pages_nodemask+0x1ea/0x220
[  521.961295]  kmalloc_order+0x1c/0x50
[  521.961304]  __kmalloc+0x115/0x170
[  521.961314]  expand_to_next_prime+0x43/0x180 [prime_numbers]
[  521.961324]  next_prime_number+0x47/0xc0 [prime_numbers]
[  521.961377]  igt_vma_rotate+0x386/0x590 [i915]
[  521.961429]  i915_subtests+0x37/0xc0 [i915]
[  521.961481]  i915_vma_mock_selftests+0x3d/0x70 [i915]
[  521.961532]  run_selftests+0x16e/0x1f0 [i915]
[  521.961541]  ? 0xffffffffa02a4000
[  521.961592]  i915_mock_selftests+0x29/0x40 [i915]
[  521.961638]  i915_init+0xa/0x5e [i915]
[  521.961646]  ? 0xffffffffa02a4000
[  521.961655]  do_one_initcall+0x3e/0x160
[  521.961664]  ? __vunmap+0x7c/0xc0
[  521.961672]  ? vfree+0x29/0x70
[  521.961680]  ? kmem_cache_alloc+0xcf/0x120
[  521.961690]  do_init_module+0x55/0x1c4
[  521.961699]  load_module+0x1f3f/0x25b0
[  521.961707]  ? __symbol_put+0x40/0x40
[  521.961716]  ? kernel_read_file+0x100/0x190
[  521.961725]  SYSC_finit_module+0xbc/0xf0
[  521.961734]  SyS_finit_module+0x9/0x10
[  521.961744]  entry_SYSCALL_64_fastpath+0x17/0x98
[  521.961752] RIP: 0033:0x7f111aca4119
[  521.961760] RSP: 002b:00007ffd8be6cbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[  521.961773] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f111aca4119
[  521.961781] RDX: 0000000000000000 RSI: 000055dfc18bc8e0 RDI: 0000000000000006
[  521.961789] RBP: 00007ffd8be6bbe0 R08: 0000000000000000 R09: 0000000000000000
[  521.961796] R10: 0000000000000006 R11: 0000000000000246 R12: 0000000000000005
[  521.961805] R13: 000055dfc18bd3a0 R14: 00007ffd8be6bbc0 R15: 0000000000000005
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170113235119.22528-1-chris@chris-wilson.co.uk