Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
On Wed, 2018-04-04 at 22:35 +0300, Ville Syrjälä wrote:
> On Wed, Apr 04, 2018 at 03:00:12PM -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
> > > > > > Cc: Laura Abbott
> > > > > > Cc: Dhinakaran Pandiyan
> > > > > > Cc: Ville Syrjälä
> > > > > > Cc: sta...@vger.kernel.org
> > > > > > 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?
> >
> > Oh-additionally I did forget to mention that i have actually witnessed the
> > channel eq failures in the ESI getting dropped without this patch.
>
> Not sure what that means. I don't think there is any sideband messaging
> involved in link training so not sure what is dropped in this case. The
> link status/etc. are just polled directly by the upstream device.
no, no nononono they are not always with MST. mdnavare is right regarding the
channel EQ occasionally being the only in
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
On Wed, 2018-04-04 at 22:31 +0300, Ville Syrjälä wrote:
> 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
> > > > > > Cc: Laura Abbott
> > > > > > Cc: Dhinakaran Pandiyan
> > > > > > Cc: Ville Syrjälä
> > > > > > Cc: sta...@vger.kernel.org
> > > > > > 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 i
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
On Wed, Apr 04, 2018 at 03:00:12PM -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
> > > > > Cc: Laura Abbott
> > > > > Cc: Dhinakaran Pandiyan
> > > > > Cc: Ville Syrjälä
> > > > > Cc: sta...@vger.kernel.org
> > > > > 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?
> Oh-additionally I did forget to mention that i have actually witnessed the
> channel eq failures in the ESI getting dropped without this patch.
Not sure what that means. I don't think there is any sideband messaging
involved in link training so not sure what is dropped in this case. The
link status/etc. are just polled directly by the upstream device.
> Meaning if
> we miss them, there's a chance the hub may just not choose to send them again
> for whatever reason.
> >
> > > * 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);
> >
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
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
> > > > > Cc: Laura Abbott
> > > > > Cc: Dhinakaran Pandiyan
> > > > > Cc: Ville Syrjälä
> > > > > Cc: sta...@vger.kernel.org
> > > > > 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_
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
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
> > > > Cc: Laura Abbott
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Ville Syrjälä
> > > > Cc: sta...@vger.kernel.org
> > > > 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?
Oh-additionally I did forget to mention that i have actually witnessed the
channel eq failures in the ESI getting dropped without this patch. Meaning if
we miss them, there's a chance the hub may just not choose to send them again
for whatever reason.
>
> > * 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
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
> > > > Cc: Laura Abbott
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Ville Syrjälä
> > > > Cc: sta...@vger.kernel.org
> > > > 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.
>
> > * 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)
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
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
> > > Cc: Laura Abbott
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Ville Syrjälä
> > > Cc: sta...@vger.kernel.org
> > > 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?
> * 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
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
On Wed, 2018-04-04 at 11:44 -0700, Manasi Navare wrote:
> On Wed, Apr 04, 2018 at 06:34:29PM +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
> > > Cc: Laura Abbott
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Ville Syrjälä
> > > Cc: sta...@vger.kernel.org
> > > 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?
> >
>
> The problem occurs only in case of MST because the Channel EQ failure is
> notified
> through ESI sideband AUX messages which potentially can get dropped because
> of disabling
> DPMS. But in case of SST, we detect the channel EQ failure write during the
> EQ TPS sequence
> which happens on the main link.
mhm- that is the big problem it causes, at least with this patchset. I've been
considering maybe looking into probing downstream sinks with remote dpcd reads
to see their link training status, as I think that might actually be the real
reason for why there's this weird difference between the channel eq status in
the esi and the actual link training status of the hub in the dpcd registers
that are shared with SST. but that's for a later date :)
>
> Manasi
>
> > > +
> > > 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
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
On Wed, Apr 04, 2018 at 06:34:29PM +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
> > Cc: Laura Abbott
> > Cc: Dhinakaran Pandiyan
> > Cc: Ville Syrjälä
> > Cc: sta...@vger.kernel.org
> > 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?
>
The problem occurs only in case of MST because the Channel EQ failure is
notified
through ESI sideband AUX messages which potentially can get dropped because of
disabling
DPMS. But in case of SST, we detect the channel EQ failure write during the EQ
TPS sequence
which happens on the main link.
Manasi
> > +
> > 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
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
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
> > Cc: Laura Abbott
> > Cc: Dhinakaran Pandiyan
> > Cc: Ville Syrjälä
> > Cc: sta...@vger.kernel.org
> > 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
* 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
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
> Cc: Laura Abbott
> Cc: Dhinakaran Pandiyan
> Cc: Ville Syrjälä
> Cc: sta...@vger.kernel.org
> 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?
> +
> 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
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST
On 04/02/2018 02:26 PM, 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
Cc: Laura Abbott
Cc: Dhinakaran Pandiyan
Cc: Ville Syrjälä
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
Still able to boot docked and lid closed so
Tested-by: Laura Abbott
---
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;
+
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);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
