--- /dev/null
+From 83502a5d34386f7c6973bc70e1c423f55f5a2e3a Mon Sep 17 00:00:00 2001
+From: "Y.C. Chen" <yc_chen@aspeedtech.com>
+Date: Wed, 10 Sep 2014 12:07:54 +0800
+Subject: drm/ast: AST2000 cannot be detected correctly
+
+From: "Y.C. Chen" <yc_chen@aspeedtech.com>
+
+commit 83502a5d34386f7c6973bc70e1c423f55f5a2e3a upstream.
+
+Type error and cause AST2000 cannot be detected correctly
+
+Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
+Reviewed-by: Egbert Eich <eich@suse.de>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/ast/ast_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/ast/ast_main.c
++++ b/drivers/gpu/drm/ast/ast_main.c
+@@ -105,7 +105,7 @@ static int ast_detect_chip(struct drm_de
+ }
+ ast->vga2_clone = false;
+ } else {
+- ast->chip = 2000;
++ ast->chip = AST2000;
+ DRM_INFO("AST 2000 detected\n");
+ }
+ }
--- /dev/null
+From 8f372e250ae5f4a5faf87ca1a629d0ae59db65b6 Mon Sep 17 00:00:00 2001
+From: "Y.C. Chen" <yc_chen@aspeedtech.com>
+Date: Wed, 10 Sep 2014 12:07:53 +0800
+Subject: drm/ast: open key before detect chips
+
+From: "Y.C. Chen" <yc_chen@aspeedtech.com>
+
+commit 8f372e250ae5f4a5faf87ca1a629d0ae59db65b6 upstream.
+
+Some config settings like 3rd TX chips will not get correctly
+if the extended reg is protected
+
+Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
+Reviewed-by: Egbert Eich <eich@suse.de>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/ast/ast_main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/ast/ast_main.c
++++ b/drivers/gpu/drm/ast/ast_main.c
+@@ -67,6 +67,7 @@ static int ast_detect_chip(struct drm_de
+ {
+ struct ast_private *ast = dev->dev_private;
+ uint32_t data, jreg;
++ ast_open_key(ast);
+
+ if (dev->pdev->device == PCI_CHIP_AST1180) {
+ ast->chip = AST1100;
--- /dev/null
+From 22cb99af39b5d4aae075a5bc9da615ba245227cd Mon Sep 17 00:00:00 2001
+From: Brad Volkin <bradley.d.volkin@intel.com>
+Date: Mon, 22 Sep 2014 08:25:21 -0700
+Subject: drm/i915: Don't leak command parser tables on suspend/resume
+
+From: Brad Volkin <bradley.d.volkin@intel.com>
+
+commit 22cb99af39b5d4aae075a5bc9da615ba245227cd upstream.
+
+Ring init and cleanup are not balanced because we re-init the rings on
+resume without having cleaned them up on suspend. This leads to the
+driver leaking the parser's hash tables with a kmemleak signature such
+as this:
+
+unreferenced object 0xffff880405960980 (size 32):
+ comm "systemd-udevd", pid 516, jiffies 4294896961 (age 10202.044s)
+ hex dump (first 32 bytes):
+ d0 85 46 c0 ff ff ff ff 00 00 00 00 00 00 00 00 ..F.............
+ 98 60 28 04 04 88 ff ff 00 00 00 00 00 00 00 00 .`(.............
+ backtrace:
+ [<ffffffff81816f9e>] kmemleak_alloc+0x4e/0xb0
+ [<ffffffff811fa678>] kmem_cache_alloc_trace+0x168/0x2f0
+ [<ffffffffc03e20a5>] i915_cmd_parser_init_ring+0x2a5/0x3e0 [i915]
+ [<ffffffffc04088a2>] intel_init_ring_buffer+0x202/0x470 [i915]
+ [<ffffffffc040c998>] intel_init_vebox_ring_buffer+0x1e8/0x2b0 [i915]
+ [<ffffffffc03eff59>] i915_gem_init_hw+0x2f9/0x3a0 [i915]
+ [<ffffffffc03f0057>] i915_gem_init+0x57/0x1d0 [i915]
+ [<ffffffffc045e26a>] i915_driver_load+0xc0a/0x10e0 [i915]
+ [<ffffffffc02e0d5d>] drm_dev_register+0xad/0x100 [drm]
+ [<ffffffffc02e3b9f>] drm_get_pci_dev+0x8f/0x200 [drm]
+ [<ffffffffc03c934b>] i915_pci_probe+0x3b/0x60 [i915]
+ [<ffffffff81436725>] local_pci_probe+0x45/0xa0
+ [<ffffffff81437a69>] pci_device_probe+0xd9/0x130
+ [<ffffffff81524f4d>] driver_probe_device+0x12d/0x3e0
+ [<ffffffff815252d3>] __driver_attach+0x93/0xa0
+ [<ffffffff81522e1b>] bus_for_each_dev+0x6b/0xb0
+
+This patch extends the current convention of checking whether a
+resource is already allocated before allocating it during ring init.
+Longer term it might make sense to only init the rings once.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83794
+Tested-by: Kari Suvanto <kari.tj.suvanto@gmail.com>
+Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_cmd_parser.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
++++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
+@@ -706,11 +706,13 @@ int i915_cmd_parser_init_ring(struct int
+ BUG_ON(!validate_cmds_sorted(ring, cmd_tables, cmd_table_count));
+ BUG_ON(!validate_regs_sorted(ring));
+
+- ret = init_hash_table(ring, cmd_tables, cmd_table_count);
+- if (ret) {
+- DRM_ERROR("CMD: cmd_parser_init failed!\n");
+- fini_hash_table(ring);
+- return ret;
++ if (hash_empty(ring->cmd_hash)) {
++ ret = init_hash_table(ring, cmd_tables, cmd_table_count);
++ if (ret) {
++ DRM_ERROR("CMD: cmd_parser_init failed!\n");
++ fini_hash_table(ring);
++ return ret;
++ }
+ }
+
+ ring->needs_cmd_parser = true;
--- /dev/null
+From 1a125d8a2c22b11741fc47d4ffcf7a5ffa044dd3 Mon Sep 17 00:00:00 2001
+From: Imre Deak <imre.deak@intel.com>
+Date: Mon, 18 Aug 2014 14:42:46 +0300
+Subject: drm/i915: don't try to retrain a DP link on an inactive CRTC
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Imre Deak <imre.deak@intel.com>
+
+commit 1a125d8a2c22b11741fc47d4ffcf7a5ffa044dd3 upstream.
+
+Atm we may retrain the DP link even if the CRTC is inactive through
+HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY
+(at least on BYT), since the DP port is disabled.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948
+Signed-off-by: Imre Deak <imre.deak@intel.com>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_dp.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/i915/intel_dp.c
++++ b/drivers/gpu/drm/i915/intel_dp.c
+@@ -3313,6 +3313,9 @@ intel_dp_check_link_status(struct intel_
+ if (WARN_ON(!intel_encoder->base.crtc))
+ return;
+
++ if (!to_intel_crtc(intel_encoder->base.crtc)->active)
++ return;
++
+ /* Try to read receiver status if the link appears to be up */
+ if (!intel_dp_get_link_status(intel_dp, link_status)) {
+ return;
--- /dev/null
+From 2232f0315c6688f5ff6b2067ea88d97542034873 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Thu, 4 Sep 2014 09:36:18 +0200
+Subject: drm/i915: Fix EIO/wedged handling in gem fault handler
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 2232f0315c6688f5ff6b2067ea88d97542034873 upstream.
+
+In
+
+commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c
+Author: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Thu Nov 15 17:17:22 2012 +0100
+
+ drm/i915: clear up wedged transitions
+
+I've accidentally inverted the EIO/wedged handling in the fault
+handler: We want to return the EIO as a SIGBUS only if it's not
+because of the gpu having died, to prevent userspace from unduly
+dying.
+
+In my defence the comment right above is completely misleading, so fix
+both.
+
+v2: Drop the WARN_ON, it's not actually a bug to e.g. receive an -EIO
+when swap-in fails.
+
+v3: Don't remove too much ... oops.
+
+Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_gem.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_gem.c
++++ b/drivers/gpu/drm/i915/i915_gem.c
+@@ -1576,10 +1576,13 @@ unlock:
+ out:
+ switch (ret) {
+ case -EIO:
+- /* If this -EIO is due to a gpu hang, give the reset code a
+- * chance to clean up the mess. Otherwise return the proper
+- * SIGBUS. */
+- if (i915_terminally_wedged(&dev_priv->gpu_error)) {
++ /*
++ * We eat errors when the gpu is terminally wedged to avoid
++ * userspace unduly crashing (gl has no provisions for mmaps to
++ * fail). But any other -EIO isn't ours (e.g. swap in failure)
++ * and so needs to be reported.
++ */
++ if (!i915_terminally_wedged(&dev_priv->gpu_error)) {
+ ret = VM_FAULT_SIGBUS;
+ break;
+ }
--- /dev/null
+From bbfb44e8b688e778964275ab0862f67463ba4f84 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Tue, 2 Sep 2014 12:57:22 +0300
+Subject: drm/i915: Fix lock dropping in intel_tv_detect()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+
+commit bbfb44e8b688e778964275ab0862f67463ba4f84 upstream.
+
+When intel_tv_detect() fails to do load detection it would forget to
+drop the locks and clean up the acquire context. Fix it up.
+
+This is a regression from:
+ commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44
+ Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
+ Date: Mon Aug 11 13:15:35 2014 +0300
+
+ drm/i915: Fix locking for intel_enable_pipe_a()
+
+v2: Make the code more readable (Chris)
+v3: Drop WARN_ON(type < 0) (Chris)
+
+Cc: Tibor Billes <tbilles@gmx.com>
+Reported-by: Tibor Billes <tbilles@gmx.com>
+Tested-by: Tibor Billes <tbilles@gmx.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_tv.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_tv.c
++++ b/drivers/gpu/drm/i915/intel_tv.c
+@@ -1311,6 +1311,7 @@ intel_tv_detect(struct drm_connector *co
+ {
+ struct drm_display_mode mode;
+ struct intel_tv *intel_tv = intel_attached_tv(connector);
++ enum drm_connector_status status;
+ int type;
+
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] force=%d\n",
+@@ -1328,16 +1329,19 @@ intel_tv_detect(struct drm_connector *co
+ if (intel_get_load_detect_pipe(connector, &mode, &tmp, &ctx)) {
+ type = intel_tv_detect_type(intel_tv, connector);
+ intel_release_load_detect_pipe(connector, &tmp);
++ status = type < 0 ?
++ connector_status_disconnected :
++ connector_status_connected;
+ } else
+- return connector_status_unknown;
++ status = connector_status_unknown;
+
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+ } else
+ return connector->status;
+
+- if (type < 0)
+- return connector_status_disconnected;
++ if (status != connector_status_connected)
++ return status;
+
+ intel_tv->type = type;
+ intel_tv_find_better_format(connector);
--- /dev/null
+From 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Mon, 11 Aug 2014 13:15:35 +0300
+Subject: drm/i915: Fix locking for intel_enable_pipe_a()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+
+commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 upstream.
+
+intel_enable_pipe_a() gets called with all the modeset locks already
+held (by drm_modeset_lock_all()), so trying to grab the same
+locks using another drm_modeset_acquire_ctx is going to fail miserably.
+
+Move most of the drm_modeset_acquire_ctx handling (init/drop/fini)
+out from intel_{get,release}_load_detect_pipe() into the callers
+(intel_{crt,tv}_detect()). Only the actual locking and backoff
+handling is left in intel_get_load_detect_pipe(). And in
+intel_enable_pipe_a() we just share the mode_config.acquire_ctx from
+drm_modeset_lock_all() which is already holding all the relevant locks.
+
+It's perfectly legal to lock the same ww_mutex multiple times using the
+same ww_acquire_ctx. drm_modeset_lock() will convert the returned
+-EALREADY into 0, so the caller doesn't need to do antyhing special.
+
+Fixes a hang on resume on my 830.
+
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_crt.c | 7 ++++++-
+ drivers/gpu/drm/i915/intel_display.c | 21 ++++-----------------
+ drivers/gpu/drm/i915/intel_drv.h | 3 +--
+ drivers/gpu/drm/i915/intel_tv.c | 7 ++++++-
+ 4 files changed, 17 insertions(+), 21 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_crt.c
++++ b/drivers/gpu/drm/i915/intel_crt.c
+@@ -673,16 +673,21 @@ intel_crt_detect(struct drm_connector *c
+ goto out;
+ }
+
++ drm_modeset_acquire_init(&ctx, 0);
++
+ /* for pre-945g platforms use load detect */
+ if (intel_get_load_detect_pipe(connector, NULL, &tmp, &ctx)) {
+ if (intel_crt_detect_ddc(connector))
+ status = connector_status_connected;
+ else
+ status = intel_crt_load_detect(crt);
+- intel_release_load_detect_pipe(connector, &tmp, &ctx);
++ intel_release_load_detect_pipe(connector, &tmp);
+ } else
+ status = connector_status_unknown;
+
++ drm_modeset_drop_locks(&ctx);
++ drm_modeset_acquire_fini(&ctx);
++
+ out:
+ intel_display_power_put(dev_priv, power_domain);
+ intel_runtime_pm_put(dev_priv);
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -8319,8 +8319,6 @@ bool intel_get_load_detect_pipe(struct d
+ connector->base.id, connector->name,
+ encoder->base.id, encoder->name);
+
+- drm_modeset_acquire_init(ctx, 0);
+-
+ retry:
+ ret = drm_modeset_lock(&config->connection_mutex, ctx);
+ if (ret)
+@@ -8435,15 +8433,11 @@ fail_unlock:
+ goto retry;
+ }
+
+- drm_modeset_drop_locks(ctx);
+- drm_modeset_acquire_fini(ctx);
+-
+ return false;
+ }
+
+ void intel_release_load_detect_pipe(struct drm_connector *connector,
+- struct intel_load_detect_pipe *old,
+- struct drm_modeset_acquire_ctx *ctx)
++ struct intel_load_detect_pipe *old)
+ {
+ struct intel_encoder *intel_encoder =
+ intel_attached_encoder(connector);
+@@ -8467,17 +8461,12 @@ void intel_release_load_detect_pipe(stru
+ drm_framebuffer_unreference(old->release_fb);
+ }
+
+- goto unlock;
+ return;
+ }
+
+ /* Switch crtc and encoder back off if necessary */
+ if (old->dpms_mode != DRM_MODE_DPMS_ON)
+ connector->funcs->dpms(connector, old->dpms_mode);
+-
+-unlock:
+- drm_modeset_drop_locks(ctx);
+- drm_modeset_acquire_fini(ctx);
+ }
+
+ static int i9xx_pll_refclk(struct drm_device *dev,
+@@ -11846,7 +11835,7 @@ static void intel_enable_pipe_a(struct d
+ struct intel_connector *connector;
+ struct drm_connector *crt = NULL;
+ struct intel_load_detect_pipe load_detect_temp;
+- struct drm_modeset_acquire_ctx ctx;
++ struct drm_modeset_acquire_ctx *ctx = dev->mode_config.acquire_ctx;
+
+ /* We can't just switch on the pipe A, we need to set things up with a
+ * proper mode and output configuration. As a gross hack, enable pipe A
+@@ -11863,10 +11852,8 @@ static void intel_enable_pipe_a(struct d
+ if (!crt)
+ return;
+
+- if (intel_get_load_detect_pipe(crt, NULL, &load_detect_temp, &ctx))
+- intel_release_load_detect_pipe(crt, &load_detect_temp, &ctx);
+-
+-
++ if (intel_get_load_detect_pipe(crt, NULL, &load_detect_temp, ctx))
++ intel_release_load_detect_pipe(crt, &load_detect_temp);
+ }
+
+ static bool
+--- a/drivers/gpu/drm/i915/intel_drv.h
++++ b/drivers/gpu/drm/i915/intel_drv.h
+@@ -754,8 +754,7 @@ bool intel_get_load_detect_pipe(struct d
+ struct intel_load_detect_pipe *old,
+ struct drm_modeset_acquire_ctx *ctx);
+ void intel_release_load_detect_pipe(struct drm_connector *connector,
+- struct intel_load_detect_pipe *old,
+- struct drm_modeset_acquire_ctx *ctx);
++ struct intel_load_detect_pipe *old);
+ int intel_pin_and_fence_fb_obj(struct drm_device *dev,
+ struct drm_i915_gem_object *obj,
+ struct intel_engine_cs *pipelined);
+--- a/drivers/gpu/drm/i915/intel_tv.c
++++ b/drivers/gpu/drm/i915/intel_tv.c
+@@ -1323,11 +1323,16 @@ intel_tv_detect(struct drm_connector *co
+ struct intel_load_detect_pipe tmp;
+ struct drm_modeset_acquire_ctx ctx;
+
++ drm_modeset_acquire_init(&ctx, 0);
++
+ if (intel_get_load_detect_pipe(connector, &mode, &tmp, &ctx)) {
+ type = intel_tv_detect_type(intel_tv, connector);
+- intel_release_load_detect_pipe(connector, &tmp, &ctx);
++ intel_release_load_detect_pipe(connector, &tmp);
+ } else
+ return connector_status_unknown;
++
++ drm_modeset_drop_locks(&ctx);
++ drm_modeset_acquire_fini(&ctx);
+ } else
+ return connector->status;
+
--- /dev/null
+From d6dd6843ff4a57c662dbc378b9f99a9c034b0956 Mon Sep 17 00:00:00 2001
+From: Paulo Zanoni <paulo.r.zanoni@intel.com>
+Date: Fri, 15 Aug 2014 15:59:32 -0300
+Subject: drm/i915: fix plane/cursor handling when runtime suspended
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Paulo Zanoni <paulo.r.zanoni@intel.com>
+
+commit d6dd6843ff4a57c662dbc378b9f99a9c034b0956 upstream.
+
+If we're runtime suspended and try to use the plane interfaces, we
+will get a lot of WARNs saying we did the wrong thing.
+
+We need to get runtime PM references to pin the objects, and to
+change the fences. The pin functions are the ideal places for
+this, but intel_crtc_cursor_set_obj() doesn't call them, so we also
+have to add get/put calls inside it. There is no problem if we runtime
+suspend right after these functions are finished, because the
+registers written are forwarded to system memory.
+
+Note: for a complete fix of the cursor-dpms test case, we also need
+the patch named "drm/i915: Don't try to enable cursor from setplane
+when crtc is disabled".
+
+v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
+v3: - Make get/put also surround the fence and unpin calls (Daniel and
+ Ville).
+ - Merge all the plane changes into a single patch since they're
+ the same fix.
+ - Add the comment requested by Daniel.
+v4: - Remove spurious whitespace (Ville).
+v5: - Remove intel_crtc_update_cursor() chunk since Ville did an
+ equivalent fix in another patch (Ville).
+v6: - Remove unpin chunk: it will be on a separate patch (Ville,
+ Chris, Daniel).
+v7: - Same thing, new color.
+
+Testcase: igt/pm_rpm/cursor
+Testcase: igt/pm_rpm/cursor-dpms
+Testcase: igt/pm_rpm/legacy-planes
+Testcase: igt/pm_rpm/legacy-planes-dpms
+Testcase: igt/pm_rpm/universal-planes
+Testcase: igt/pm_rpm/universal-planes-dpms
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82603
+Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_display.c | 24 ++++++++++++++++++++++++
+ 1 file changed, 24 insertions(+)
+
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -2200,6 +2200,15 @@ intel_pin_and_fence_fb_obj(struct drm_de
+ if (need_vtd_wa(dev) && alignment < 256 * 1024)
+ alignment = 256 * 1024;
+
++ /*
++ * Global gtt pte registers are special registers which actually forward
++ * writes to a chunk of system memory. Which means that there is no risk
++ * that the register values disappear as soon as we call
++ * intel_runtime_pm_put(), so it is correct to wrap only the
++ * pin/unpin/fence and not more.
++ */
++ intel_runtime_pm_get(dev_priv);
++
+ dev_priv->mm.interruptible = false;
+ ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined);
+ if (ret)
+@@ -2217,12 +2226,14 @@ intel_pin_and_fence_fb_obj(struct drm_de
+ i915_gem_object_pin_fence(obj);
+
+ dev_priv->mm.interruptible = true;
++ intel_runtime_pm_put(dev_priv);
+ return 0;
+
+ err_unpin:
+ i915_gem_object_unpin_from_display_plane(obj);
+ err_interruptible:
+ dev_priv->mm.interruptible = true;
++ intel_runtime_pm_put(dev_priv);
+ return ret;
+ }
+
+@@ -8087,6 +8098,15 @@ static int intel_crtc_cursor_set(struct
+ goto fail_locked;
+ }
+
++ /*
++ * Global gtt pte registers are special registers which actually
++ * forward writes to a chunk of system memory. Which means that
++ * there is no risk that the register values disappear as soon
++ * as we call intel_runtime_pm_put(), so it is correct to wrap
++ * only the pin/unpin/fence and not more.
++ */
++ intel_runtime_pm_get(dev_priv);
++
+ /* Note that the w/a also requires 2 PTE of padding following
+ * the bo. We currently fill all unused PTE with the shadow
+ * page and so we should always have valid PTE following the
+@@ -8099,16 +8119,20 @@ static int intel_crtc_cursor_set(struct
+ ret = i915_gem_object_pin_to_display_plane(obj, alignment, NULL);
+ if (ret) {
+ DRM_DEBUG_KMS("failed to move cursor bo into the GTT\n");
++ intel_runtime_pm_put(dev_priv);
+ goto fail_locked;
+ }
+
+ ret = i915_gem_object_put_fence(obj);
+ if (ret) {
+ DRM_DEBUG_KMS("failed to release fence for cursor");
++ intel_runtime_pm_put(dev_priv);
+ goto fail_unpin;
+ }
+
+ addr = i915_gem_obj_ggtt_offset(obj);
++
++ intel_runtime_pm_put(dev_priv);
+ } else {
+ int align = IS_I830(dev) ? 16 * 1024 : 256;
+ ret = i915_gem_object_attach_phys(obj, align);
--- /dev/null
+From c84db77010877da6c5da119868ed54c43d59e726 Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Wed, 17 Sep 2014 15:34:58 +0300
+Subject: drm/i915/hdmi: fix hdmi audio state readout
+
+From: Jani Nikula <jani.nikula@intel.com>
+
+commit c84db77010877da6c5da119868ed54c43d59e726 upstream.
+
+Check the correct bit for audio. Seems like a copy-paste error from the
+start:
+
+commit 9ed109a7b445e3f073d8ea72f888ec80c0532465
+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
+
+Reported-by: Martin Andersen <martin.x.andersen@gmail.com>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82756
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/intel_hdmi.c
++++ b/drivers/gpu/drm/i915/intel_hdmi.c
+@@ -728,7 +728,7 @@ static void intel_hdmi_get_config(struct
+ if (tmp & HDMI_MODE_SELECT_HDMI)
+ pipe_config->has_hdmi_sink = true;
+
+- if (tmp & HDMI_MODE_SELECT_HDMI)
++ if (tmp & SDVO_AUDIO_ENABLE)
+ pipe_config->has_audio = true;
+
+ pipe_config->adjusted_mode.flags |= flags;
--- /dev/null
+From dfb3d47b2369ad752ab9f7438bbf9949524b46ae Mon Sep 17 00:00:00 2001
+From: Scot Doyle <lkml14@scotdoyle.com>
+Date: Thu, 21 Aug 2014 16:08:02 +0000
+Subject: drm/i915: Ignore VBT backlight presence check on Acer C720 (4005U)
+
+From: Scot Doyle <lkml14@scotdoyle.com>
+
+commit dfb3d47b2369ad752ab9f7438bbf9949524b46ae upstream.
+
+commit c675949ec58ca50d5a3ae3c757892f1560f6e896
+Author: Jani Nikula <jani.nikula@intel.com>
+Date: Wed Apr 9 11:31:37 2014 +0300
+
+ drm/i915: do not setup backlight if not available according to VBT
+
+prevents backlight setup on the Acer C720 (Core i3 4005U CPU), which has a
+misconfigured VBT. Apply quirk to ignore the VBT backlight presence check
+during backlight setup.
+
+Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
+Tested-by: Tyler Cleveland <siralucardt@openmailbox.org>
+Cc: Jani Nikula <jani.nikula@intel.com>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_display.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -11690,6 +11690,9 @@ static struct intel_quirk intel_quirks[]
+ /* Acer C720 and C720P Chromebooks (Celeron 2955U) have backlights */
+ { 0x0a06, 0x1025, 0x0a11, quirk_backlight_present },
+
++ /* Acer C720 Chromebook (Core i3 4005U) */
++ { 0x0a16, 0x1025, 0x0a11, quirk_backlight_present },
++
+ /* Toshiba CB35 Chromebook (Celeron 2955U) */
+ { 0x0a06, 0x1179, 0x0a88, quirk_backlight_present },
+
--- /dev/null
+From bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a Mon Sep 17 00:00:00 2001
+From: Mathias Krause <minipli@googlemail.com>
+Date: Wed, 27 Aug 2014 18:41:19 +0200
+Subject: drm/i915: Remove bogus __init annotation from DMI callbacks
+
+From: Mathias Krause <minipli@googlemail.com>
+
+commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a upstream.
+
+The __init annotations for the DMI callback functions are wrong as this
+code can be called even after the module has been initialized, e.g. like
+this:
+
+ # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove
+ # modprobe i915
+ # echo 1 > /sys/bus/pci/rescan
+
+The first command will remove the PCI device from the kernel's device
+list so the second command won't see it right away. But as it registers
+a PCI driver it'll see it on the third command. If the system happens to
+match one of the DMI table entries we'll try to call a function in long
+released memory and generate an Oops, at best.
+
+Fix this by removing the bogus annotation.
+
+Modpost should have caught that one but it ignores section reference
+mismatches from the .rodata section. :/
+
+Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT")
+Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...")
+Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...")
+Signed-off-by: Mathias Krause <minipli@googlemail.com>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Duncan Laurie <dlaurie@chromium.org>
+Cc: Jarod Wilson <jarod@redhat.com>
+Cc: Rusty Russell <rusty@rustcorp.com.au> # Can modpost be fixed?
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_bios.c | 2 +-
+ drivers/gpu/drm/i915/intel_crt.c | 2 +-
+ drivers/gpu/drm/i915/intel_lvds.c | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_bios.c
++++ b/drivers/gpu/drm/i915/intel_bios.c
+@@ -1122,7 +1122,7 @@ init_vbt_defaults(struct drm_i915_privat
+ }
+ }
+
+-static int __init intel_no_opregion_vbt_callback(const struct dmi_system_id *id)
++static int intel_no_opregion_vbt_callback(const struct dmi_system_id *id)
+ {
+ DRM_DEBUG_KMS("Falling back to manually reading VBT from "
+ "VBIOS ROM for %s\n",
+--- a/drivers/gpu/drm/i915/intel_crt.c
++++ b/drivers/gpu/drm/i915/intel_crt.c
+@@ -780,7 +780,7 @@ static const struct drm_encoder_funcs in
+ .destroy = intel_encoder_destroy,
+ };
+
+-static int __init intel_no_crt_dmi_callback(const struct dmi_system_id *id)
++static int intel_no_crt_dmi_callback(const struct dmi_system_id *id)
+ {
+ DRM_INFO("Skipping CRT initialization for %s\n", id->ident);
+ return 1;
+--- a/drivers/gpu/drm/i915/intel_lvds.c
++++ b/drivers/gpu/drm/i915/intel_lvds.c
+@@ -531,7 +531,7 @@ static const struct drm_encoder_funcs in
+ .destroy = intel_encoder_destroy,
+ };
+
+-static int __init intel_no_lvds_dmi_callback(const struct dmi_system_id *id)
++static int intel_no_lvds_dmi_callback(const struct dmi_system_id *id)
+ {
+ DRM_INFO("Skipping LVDS initialization for %s\n", id->ident);
+ return 1;
--- /dev/null
+From a459249c73eaec1daf4e4657ea3564cc3550e66c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Mon, 11 Aug 2014 13:15:36 +0300
+Subject: drm/i915: Skip load detect when intel_crtc->new_enable==true
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+
+commit a459249c73eaec1daf4e4657ea3564cc3550e66c upstream.
+
+During suspend we turn off the crtcs, but leave the staged config in
+place so that we can restore the display(s) to their previous state on
+resume.
+
+During resume when we attempt to apply the force pipe A quirk we use the
+load detect mechanism. That doesn't check whether there was an already
+staged configuration for the crtc since that's not even possible during
+normal runtime load detection. But during resume it is possible, and if
+we just blindly go and overwrite the staged crtc configuration for the
+load detection we can no longer restore the display to the correct
+state.
+
+Even worse, we don't even clear all the staged connector->encoder->crtc
+links so we may end up using a cloned setup for the load detection, and
+after we're done we just clear the links related to the VGA output
+leaving the links for the other outputs in place. This will eventually
+result in calling intel_set_mode() with mode==NULL but with valid
+connector->encoder->crtc links which will result in dereferencing the
+NULL mode since the code thinks it will have to a modeset.
+
+To avoid these problems don't use any crtc with new_enabled==true for
+load detection.
+
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_display.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -8359,10 +8359,14 @@ retry:
+ i++;
+ if (!(encoder->possible_crtcs & (1 << i)))
+ continue;
+- if (!possible_crtc->enabled) {
+- crtc = possible_crtc;
+- break;
+- }
++ if (possible_crtc->enabled)
++ continue;
++ /* This can occur when applying the pipe A quirk on resume. */
++ if (to_intel_crtc(possible_crtc)->new_enabled)
++ continue;
++
++ crtc = possible_crtc;
++ break;
+ }
+
+ /*
--- /dev/null
+From 7a98948f3b536ca9a077e84966ddc0e9f53726df Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Mon, 8 Sep 2014 17:43:01 +0300
+Subject: drm/i915: Wait for vblank before enabling the TV encoder
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+
+commit 7a98948f3b536ca9a077e84966ddc0e9f53726df upstream.
+
+The vblank waits in intel_tv_detect_type() are timing out for some
+reason. This is a regression caused removing seemingly useless vblank
+waits from the modeset seqeuence in:
+
+ commit 56ef52cad5e37fca89638e4bad598a994ecc3d9f
+ Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
+ Date: Thu May 8 19:23:15 2014 +0300
+
+ drm/i915: Kill vblank waits after pipe enable on gmch platforms
+
+So it turns out they weren't all entirely useless. Apparently the pipe
+has to go through one full frame before we enable the TV port. Add a
+vblank wait to intel_enable_tv() to make sure that happens.
+
+Another approach was attempted by placing the vblank wait just after
+enabling the port. The theory behind that attempt was that we need to
+let the port stay enabled for one full frame before disabling it again
+during load detection. But that didn't work, and we definitely must
+have the vblank wait before enabling the port.
+
+Cc: Alan Bartlett <ajb@elrepo.org>
+Tested-by: Alan Bartlett <ajb@elrepo.org>
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79311
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/intel_tv.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/i915/intel_tv.c
++++ b/drivers/gpu/drm/i915/intel_tv.c
+@@ -854,6 +854,10 @@ intel_enable_tv(struct intel_encoder *en
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
++ /* Prevents vblank waits from timing out in intel_tv_detect_type() */
++ intel_wait_for_vblank(encoder->base.dev,
++ to_intel_crtc(encoder->base.crtc)->pipe);
++
+ I915_WRITE(TV_CTL, I915_READ(TV_CTL) | TV_ENC_ENABLE);
+ }
+
--- /dev/null
+From f01ea0c3d9db536c64d47922716d8b3b8f21d850 Mon Sep 17 00:00:00 2001
+From: Thomas Hellstrom <thellstrom@vmware.com>
+Date: Thu, 28 Aug 2014 11:53:23 +0200
+Subject: drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle
+
+From: Thomas Hellstrom <thellstrom@vmware.com>
+
+commit f01ea0c3d9db536c64d47922716d8b3b8f21d850 upstream.
+
+The code waiting for fifo idle was incorrect and could possibly spin
+forever under certain circumstances.
+
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Reported-by: Mark Sheldon <markshel@vmware.com>
+Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
+Reivewed-by: Mark Sheldon <markshel@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+@@ -180,8 +180,9 @@ void vmw_fifo_release(struct vmw_private
+
+ mutex_lock(&dev_priv->hw_mutex);
+
++ vmw_write(dev_priv, SVGA_REG_SYNC, SVGA_SYNC_GENERIC);
+ while (vmw_read(dev_priv, SVGA_REG_BUSY) != 0)
+- vmw_write(dev_priv, SVGA_REG_SYNC, SVGA_SYNC_GENERIC);
++ ;
+
+ dev_priv->last_read_seqno = ioread32(fifo_mem + SVGA_FIFO_FENCE);
+
--- /dev/null
+From d9fdb9fba7ec08769594abede8f78523ed3f025a Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Mon, 1 Sep 2014 18:07:38 +0100
+Subject: imx-drm: imx-ldb: fix NULL pointer in imx_ldb_unbind()
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+commit d9fdb9fba7ec08769594abede8f78523ed3f025a upstream.
+
+When trying to unbind imx-drm, the following oops was observed from
+the imx-ldb driver:
+
+Unable to handle kernel NULL pointer dereference at virtual address 0000001c
+pgd = de954000
+[0000001c] *pgd=2e92c831, *pte=00000000, *ppte=00000000
+Internal error: Oops: 17 [#1] SMP ARM
+Modules linked in: bnep rfcomm bluetooth nfsd exportfs hid_cypress brcmfmac brcmutil snd_soc_fsl_ssi snd_soc_fsl_spdif imx_pcm_fiq imx_pcm_dma imx_ldb(C) imx_thermal imx_sdma imx2_wdt snd_soc_sgtl5000 snd_soc_imx_sgtl5000 snd_soc_imx_spdif snd_soc_imx_audmux
+CPU: 1 PID: 1228 Comm: bash Tainted: G C 3.16.0-rc2+ #1229
+task: ea378d80 ti: de948000 task.ti: de948000
+PC is at imx_ldb_unbind+0x1c/0x58 [imx_ldb]
+LR is at component_unbind+0x38/0x70
+pc : [<bf025068>] lr : [<c0353108>] psr: 200f0013
+sp : de949da8 ip : de949dc0 fp : de949dbc
+r10: e9a44b0c r9 : 00000000 r8 : de949f78
+r7 : 00000012 r6 : e9b3f400 r5 : e9b133b8 r4 : e9b13010
+r3 : 00000000 r2 : e9b3f400 r1 : ea9a0210 r0 : e9b13020
+Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
+Control: 10c53c7d Table: 2e95404a DAC: 00000015
+Process bash (pid: 1228, stack limit = 0xde948240)
+Stack: (0xde949da8 to 0xde94a000)
+...
+Backtrace:
+[<bf02504c>] (imx_ldb_unbind [imx_ldb]) from [<c0353108>] (component_unbind+0x38/0x70)
+[<c03530d0>] (component_unbind) from [<c03531d4>] (component_unbind_all+0x94/0xc8)
+[<c0353140>] (component_unbind_all) from [<c04bc224>] (imx_drm_driver_unload+0x34/0x4c)
+[<c04bc1f0>] (imx_drm_driver_unload) from [<c03394a4>] (drm_dev_unregister+0x2c/0xa0)
+[<c0339478>] (drm_dev_unregister) from [<c0339f8c>] (drm_put_dev+0x30/0x6c)
+[<c0339f5c>] (drm_put_dev) from [<c04bc1cc>] (imx_drm_unbind+0x14/0x18)
+[<c04bc1b8>] (imx_drm_unbind) from [<c03530b4>] (component_master_del+0xbc/0xd8)
+...
+Code: e5904058 e2840010 e2845fea e59430a0 (e593301c)
+---[ end trace 4f211c6dbbcd4963 ]---
+
+This is caused by only having one channel out of the pair configured in
+DT; the second channel remains uninitialised, but upon unbind, the
+driver attempts to clean up both, thereby dereferencing a NULL pointer.
+Avoid this by checking that the second channel is initialised.
+
+Fixes: 1b3f76756633 ("imx-drm: initialise drm components directly")
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/imx-drm/imx-ldb.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/staging/imx-drm/imx-ldb.c
++++ b/drivers/staging/imx-drm/imx-ldb.c
+@@ -574,6 +574,9 @@ static void imx_ldb_unbind(struct device
+ for (i = 0; i < 2; i++) {
+ struct imx_ldb_channel *channel = &imx_ldb->channel[i];
+
++ if (!channel->connector.funcs)
++ continue;
++
+ channel->connector.funcs->destroy(&channel->connector);
+ channel->encoder.funcs->destroy(&channel->encoder);
+ }
--- /dev/null
+From 3a44a2058747d71385eb69691c7f977cb58cc293 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Mon, 1 Sep 2014 18:07:33 +0100
+Subject: imx-drm: ipuv3-plane: fix ipu_plane_dpms()
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+commit 3a44a2058747d71385eb69691c7f977cb58cc293 upstream.
+
+When unbinding imx-drm, the following oops was observed:
+
+Unable to handle kernel NULL pointer dereference at virtual address 00000004
+pgd = e995c000
+[00000004] *pgd=4fea5831
+Internal error: Oops: 817 [#1] SMP ARM
+Modules linked in: bnep rfcomm bluetooth nfsd exportfs hid_cypress brcmfmac brcmutil snd_soc_fsl_ssi snd_soc_fsl_spdif imx_pcm_fiq imx_pcm_dma snd_soc_sgtl5000 imx_sdma imx2_wdt imx_ldb(C) imx_thermal snd_soc_imx_sgtl5000 snd_soc_imx_spdif snd_soc_imx_audmux
+CPU: 1 PID: 779 Comm: bash Tainted: G C 3.16.0-rc2+ #1230
+task: ea9eb180 ti: ea378000 task.ti: ea378000
+PC is at ipu_dp_put+0x10/0x18
+LR is at ipu_plane_dpms+0x60/0x8c
+pc : [<c0350d20>] lr : [<c04bd9e8>] psr: 200f0013
+sp : ea379d80 ip : ea379d90 fp : ea379d8c
+r10: 00100100 r9 : 00000000 r8 : 00200200
+r7 : e9ba0264 r6 : e9ba01f8 r5 : 00000000 r4 : ea34b800
+r3 : 00000000 r2 : 00000000 r1 : 0000009b r0 : 00000000
+Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
+Control: 10c53c7d Table: 3995c04a DAC: 00000015
+Process bash (pid: 779, stack limit = 0xea378240)
+Stack: (0xea379d80 to 0xea37a000)
+...
+Backtrace:
+[<c0350d10>] (ipu_dp_put) from [<c04bd9e8>] (ipu_plane_dpms+0x60/0x8c)
+[<c04bd988>] (ipu_plane_dpms) from [<c04bda40>] (ipu_disable_plane+0x2c/0x60)
+[<c04bda14>] (ipu_disable_plane) from [<c04bda9c>] (ipu_plane_destroy+0x28/0x60)
+[<c04bda74>] (ipu_plane_destroy) from [<c033ff84>] (drm_mode_config_cleanup+0x1b8/0x250)
+[<c033fdcc>] (drm_mode_config_cleanup) from [<c04bc234>] (imx_drm_driver_unload+0x44/0x4c)
+[<c04bc1f0>] (imx_drm_driver_unload) from [<c03394a4>] (drm_dev_unregister+0x2c/0xa0)
+[<c0339478>] (drm_dev_unregister) from [<c0339f8c>] (drm_put_dev+0x30/0x6c)
+[<c0339f5c>] (drm_put_dev) from [<c04bc1cc>] (imx_drm_unbind+0x14/0x18)
+[<c04bc1b8>] (imx_drm_unbind) from [<c03530b4>] (component_master_del+0xbc/0xd8)
+...
+Code: e1a0c00d e92dd800 e24cb004 e3a03000 (e5c03004)
+
+This is caused by a missing check in ipu_plane_dpms for a NULL pointer.
+
+Fixes: b8d181e408af ("staging: drm/imx: add drm plane support")
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/staging/imx-drm/ipuv3-plane.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/imx-drm/ipuv3-plane.c
++++ b/drivers/staging/imx-drm/ipuv3-plane.c
+@@ -281,7 +281,8 @@ static void ipu_plane_dpms(struct ipu_pl
+
+ ipu_idmac_put(ipu_plane->ipu_ch);
+ ipu_dmfc_put(ipu_plane->dmfc);
+- ipu_dp_put(ipu_plane->dp);
++ if (ipu_plane->dp)
++ ipu_dp_put(ipu_plane->dp);
+ }
+ }
+
hid-magicmouse-sanity-check-report-size-in-raw_event-callback.patch
hid-logitech-dj-prevent-false-errors-to-be-shown.patch
xattr-fix-check-for-simultaneous-glibc-header-inclusion.patch
+drm-i915-skip-load-detect-when-intel_crtc-new_enable-true.patch
+drm-i915-fix-locking-for-intel_enable_pipe_a.patch
+drm-i915-don-t-try-to-retrain-a-dp-link-on-an-inactive-crtc.patch
+drm-i915-fix-plane-cursor-handling-when-runtime-suspended.patch
+drm-i915-ignore-vbt-backlight-presence-check-on-acer-c720-4005u.patch
+drm-i915-remove-bogus-__init-annotation-from-dmi-callbacks.patch
+drm-i915-fix-lock-dropping-in-intel_tv_detect.patch
+drm-i915-fix-eio-wedged-handling-in-gem-fault-handler.patch
+drm-i915-wait-for-vblank-before-enabling-the-tv-encoder.patch
+drm-i915-hdmi-fix-hdmi-audio-state-readout.patch
+drm-i915-don-t-leak-command-parser-tables-on-suspend-resume.patch
+drm-ast-open-key-before-detect-chips.patch
+drm-ast-ast2000-cannot-be-detected-correctly.patch
+imx-drm-ipuv3-plane-fix-ipu_plane_dpms.patch
+imx-drm-imx-ldb-fix-null-pointer-in-imx_ldb_unbind.patch
+drm-vmwgfx-fix-a-potential-infinite-spin-waiting-for-fifo-idle.patch