On Wed, Apr 04, 2018 at 02:59:09PM -0400, Lyude Paul wrote:
> On Wed, 2018-04-04 at 21:53 +0300, Ville Syrjälä wrote:
> > On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote:
> > > On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote:
> > > > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > > > > While enabling/disabling DPMS before link training with MST hubs is
> > > > > perfectly valid; unfortunately disabling DPMS results in some devices
> > > > > disabling their AUX CH block as well. For SST this isn't as much of a
> > > > > problem, but for MST we need to be able to continue handling aux
> > > > > transactions even when none of the sinks are turned on since it's
> > > > > possible for us to have a single atomic commit which results in
> > > > > disabling each downstream sink, followed by subsequently re-enabling
> > > > > each sink.
> > > > >
> > > > > If we don't do this, we'll end up stalling any pending ESI interrupts
> > > > > from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> > > > > timespan makes it so that link fallback retraining for MST (which I
> > > > > will
> > > > > be submitting to the ML shortly) fails due to the channel EQ failure
> > > > > interrupts potentially getting dropped. Additionally, when performing
> > > > > a
> > > > > modeset that brings the hub status's link status from bad -> good
> > > > > having
> > > > > ESIs disabled for that long causes us to miss the hub's response to us
> > > > > trying to start link training as well.
> > > > >
> > > > > Since any sink with MST is going to support DisplayPort 1.2 anyway,
> > > > > save
> > > > > us the hassle of trying to wait until the sink comes back up and just
> > > > > never shut the aux block down.
> > > > >
> > > > > Changes since v2:
> > > > > - Fix patch name, no functional changes
> > > > >
> > > > > Signed-off-by: Lyude Paul <lyude@xxxxxxxxxx>
> > > > > Cc: Laura Abbott <labbott@xxxxxxxxxx>
> > > > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@xxxxxxxxx>
> > > > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > > > > Cc: stable@xxxxxxxxxxxxxxx
> > > > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable
> > > > > MST
> > > > > hub.")
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_dp.c | 6 ++++--
> > > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 62f82c4298ac..0479c377981b 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > > *intel_dp,
> > > > > int mode)
> > > > > return;
> > > > >
> > > > > if (mode != DRM_MODE_DPMS_ON) {
> > > > > + unsigned char data = intel_dp->is_mst ?
> > > > > + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> > > >
> > > > This smells like a workaround for an actual bug somewhere. Why exactly
> > > > is the slower wakeup or the AUX block a problem for MST but not for SST
> > > > when the link training is exactly the same for SST and MST?
> > >
> > > I actually thought about this but I still think this is the appropriate
> > > fix.
> > > So; the real reason for the wakeup not being a problem with SST is that
> > > for
> > > DPMS on with SST, we actually do a wait to make sure that the hub is ready
> > > before continuing. And yes: I'm fairly sure SST does actually have around
> > > the
> > > same wakeup time that MST does, but with the wait we do it doesn't reallhy
> > > make a difference. With MST, we could do this but there's a few reasons I
> > > don't think we should:
> > > * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub that
> > > has
> > > MST is going to be guaranteed to have this.
> > > * Turning off the aux block means that there's a high chance we're going
> > > to
> > > miss ESIs from sinks
> >
> > And how exactly do we lose irqs? The hub/whatever throws the up req msgs
> > away if we don't read them within some really short time?
> That's my hypothesis at least. I'm betting that on the fact that when I was
> implementing MST retraining before we put the intel_dp_check_mst_status() (or
> whatever it's called) into the dig workqueue, getting the sink to go down and
> come back up was a lot more unreliable whenever I introduced anything that
> would block the esi handler for longer then a very brief period of time (say,
> 50-100ms?). I've seen some notes elsewhere too that seemed to imply for SST,
> things were pretty sensitive to irq latency (line 1050, intel_dp.c) so it
> wouldn't be terribly surprising if it's the same for MST. At the very least,
> now that we've got the ESI handler running in the dig worker things seem to
> have gotten a /lot/ more reliable now that we can basically go the whole
> modeset without blocking the ESI handler for very long.
Hmm. OK, so the spec seems to be saying that we have 100ms to read
the UP_REQ/DOWN_REPLY msg after the IRQ_HPD. That's still a lot more
than the 1ms max allowed wakeup time. Looks like there's a extended
wakeup time request/grant mechanism now, but without the explicit
grant (which we don't do) the 1ms still holds.
> >
> > > * It's faster to keep the aux block on anyway
> > >
> > >
> > > >
> > > > > +
> > > > > if (downstream_hpd_needs_d0(intel_dp))
> > > > > return;
> > > > >
> > > > > - ret = drm_dp_dpcd_writeb(&intel_dp->aux,
> > > > > DP_SET_POWER,
> > > > > - DP_SET_POWER_D3);
> > > > > + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
> > > > > DP_SET_POWER,
> > > > > data);
> > > > > } else {
> > > > > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > > > >
> > > > > --
> > > > > 2.14.3
> > > >
> > > >
> > >
> > > --
> > > Cheers,
> > > Lyude Paul
> >
> >
> --
> Cheers,
> Lyude Paul
--
Ville Syrjälä
Intel OTC