lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <89a025ea-b7a2-81f0-7277-341d3c96ebe1@redhat.com> Date: Mon, 2 Apr 2018 19:15:04 -0700 From: Laura Abbott <labbott@...hat.com> To: Lyude Paul <lyude@...hat.com>, intel-gfx@...ts.freedesktop.org Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@...el.com>, Ville Syrjälä <ville.syrjala@...ux.intel.com>, stable@...r.kernel.org, Jani Nikula <jani.nikula@...ux.intel.com>, Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, Rodrigo Vivi <rodrigo.vivi@...el.com>, David Airlie <airlied@...ux.ie>, dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org Subject: Re: [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 <lyude@...hat.com> > Cc: Laura Abbott <labbott@...hat.com> > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@...el.com> > Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com> > Cc: stable@...r.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 <labbott@...hat.com> > --- > 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); > >
Powered by blists - more mailing lists