From: Lyude <cpaul@redhat.com>
To: intel-gfx@lists.freedesktop.org
Cc: stable@vger.kernel.org,
"open list:INTEL DRM DRIVERS excluding Poulsbo, Moorestow...,
linux-kernel@vger.kernel.org open list"
<dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>, Lyude <cpaul@redhat.com>
Subject: [PATCH v2] drm/i915: Discard previous atomic state on resume if connectors change
Date: Fri, 6 May 2016 17:39:56 -0400 [thread overview]
Message-ID: <1462570796-22500-1-git-send-email-cpaul@redhat.com> (raw)
If an MST device is disconnected while the machine is suspended, the
number of connectors will change as well after we call
intel_dp_mst_resume(). This means that any previous atomic state we had
before suspending is no longer valid, since it'll still be pointing to
missing connectors. We need to check for this before committing the
state, otherwise we'll kernel panic on resume whenever if any MST
display was disconnected before we started resuming:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffffa01588ef>] drm_atomic_helper_check_modeset+0x29f/0xb40 [drm_kms_helper]
Call Trace:
[<ffffffffa02354f4>] intel_atomic_check+0x34/0x1180 [i915]
[<ffffffff810e6c3f>] ? mark_held_locks+0x6f/0xa0
[<ffffffff810e6d99>] ? trace_hardirqs_on_caller+0x129/0x1b0
[<ffffffffa00ff1d2>] drm_atomic_check_only+0x192/0x620 [drm]
[<ffffffff813ee001>] ? pci_pm_thaw+0x21/0x90
[<ffffffffa00ff677>] drm_atomic_commit+0x17/0x60 [drm]
[<ffffffffa023e0ad>] intel_display_resume+0xbd/0x160 [i915]
[<ffffffff813ee070>] ? pci_pm_thaw+0x90/0x90
[<ffffffffa01b60d8>] i915_drm_resume+0xd8/0x160 [i915]
[<ffffffffa01b6185>] i915_pm_resume+0x25/0x30 [i915]
[<ffffffff813ee0d4>] pci_pm_resume+0x64/0xa0
[<ffffffff814d9ea0>] dpm_run_callback+0x90/0x190
[<ffffffff814da455>] device_resume+0xd5/0x1f0
[<ffffffff814da58d>] async_resume+0x1d/0x50
[<ffffffff810b6718>] async_run_entry_fn+0x48/0x150
[<ffffffff810acc19>] process_one_work+0x1e9/0x5c0
[<ffffffff810acb96>] ? process_one_work+0x166/0x5c0
[<ffffffff810ad038>] worker_thread+0x48/0x4e0
[<ffffffff810acff0>] ? process_one_work+0x5c0/0x5c0
[<ffffffff810b3794>] kthread+0xe4/0x100
[<ffffffff81742672>] ret_from_fork+0x22/0x50
[<ffffffff810b36b0>] ? kthread_create_on_node+0x200/0x200
Changes since v1:
- Move drm_atomic_state_free() call down so we're holding the
appropriate locks when destroying the atomic state
Cc: stable@vger.kernel.org
Signed-off-by: Lyude <cpaul@redhat.com>
---
drivers/gpu/drm/i915/intel_display.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 0f29ef6..d68efc7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15934,6 +15934,18 @@ void intel_display_resume(struct drm_device *dev)
retry:
ret = drm_modeset_lock_all_ctx(dev, &ctx);
+ /*
+ * With MST, the number of connectors can change between suspend and
+ * resume, which means that the state we want to restore might now be
+ * impossible to use since it'll be pointing to non-existant
+ * connectors.
+ */
+ if (ret == 0 &&
+ state->num_connector != dev->mode_config.num_connector) {
+ drm_atomic_state_free(state);
+ state = NULL;
+ }
+
if (ret == 0 && !setup) {
setup = true;
--
2.5.5
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2016-05-06 21:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 21:39 Lyude [this message]
2016-05-09 6:42 ` [PATCH v2] drm/i915: Discard previous atomic state on resume if connectors change Daniel Vetter
2016-05-09 14:07 ` Lyude Paul
2016-05-09 14:53 ` Daniel Vetter
2016-05-09 15:31 ` Lyude Paul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1462570796-22500-1-git-send-email-cpaul@redhat.com \
--to=cpaul@redhat.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox