[Intel-gfx] [PATCH] drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (v3)

Vivek Kasireddy vivek.kasireddy at intel.com
Tue Feb 4 22:56:15 UTC 2020


On Fri, 31 Jan 2020 11:35:35 +0200
Jani Nikula <jani.nikula at intel.com> wrote:
Hi Jani,

> On Thu, 30 Jan 2020, Vivek Kasireddy <vivek.kasireddy at intel.com>
> wrote:
> > On some platforms such as Elkhart Lake, although we may use DDI D
> > to drive a connector, we have to use PHY A (Combo Phy PORT A) to
> > detect the hotplug interrupts as per the spec because there is no
> > one-to-one mapping between DDIs and PHYs. Therefore, use the
> > function intel_port_to_phy() which contains the logic for such
> > mapping(s) to find the correct hpd_pin.
> >
> > This change should not affect other platforms as there is always
> > a one-to-one mapping between DDIs and PHYs.
> >
> > v2:
> > - Convert the case statements to use PHYs instead of PORTs (Jani)
> >
> > v3:
> > - Refactor the function to reduce the number of return statements by
> >   lumping all the case statements together except PHY_F which needs
> >   special handling (Jose)
> >
> > Cc: Jani Nikula <jani.nikula at intel.com>
> > Cc: Matt Roper <matthew.d.roper at intel.com>
> > Cc: José Roberto de Souza <jose.souza at intel.com>
> > Signed-off-by: Vivek Kasireddy <vivek.kasireddy at intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_hotplug.c | 37
> > ++++++++------------ 1 file changed, 15 insertions(+), 22
> > deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> > b/drivers/gpu/drm/i915/display/intel_hotplug.c index
> > 042d98bae1ea..27e3033278a0 100644 ---
> > a/drivers/gpu/drm/i915/display/intel_hotplug.c +++
> > b/drivers/gpu/drm/i915/display/intel_hotplug.c @@ -89,29 +89,22 @@
> >  enum hpd_pin intel_hpd_pin_default(struct drm_i915_private
> > *dev_priv, enum port port)
> >  {
> > -	switch (port) {
> > -	case PORT_A:
> > -		return HPD_PORT_A;
> > -	case PORT_B:
> > -		return HPD_PORT_B;
> > -	case PORT_C:
> > -		return HPD_PORT_C;
> > -	case PORT_D:
> > -		return HPD_PORT_D;
> > -	case PORT_E:
> > -		return HPD_PORT_E;
> > -	case PORT_F:
> > -		if (IS_CNL_WITH_PORT_F(dev_priv))
> > -			return HPD_PORT_E;
> > -		return HPD_PORT_F;
> > -	case PORT_G:
> > -		return HPD_PORT_G;
> > -	case PORT_H:
> > -		return HPD_PORT_H;
> > -	case PORT_I:
> > -		return HPD_PORT_I;
> > +	enum phy phy = intel_port_to_phy(dev_priv, port);
> > +
> > +	switch (phy) {
> > +	case PHY_F:
> > +		return IS_CNL_WITH_PORT_F(dev_priv) ? HPD_PORT_E :
> > HPD_PORT_F;
> > +	case PHY_A:
> > +	case PHY_B:
> > +	case PHY_C:
> > +	case PHY_D:
> > +	case PHY_E:
> > +	case PHY_G:
> > +	case PHY_H:
> > +	case PHY_I:
> > +		return HPD_PORT_A + phy;  
> 
> I know José asked you to do this, but now you've tied two enum
> sequences together without explaining it anywhere. Before this,
> AFAICT, enum hpd_pin was just an abstract enumeration where the
> actual values of the enums didn't mean a thing, apart from 0 for
> HPD_NONE.
> 
> Maybe this is what we want to do, but we should never be so casual
> about it.
Do you suggest that I explain this in the description associated
with v3 that we now have a switch/case fallthrough in this function?
Or, do you want me to send a v4 to include this in a comment?

Thanks,
Vivek

> 
> 
> BR,
> Jani.
> 
> 
> >  	default:
> > -		MISSING_CASE(port);
> > +		MISSING_CASE(phy);
> >  		return HPD_NONE;
> >  	}
> >  }  
> 



More information about the Intel-gfx mailing list