drm/i915: lock around link status and link training.

Commit Message

Dave Airlie Aug. 5, 2014, 12:40 a.m. UTC

From: Dave Airlie <[e-mail]>

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 <[e-mail]>
---
 drivers/gpu/drm/i915/intel_dp.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Daniel Vetter Aug. 5, 2014, 10:07 p.m. UTC | #1

On Tue, Aug 5, 2014 at 2:40 AM, Dave Airlie <[e-mail]> wrote:
> @@ -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 you drop the FIXME here (since this patch address it) this is

Reviewed-by: Daniel Vetter <[e-mail]>

I guess you'll pick this up directly to drm-next like that other mst
fixes?
-Daniel

Dave Airlie Aug. 5, 2014, 11:59 p.m. UTC | #2

On 6 August 2014 08:07, Daniel Vetter <[e-mail]> wrote:
> On Tue, Aug 5, 2014 at 2:40 AM, Dave Airlie <[e-mail]> wrote:
>> @@ -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 you drop the FIXME here (since this patch address it) this is
>
> Reviewed-by: Daniel Vetter <[e-mail]>
>
> I guess you'll pick this up directly to drm-next like that other mst
> fixes?

FIXME gone, and yes in -next now.

Hopefully that is all the QA fixes :-)

Dave.

Dave Airlie Aug. 6, 2014, 12:12 a.m. UTC | #3

On 6 August 2014 09:59, Dave Airlie <[e-mail]> wrote:
> On 6 August 2014 08:07, Daniel Vetter <[e-mail]> wrote:
>> On Tue, Aug 5, 2014 at 2:40 AM, Dave Airlie <[e-mail]> wrote:
>>> @@ -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 you drop the FIXME here (since this patch address it) this is
>>
>> Reviewed-by: Daniel Vetter <[e-mail]>
>>
>> I guess you'll pick this up directly to drm-next like that other mst
>> fixes?
>
> FIXME gone, and yes in -next now.
>
> Hopefully that is all the QA fixes :-)

I dropped the first hunk of this actually, not sure what I was thinking locking
in the short pulse can't happen. Though we should never have a retrain here
that we don't want anyways.

I suspect we need some finer grained locking here.

Dave.

Patch

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;