From: Dave Airlie <airlied@gmail.com>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH] drm/i915: lock around link status and link training.
Date: Tue, 5 Aug 2014 10:40:20 +1000 [thread overview]
Message-ID: <1407199220-10984-1-git-send-email-airlied@gmail.com> (raw)
From: Dave Airlie <airlied@redhat.com>
We need to take the connection mutex around the link status
check for non-MST case, but also around the MST link training
on short HPDs.
I suspect we actually should have a dpcd lock in the future as
well, that just lock the local copies of dpcd and flags stored
from that.
Signed-off-by: Dave Airlie <airlied@redhat.com>
---
drivers/gpu/drm/i915/intel_dp.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0f05b88..145ac7c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3437,6 +3437,7 @@ intel_dp_handle_test_request(struct intel_dp *intel_dp)
static int
intel_dp_check_mst_status(struct intel_dp *intel_dp)
{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
bool bret;
if (intel_dp->is_mst) {
@@ -3449,12 +3450,14 @@ go_again:
if (bret == true) {
/* check link status - esi[10] = 0x200c */
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
if (intel_dp->active_mst_links && !drm_dp_channel_eq_ok(&esi[10], intel_dp->lane_count)) {
DRM_DEBUG_KMS("channel EQ not ok, retraining\n");
intel_dp_start_link_train(intel_dp);
intel_dp_complete_link_train(intel_dp);
intel_dp_stop_link_train(intel_dp);
}
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
DRM_DEBUG_KMS("got esi %02x %02x %02x\n", esi[0], esi[1], esi[2]);
ret = drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi, &handled);
@@ -3502,10 +3505,13 @@ go_again:
void
intel_dp_check_link_status(struct intel_dp *intel_dp)
{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = &dp_to_dig_port(intel_dp)->base;
u8 sink_irq_vector;
u8 link_status[DP_LINK_STATUS_SIZE];
+ WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+
/* FIXME: This access isn't protected by any locks. */
if (!intel_encoder->connectors_active)
return;
@@ -4021,7 +4027,9 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
* we'll check the link status via the normal hot plug path later -
* but for short hpds we should check it now
*/
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
intel_dp_check_link_status(intel_dp);
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
}
}
return false;
--
1.9.3
next reply other threads:[~2014-08-05 0:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-05 0:40 Dave Airlie [this message]
2014-08-05 22:07 ` [PATCH] drm/i915: lock around link status and link training Daniel Vetter
2014-08-05 23:59 ` Dave Airlie
2014-08-06 0:12 ` Dave Airlie
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=1407199220-10984-1-git-send-email-airlied@gmail.com \
--to=airlied@gmail.com \
--cc=intel-gfx@lists.freedesktop.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