On Fri, Feb 23, 2024 at 10:32:15PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>
> The icl+ power well code currently assumes that every AUX power
> well maps to an encoder which is using said power well. That is
> by no menas guaranteed as we:
> - only register encoders for ports declared in the VBT
> - combo PHY HDMI-only encoder no longer get an AUX CH since
> commit 9856308c94ca ("drm/i915: Only populate aux_ch if really needed")
>
> However we have places such as intel_power_domains_sanitize_state()
> that blindly traverse all the possible power wells. So these bits
> of code may very well encounbter an aux power well with no associated
> encoder.
>
> In this particular case the BIOS seems to have left one AUX power
> well enabled even though we're dealing with a HDMI only encoder
> on a combo PHY. We then proceed to turn off said power well and
> explode when we can't find a matching encoder. As a short term fix
> we should be able to just skip the PHY related parts of the power
> well programming since we know this situation can only happen with
> combo PHYs.
>
> Another option might be to go back to always picking an AUX CH for
> all encoders. However I'm a bit wary about that since we might in
> theory end up conflicting with the VBT AUX CH assignment. Also
> that wouldn't help with encoders not declared in the VBT, should
> we ever need to poke the corresponding power wells.
>
> Longer term we need to figure out what the actual relationship
> is between the PHY vs. AUX CH vs. AUX power well. Currently this
> is entirely unclear.
This is unspecified, so the only way would be to test an actual platform
with an alternative AUX CH VBT setting (on a DDI platform). My current
assumption is that this alternative AUX CH determines:
- The AUX power well to be enabled for an AUX transfer
- The AUX CH data/ctl registers to be used for an AUX transfer
Otoh, for the (overloaded) power control for the main lane functionality
it is not the alternative AUX CH power well, rather the given DDIs
direct mapped/own AUX CH power well what would be required. The driver
doesn't make a distinction in this now, since it's unspecified. I think
cross connecting AUX CHs wouldn't really work on DDI platforms for this
reason (at least on TC DDIs/PHYs/AUX CHs).
For the PHY workarounds which are part of the AUX power well programming
sequence, it is the PHY connected to the given DDI (so not affected by
any alternative AUX CH setting), which needs to be programmed. As above
this is also unspeficied, so just my assumption.
> Cc: stable@xxxxxxxxxxxxxxx
> Fixes: 9856308c94ca ("drm/i915: Only populate aux_ch if really needed")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10184
> Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> ---
> .../drm/i915/display/intel_display_power_well.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> index 47cd6bb04366..06900ff307b2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> @@ -246,7 +246,14 @@ static enum phy icl_aux_pw_to_phy(struct drm_i915_private *i915,
> enum aux_ch aux_ch = icl_aux_pw_to_ch(power_well);
> struct intel_digital_port *dig_port = aux_ch_to_digital_port(i915, aux_ch);
>
> - return intel_port_to_phy(i915, dig_port->base.port);
> + /*
> + * FIXME should we care about the (VBT defined) dig_port->aux_ch
> + * relationship or should this be purely defined by the hardware layout?
> + * Currently if the port doesn't appear in the VBT, or if it's declared
> + * as HDMI-only and routed to a combo PHY, the encoder either won't be
> + * present at all or it will not have an aux_ch assigned.
> + */
> + return dig_port ? intel_port_to_phy(i915, dig_port->base.port) : PHY_NONE;
Yes, if it's not known which PHY is used in connection with an AUX CH
(which in theory could be remapped via VBT), then the WA can't be
applied either; so on both patches:
Reviewed-by: Imre Deak <imre.deak@xxxxxxxxx>
> }
>
> static void hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
> @@ -414,7 +421,8 @@ icl_combo_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
>
> intel_de_rmw(dev_priv, regs->driver, 0, HSW_PWR_WELL_CTL_REQ(pw_idx));
>
> - if (DISPLAY_VER(dev_priv) < 12)
> + /* FIXME this is a mess */
> + if (phy != PHY_NONE)
> intel_de_rmw(dev_priv, ICL_PORT_CL_DW12(phy),
> 0, ICL_LANE_ENABLE_AUX);
>
> @@ -437,7 +445,10 @@ icl_combo_phy_aux_power_well_disable(struct drm_i915_private *dev_priv,
>
> drm_WARN_ON(&dev_priv->drm, !IS_ICELAKE(dev_priv));
>
> - intel_de_rmw(dev_priv, ICL_PORT_CL_DW12(phy), ICL_LANE_ENABLE_AUX, 0);
> + /* FIXME this is a mess */
> + if (phy != PHY_NONE)
> + intel_de_rmw(dev_priv, ICL_PORT_CL_DW12(phy),
> + ICL_LANE_ENABLE_AUX, 0);
>
> intel_de_rmw(dev_priv, regs->driver, HSW_PWR_WELL_CTL_REQ(pw_idx), 0);
>
> --
> 2.43.0
>
