From: Daniel Vetter <daniel@ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/i915: Protect MST retraining with connection_mutex
Date: Wed, 23 Sep 2015 10:01:05 +0200 [thread overview]
Message-ID: <20150923080105.GG3383@phenom.ffwll.local> (raw)
In-Reply-To: <55F95721.3010101@linux.intel.com>
On Wed, Sep 16, 2015 at 01:48:49PM +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 03-09-15 om 14:11 schreef Ville Syrjälä:
> > On Thu, Aug 27, 2015 at 06:36:48PM +0300, ville.syrjala@linux.intel.com wrote:
> >> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>
> >> Grab the connection_mutex around MSR link retraining to protect it
> >> against a concurrent modeset. We already do the same for SST.
> >>
> >> DP hpd_pulse can still otherwise race against modeset and ->detect(), so
> >> it's not clear what will happen when both want to scribble into eg.
> >> intel_dp->dpcd[] at the same time. But sorting it all out requires way
> >> more thought than I'm willing to expend now.
> > Actually I suppose this might not work out so well after all. I suppose
> > MST depends on short HPDs during modeset due to the sideband stuff.
> >
> > So if we want to grab modeset locks for retraining, I suppose we'd
> > need to move the retraining to happen from .hot_plug() which gets run
> > from the other hotplug work, and so wouldn't interfere with sideband.
> >
> I think it would be better to have a per encoder mutex. In the future we may want to run modeset
> disable/enable async, in which case it may not hold the connection_mutex.
>
> If we do decide on a separate mutex then it would also be useful to also think about how to
> protect intel_mst_*(dis,en)able_dp. :)
We need to sync re-training with any other modeset work. Which means
another thing to get right for async modesets.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-09-23 7:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-27 15:36 [PATCH 0/3] drm/i915: MST link training locking and cleanups ville.syrjala
2015-08-27 15:36 ` [PATCH 1/3] drm/i915: Protect MST retraining with connection_mutex ville.syrjala
2015-09-03 12:11 ` Ville Syrjälä
2015-09-16 11:48 ` Maarten Lankhorst
2015-09-23 8:01 ` Daniel Vetter [this message]
2015-08-27 15:36 ` [PATCH 2/3] drm/i915: Flatten the mst suspend/resume functions a bit ville.syrjala
2015-09-16 12:28 ` Maarten Lankhorst
2015-08-27 15:36 ` [PATCH 3/3] drm/i915: Flatten intel_dp_check_mst_status() ville.syrjala
2015-09-16 13:07 ` Maarten Lankhorst
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=20150923080105.GG3383@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.