Message ID | 1400876205-12997-1-git-send-email-jbarnes@virtuousgeek.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Fri, May 23, 2014 at 01:16:40PM -0700, Jesse Barnes wrote: > This is a bit like the CMN reset de-assert we do in DPIO_CTL, except > that it resets the whole common lane section of the PHY. This is > required on machines where the BIOS doesn't do this for us on boot or > resume to properly re-calibrate and get the PHY ready to transmit data. > > Without this patch, such machines won't resume correctly much of the time, > with the symptom being a 'port ready' timeout and/or a link training > failure. > > Note that simply asserting reset at suspend and de-asserting at resume > is not sufficient, nor is simply de-asserting at boot. Both of these > cases have been tested and have still been found to have failures on > some configurations. > > v2: extract simpler set_power_well function for use in reset_dpio (Imre) > move to reset_dpio (Daniel & Ville) > v3: don't reset if DPIO reset is already de-asserted (Imre) > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> The series matches my understanding of the limitations of the PHY, so: Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> But if these limitations are real, then I think we would also need to adjust the power domains to power up all the wells whenever even a single one is required. This should be testable I think by simply: 1. disable both ports 2. enable one port 3. enable the other port At step 3. the common well is already up, so the TX wells for the second port should come up in some kind of poor state. > --- > drivers/gpu/drm/i915/intel_display.c | 19 +++++++++++++++++++ > drivers/gpu/drm/i915/intel_drv.h | 3 ++- > drivers/gpu/drm/i915/intel_pm.c | 13 ++++++++++--- > 3 files changed, 31 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index df58afc..bdb4624 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -1509,6 +1509,25 @@ static void intel_reset_dpio(struct drm_device *dev) > > } else { > /* > + * If DPIO has already been reset, e.g. by BIOS, just skip all > + * this. > + */ > + if (I915_READ(DPIO_CTL) & DPIO_CMNRST) > + return; > + > + /* > + * From VLV2A0_DP_eDP_HDMI_DPIO_driver_vbios_notes_11.docx: > + * Need to assert and de-assert PHY SB reset by gating the > + * common lane power, then un-gating it. > + * Simply ungating isn't enough to reset the PHY enough to get > + * ports and lanes running. > + */ > + __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC, > + false); > + __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC, > + true); > + > + /* > * From VLV2A0_DP_eDP_DPIO_driver_vbios_notes_10.docx - > * 6. De-assert cmn_reset/side_reset. Same as VLV X0. > * a. GUnit 0x2110 bit[0] set to 1 (def 0) > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h > index 0ef2777..feb6165 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -966,7 +966,8 @@ void intel_runtime_pm_put(struct drm_i915_private *dev_priv); > void intel_init_runtime_pm(struct drm_i915_private *dev_priv); > void intel_fini_runtime_pm(struct drm_i915_private *dev_priv); > void ilk_wm_get_hw_state(struct drm_device *dev); > - > +void __vlv_set_power_well(struct drm_i915_private *dev_priv, > + enum punit_power_well power_well_id, bool enable); > > /* intel_sdvo.c */ > bool intel_sdvo_init(struct drm_device *dev, uint32_t sdvo_reg, bool is_sdvob); > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index b59e8ab..8f7dbb9 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -5724,10 +5724,9 @@ static bool i9xx_always_on_power_well_enabled(struct drm_i915_private *dev_priv, > return true; > } > > -static void vlv_set_power_well(struct drm_i915_private *dev_priv, > - struct i915_power_well *power_well, bool enable) > +void __vlv_set_power_well(struct drm_i915_private *dev_priv, > + enum punit_power_well power_well_id, bool enable) > { > - enum punit_power_well power_well_id = power_well->data; > u32 mask; > u32 state; > u32 ctrl; > @@ -5760,6 +5759,14 @@ out: > mutex_unlock(&dev_priv->rps.hw_lock); > } > > +static void vlv_set_power_well(struct drm_i915_private *dev_priv, > + struct i915_power_well *power_well, bool enable) > +{ > + enum punit_power_well power_well_id = power_well->data; > + > + __vlv_set_power_well(dev_priv, power_well_id, enable); > +} > + > static void vlv_power_well_sync_hw(struct drm_i915_private *dev_priv, > struct i915_power_well *power_well) > { > -- > 1.8.4.2 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, May 27, 2014 at 10:32:47PM +0300, Ville Syrjälä wrote: > On Fri, May 23, 2014 at 01:16:40PM -0700, Jesse Barnes wrote: > > This is a bit like the CMN reset de-assert we do in DPIO_CTL, except > > that it resets the whole common lane section of the PHY. This is > > required on machines where the BIOS doesn't do this for us on boot or > > resume to properly re-calibrate and get the PHY ready to transmit data. > > > > Without this patch, such machines won't resume correctly much of the time, > > with the symptom being a 'port ready' timeout and/or a link training > > failure. > > > > Note that simply asserting reset at suspend and de-asserting at resume > > is not sufficient, nor is simply de-asserting at boot. Both of these > > cases have been tested and have still been found to have failures on > > some configurations. > > > > v2: extract simpler set_power_well function for use in reset_dpio (Imre) > > move to reset_dpio (Daniel & Ville) > > v3: don't reset if DPIO reset is already de-asserted (Imre) > > > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > > The series matches my understanding of the limitations of the PHY, so: > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> All merged to dinq, thanks. > But if these limitations are real, then I think we would also need to > adjust the power domains to power up all the wells whenever even a > single one is required. > > This should be testable I think by simply: > 1. disable both ports > 2. enable one port > 3. enable the other port > > At step 3. the common well is already up, so the TX wells for the second > port should come up in some kind of poor state. Hm, if we need this we might forc a modeset for _all_ pipes on vlv, even for unchanged ports. At elast as long as we enable something new. That should make this work properly I hope. -Daniel
On Tue, May 27, 2014 at 10:24:14PM +0200, Daniel Vetter wrote: > On Tue, May 27, 2014 at 10:32:47PM +0300, Ville Syrjälä wrote: > > On Fri, May 23, 2014 at 01:16:40PM -0700, Jesse Barnes wrote: > > > This is a bit like the CMN reset de-assert we do in DPIO_CTL, except > > > that it resets the whole common lane section of the PHY. This is > > > required on machines where the BIOS doesn't do this for us on boot or > > > resume to properly re-calibrate and get the PHY ready to transmit data. > > > > > > Without this patch, such machines won't resume correctly much of the time, > > > with the symptom being a 'port ready' timeout and/or a link training > > > failure. > > > > > > Note that simply asserting reset at suspend and de-asserting at resume > > > is not sufficient, nor is simply de-asserting at boot. Both of these > > > cases have been tested and have still been found to have failures on > > > some configurations. > > > > > > v2: extract simpler set_power_well function for use in reset_dpio (Imre) > > > move to reset_dpio (Daniel & Ville) > > > v3: don't reset if DPIO reset is already de-asserted (Imre) > > > > > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > > > > The series matches my understanding of the limitations of the PHY, so: > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > All merged to dinq, thanks. > > > But if these limitations are real, then I think we would also need to > > adjust the power domains to power up all the wells whenever even a > > single one is required. > > > > This should be testable I think by simply: > > 1. disable both ports > > 2. enable one port > > 3. enable the other port > > > > At step 3. the common well is already up, so the TX wells for the second > > port should come up in some kind of poor state. > > Hm, if we need this we might forc a modeset for _all_ pipes on vlv, even > for unchanged ports. At elast as long as we enable something new. That > should make this work properly I hope. Yeah that would work too, but obviously would cause some blinking that might be a bit disturbing. But we may have such blinking already due to adjusting cdclk. If the blinking is disturbing for users we might want to have a knob for controlling it: either use less power but blink more, or waste a bit of power and blink less. But I don't know if anyone would really want to waste power.
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index df58afc..bdb4624 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1509,6 +1509,25 @@ static void intel_reset_dpio(struct drm_device *dev) } else { /* + * If DPIO has already been reset, e.g. by BIOS, just skip all + * this. + */ + if (I915_READ(DPIO_CTL) & DPIO_CMNRST) + return; + + /* + * From VLV2A0_DP_eDP_HDMI_DPIO_driver_vbios_notes_11.docx: + * Need to assert and de-assert PHY SB reset by gating the + * common lane power, then un-gating it. + * Simply ungating isn't enough to reset the PHY enough to get + * ports and lanes running. + */ + __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC, + false); + __vlv_set_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC, + true); + + /* * From VLV2A0_DP_eDP_DPIO_driver_vbios_notes_10.docx - * 6. De-assert cmn_reset/side_reset. Same as VLV X0. * a. GUnit 0x2110 bit[0] set to 1 (def 0) diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 0ef2777..feb6165 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -966,7 +966,8 @@ void intel_runtime_pm_put(struct drm_i915_private *dev_priv); void intel_init_runtime_pm(struct drm_i915_private *dev_priv); void intel_fini_runtime_pm(struct drm_i915_private *dev_priv); void ilk_wm_get_hw_state(struct drm_device *dev); - +void __vlv_set_power_well(struct drm_i915_private *dev_priv, + enum punit_power_well power_well_id, bool enable); /* intel_sdvo.c */ bool intel_sdvo_init(struct drm_device *dev, uint32_t sdvo_reg, bool is_sdvob); diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index b59e8ab..8f7dbb9 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -5724,10 +5724,9 @@ static bool i9xx_always_on_power_well_enabled(struct drm_i915_private *dev_priv, return true; } -static void vlv_set_power_well(struct drm_i915_private *dev_priv, - struct i915_power_well *power_well, bool enable) +void __vlv_set_power_well(struct drm_i915_private *dev_priv, + enum punit_power_well power_well_id, bool enable) { - enum punit_power_well power_well_id = power_well->data; u32 mask; u32 state; u32 ctrl; @@ -5760,6 +5759,14 @@ out: mutex_unlock(&dev_priv->rps.hw_lock); } +static void vlv_set_power_well(struct drm_i915_private *dev_priv, + struct i915_power_well *power_well, bool enable) +{ + enum punit_power_well power_well_id = power_well->data; + + __vlv_set_power_well(dev_priv, power_well_id, enable); +} + static void vlv_power_well_sync_hw(struct drm_i915_private *dev_priv, struct i915_power_well *power_well) {
This is a bit like the CMN reset de-assert we do in DPIO_CTL, except that it resets the whole common lane section of the PHY. This is required on machines where the BIOS doesn't do this for us on boot or resume to properly re-calibrate and get the PHY ready to transmit data. Without this patch, such machines won't resume correctly much of the time, with the symptom being a 'port ready' timeout and/or a link training failure. Note that simply asserting reset at suspend and de-asserting at resume is not sufficient, nor is simply de-asserting at boot. Both of these cases have been tested and have still been found to have failures on some configurations. v2: extract simpler set_power_well function for use in reset_dpio (Imre) move to reset_dpio (Daniel & Ville) v3: don't reset if DPIO reset is already de-asserted (Imre) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- drivers/gpu/drm/i915/intel_display.c | 19 +++++++++++++++++++ drivers/gpu/drm/i915/intel_drv.h | 3 ++- drivers/gpu/drm/i915/intel_pm.c | 13 ++++++++++--- 3 files changed, 31 insertions(+), 4 deletions(-)