[Intel-gfx] [PATCH 6/6] drm/i915/dp_mst: Ensure the DPCD ACT sent flag is cleared before waiting for it

Imre Deak imre.deak at intel.com
Tue Jun 16 16:47:53 UTC 2020


On Tue, Jun 16, 2020 at 07:40:47PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 16, 2020 at 07:23:21PM +0300, Ville Syrjälä wrote:
> > On Tue, Jun 16, 2020 at 06:54:41PM +0300, Imre Deak wrote:
> > > On Tue, Jun 16, 2020 at 06:45:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Jun 16, 2020 at 05:18:55PM +0300, Imre Deak wrote:
> > > > > Atm, we clear the ACT sent flag in the sink's DPCD before updating the
> > > > > sink's payload table, along clearing the payload table updated flag.
> > > > > The sink is supposed to set this flag once it detects that the source
> > > > > has completed the ACT sequence (after detecting the 4 required ACT MTPH
> > > > > symbols sent by the source). As opposed to this 2 DELL monitors I have
> > > > > set the flag already along the payload table updated flag, which is not
> > > > > quite correct.
> > > > > 
> > > > > To be sure that the sink has detected the ACT MTPH symbols before
> > > > > continuing enabling the encoder, clear the ACT sent flag before enabling
> > > > > or disabling the transcoder VC payload allocation (which is what starts
> > > > > the ACT sequence).
> > > > > 
> > > > > Cc: Lyude Paul <lyude at redhat.com>
> > > > > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > Cc: dri-devel at lists.freedesktop.org
> > > > > Signed-off-by: Imre Deak <imre.deak at intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/drm_dp_mst_topology.c       | 31 +++++++++++++++++++--
> > > > >  drivers/gpu/drm/i915/display/intel_dp_mst.c |  2 ++
> > > > >  include/drm/drm_dp_mst_helper.h             |  2 ++
> > > > >  3 files changed, 33 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > index b2f5a84b4cfb..e3bf8c9c8267 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > @@ -4377,6 +4377,34 @@ void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr,
> > > > >  }
> > > > >  EXPORT_SYMBOL(drm_dp_mst_deallocate_vcpi);
> > > > >  
> > > > > +/**
> > > > > + * drm_dp_clear_payload_status() - Clears the payload table status flags
> > > > > + * @mgr: manager to use
> > > > > + *
> > > > > + * Clears the payload table ACT handled and table updated flags in the MST hub's
> > > > > + * DPCD. This function must be called before updating the payload table or
> > > > > + * starting the ACT sequence and waiting for the corresponding flags to get
> > > > > + * set by the hub.
> > > > > + *
> > > > > + * Returns:
> > > > > + * 0 if the flag got cleared successfully, otherwise a negative error code.
> > > > > + */
> > > > > +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr)
> > > > > +{
> > > > > +	int ret;
> > > > > +
> > > > > +	ret = drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > > > > +				 DP_PAYLOAD_ACT_HANDLED);
> > > > > +	if (ret < 0) {
> > > > > +		DRM_DEBUG_DRIVER("Can't clear the ACT sent flag (%d)\n", ret);
> > > > > +		return ret;
> > > > > +	}
> > > > > +	WARN_ON(ret != 1);
> > > > > +
> > > > > +	return 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_dp_clear_payload_status);
> > > > > +
> > > > >  static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> > > > >  				     int id, struct drm_dp_payload *payload)
> > > > >  {
> > > > > @@ -4384,8 +4412,7 @@ static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> > > > >  	int ret;
> > > > >  	int retries = 0;
> > > > >  
> > > > > -	drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS,
> > > > > -			   DP_PAYLOAD_TABLE_UPDATED);
> > > > 
> > > > We used to clear DP_PAYLOAD_TABLE_UPDATED but now we clear
> > > > DP_PAYLOAD_ACT_HANDLED ?
> > > 
> > > Eek. We should write DP_PAYLOAD_TABLE_UPDATED which is the only way to
> > > clear both the act-handled and the table-updated flags.
> > 
> > Huh. That's a bit crazy. But it is what the spec says.
> 
> In fact, I'd suggest adding a comment explaining this crazyness
> so that the next person doesn't have to wonder why we're never
> clearing the ACT bit.

Ok.

> 
> > 
> > > I tested things
> > > that way but managed to send an old version. Thanks for catching it.
> > > 
> > > > 
> > > > > +	drm_dp_clear_payload_status(mgr);
> > > > >  
> > > > >  	payload_alloc[0] = id;
> > > > >  	payload_alloc[1] = payload->start_slot;
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > index 9308b5920780..3c4b0fb10d8b 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > @@ -323,6 +323,8 @@ static void clear_act_sent(struct intel_dp *intel_dp)
> > > > >  
> > > > >  	intel_de_write(i915, intel_dp->regs.dp_tp_status,
> > > > >  		       DP_TP_STATUS_ACT_SENT);
> > > > > +
> > > > > +	drm_dp_clear_payload_status(&intel_dp->mst_mgr);
> > > > >  }
> > > > >  
> > > > >  static void wait_for_act_sent(struct intel_dp *intel_dp)
> > > > > diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> > > > > index 8b9eb4db3381..2facb87624bf 100644
> > > > > --- a/include/drm/drm_dp_mst_helper.h
> > > > > +++ b/include/drm/drm_dp_mst_helper.h
> > > > > @@ -763,6 +763,8 @@ int drm_dp_find_vcpi_slots(struct drm_dp_mst_topology_mgr *mgr,
> > > > >  			   int pbn);
> > > > >  
> > > > >  
> > > > > +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr);
> > > > > +
> > > > >  int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr);
> > > > >  
> > > > >  
> > > > > -- 
> > > > > 2.23.1
> > > > 
> > > > -- 
> > > > Ville Syrjälä
> > > > Intel
> > 
> > -- 
> > Ville Syrjälä
> > Intel
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel


More information about the Intel-gfx mailing list