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

PTR_ERR should access the value just tested by IS_ERR, otherwise
the wrong error code will be returned.

Fixes: d1667b86 ("drm/hisilicon/hibmc: Add support for frame buffer")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170112151921.16538-1-weiyj.lk@gmail.com

Fixes the following sparse warning:

drivers/gpu/drm/drm_atomic_helper.c:1360:6: warning:
 symbol 'release_crtc_commit' was not declared. Should it be static?
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170112142157.14684-1-weiyj.lk@gmail.com

This avoids using the deprecated drm_put_dev() and unload() hook
interfaces in the qxl driver.
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170119134806.8926-2-krisman@collabora.co.uk

This avoids using the deprecated drm_get_pci_dev() and load() hook
interfaces in the qxl driver.

The only tricky part is to ensure TTM debugfs initialization happens
after the debugfs root node is created, which is done by moving that
code into the debufs_init() hook.

Tested on qemu with igt and running a WM on top of X.

Changes since v1:
 - Drop verification for primary minor in qxl_debugsfs_init.
Changes since V2:
 - Put new header together with other debugfs headers.
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170119134806.8926-1-krisman@collabora.co.uk