Re: [Intel-gfx] [PATCH v3 07/15] drm/i915/rkl: Update TGP's pin mapping when paired with RKL

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Jun 04, 2020 at 04:18:49PM -0700, Matt Roper wrote:
> On Thu, Jun 04, 2020 at 09:29:19PM +0300, Ville Syrjälä wrote:
> > On Wed, Jun 03, 2020 at 02:15:21PM -0700, Matt Roper wrote:
> > > When TGP is paired with RKL it uses a different HPD pin mapping than
> > > when paired with TGL.
> > > 
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_irq.c | 15 ++++++++++++++-
> > >  1 file changed, 14 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > > index 490574669eaa..f3ea81a17352 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -167,6 +167,17 @@ static const u32 hpd_tgp[HPD_NUM_PINS] = {
> > >  	[HPD_PORT_I] = SDE_TC_HOTPLUG_ICP(PORT_TC6),
> > >  };
> > >  
> > > +/*
> > > + * TGP when paired with RKL has different pin mappings than when paired
> > > + * with TGL.
> > > + */
> > > +static const u32 hpd_rkl_tgp[HPD_NUM_PINS] = {
> > > +	[HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(PORT_A),
> > > +	[HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(PORT_B),
> > > +	[HPD_PORT_C] = SDE_TC_HOTPLUG_ICP(PORT_TC1),
> > > +	[HPD_PORT_D] = SDE_TC_HOTPLUG_ICP(PORT_TC2),
> > > +};
> > 
> > Hmm. So basically it looks like we'd want to pick the hpd_pin
> > based on the DDI rather than the PHY on this platform?
> 
> I may be misinterpreting the table on bspec 49181, but I *think* it
> looks like we use the DDI when paired with a TGP PCH and the PHY when
> paired with CMP PCH.  So if I just set the hpd_pin based on the DDI,
> then I think that will break the CMP-based systems (although I haven't
> tested on one of those, so I'm not 100% sure).

After staring at the spec+code a bit I think what I want to
do is introduce proper HPD_PORT_TC1-6 enums (and remove
HPD_PORT_F+ since they become unused).

In the meantime I think assigning hpd_pin in a custom way
for rkl only should work.

> 
> 
> Matt
> 
> > 
> > OK, I guess we need to remap somehow. The question is
> > whether we want to do it before or after selecting hpd_pin...
> > I think we would want to do it before, as otherwise the
> > long_detect() stuff won't work right AFAICS. Or am I
> > missing something?
> > 
> > Side note: we should probably convert the long_detect()
> > switches to arrays just like we have for the isr bits here.
> > Would potentially avoid having to touch that code every time
> > they tweak these thinhs in hw.
> > 
> > And in fact it looks like icp already has all the same hpd
> > pins as tgp, so I'm thinking we should just s/hpd_tgp/hpd_icp/
> > and for icl/jsl we should remap hpd_pin as well. Oh and the
> > mcc case would just need a slightly different mapping of
> > port C -> HPD_PORT_D (aka. tc1).
> > 
> > This way all the hpd[] arrays and whatnot would just be based
> > on the actual pch type and not based on what it happens to be
> > paired with.
> > 
> > Anwyays, most of that is out of scope for this rkl stuff, so
> > I guess for now just add a bit of logic to remap hpd_pin for rkl?
> > 
> > > +
> > >  static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
> > >  {
> > >  	struct i915_hotplug *hpd = &dev_priv->hotplug;
> > > @@ -196,7 +207,9 @@ static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
> > >  	if (!HAS_PCH_SPLIT(dev_priv) || HAS_PCH_NOP(dev_priv))
> > >  		return;
> > >  
> > > -	if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
> > > +	if (HAS_PCH_TGP(dev_priv) && IS_ROCKETLAKE(dev_priv))
> > > +		hpd->pch_hpd = hpd_rkl_tgp;
> > > +	else if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
> > >  		hpd->pch_hpd = hpd_tgp;
> > >  	else if (HAS_PCH_ICP(dev_priv) || HAS_PCH_MCC(dev_priv))
> > >  		hpd->pch_hpd = hpd_icp;
> > > -- 
> > > 2.24.1
> > 
> > -- 
> > Ville Syrjälä
> > Intel
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx