[Intel-gfx] [Intel-xe] [PATCH 27/42] drm/i915/xe2lpd: Read pin assignment from IOM

Coelho, Luciano luciano.coelho at intel.com
Thu Aug 24 11:31:45 UTC 2023


On Wed, 2023-08-23 at 13:28 -0700, Matt Roper wrote:
> On Wed, Aug 23, 2023 at 10:07:25AM -0700, Lucas De Marchi wrote:
> > From: Luca Coelho <luciano.coelho at intel.com>
> > 
> > Starting from display version 20, we need to read the pin assignment
> > from the IOM TCSS_DDI_STATUS register instead of reading it from the
> > FIA.
> > 
> > We use the pin assignment to decide the maximum lane count.  So, to
> > support this change, add a new lnl_tc_port_get_max_lane_count() function
> > that reads from the TCSS_DDI_STATUS register and decides the maximum
> > lane count based on that.
> > 
> > BSpec: 69594
> > Cc: Mika Kahola <mika.kahola at intel.com>
> > Signed-off-by: Luca Coelho <luciano.coelho at intel.com>
> > Signed-off-by: Lucas De Marchi <lucas.demarchi at intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_tc.c | 28 +++++++++++++++++++++++++
> >  drivers/gpu/drm/i915/i915_reg.h         |  1 +
> >  2 files changed, 29 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c
> > index 3c94bbcb5497..37b0f8529b4f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -290,6 +290,31 @@ u32 intel_tc_port_get_pin_assignment_mask(struct intel_digital_port *dig_port)
> >  	       DP_PIN_ASSIGNMENT_SHIFT(tc->phy_fia_idx);
> >  }
> >  
> > +static int lnl_tc_port_get_max_lane_count(struct intel_digital_port *dig_port)
> > +{
> > +	struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > +	enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> > +	intel_wakeref_t wakeref;
> > +	u32 val, pin_assignment;
> > +
> > +	with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> 
> Do we need this?  I don't think POWER_DOMAIN_DISPLAY_CORE has been tied
> to any power wells since VLV/CHV.
> 
> Hmm, it looks like we actually grab it (and even assert it) in a bunch of
> places on modern platforms that don't make sense to me since it isn't
> tied to anything.
> 
> I guess leaving this here doesn't hurt anything, although we might want
> to go back and take another look at this in the future.
> 
> Reviewed-by: Matt Roper <matthew.d.roper at intel.com>

Thanks, Matt! You have a good point, but as you said, maybe this should
be revisited in all occurrences and changed in one go.  I just kept it
consistent with other usage.

--
Cheers,
Luca.


More information about the Intel-gfx mailing list