Re: [Intel-gfx] [PATCH v8 1/1] drm/drm_mst: Use Extended Base Receiver Capability DPCD space

[Jani Nikula <jani.nikula@linux.intel.com>]

On Wed, 28 Apr 2021, Nikola Cornij <nikola.cornij@amd.com> wrote:
> [why]
> DP 1.4a spec madates that if DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is
> set, Extended Base Receiver Capability DPCD space must be used. Without
> doing that, the three DPCD values that differ will be wrong, leading to
> incorrect or limited functionality. MST link rate, for example, could
> have a lower value. Also, Synaptics quirk wouldn't work out well when
> Extended DPCD was not read, resulting in no DSC for such hubs.
>
> [how]
> Modify MST topology manager to use the values from Extended DPCD where
> applicable.
>
> To prevent regression on the sources that have a lower maximum link rate
> capability than MAX_LINK_RATE from Extended DPCD, have the drivers
> supply maximum lane count and rate at initialization time.
>
> This also reverts 'commit 2dcab875e763 ("Revert drm/dp_mst: Retrieve
> extended DPCD caps for topology manager")', brining the change back to
> the original 'commit ad44c03208e4 ("drm/dp_mst: Retrieve extended DPCD
> caps for topology manager")'.
>
> Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
> ---
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  5 +++
>  .../gpu/drm/amd/display/dc/core/dc_link_dp.c  | 18 ++++++++++
>  drivers/gpu/drm/amd/display/dc/dc_link.h      |  2 ++
>  drivers/gpu/drm/drm_dp_mst_topology.c         | 33 ++++++++++++-------
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  6 +++-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c       |  3 +-
>  drivers/gpu/drm/radeon/radeon_dp_mst.c        |  7 ++++
>  include/drm/drm_dp_mst_helper.h               | 12 ++++++-
>  8 files changed, 71 insertions(+), 15 deletions(-)


> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 860381d68d9d..a4245eb48ef4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -942,6 +942,7 @@ intel_dp_mst_encoder_init(struct intel_digital_port *dig_port, int conn_base_id)
>  	struct intel_dp *intel_dp = &dig_port->dp;
>  	enum port port = dig_port->base.port;
>  	int ret;
> +	int bios_max_link_rate;
>  
>  	if (!HAS_DP_MST(i915) || intel_dp_is_edp(intel_dp))
>  		return 0;
> @@ -956,8 +957,11 @@ intel_dp_mst_encoder_init(struct intel_digital_port *dig_port, int conn_base_id)
>  
>  	/* create encoders */
>  	intel_dp_create_fake_mst_encoders(dig_port);
> +	bios_max_link_rate = intel_bios_dp_max_link_rate(&dig_port->base);

Wait, what? This can return 0, and usually does. This is an optional
limitation, and is generally only used if there's a need to have a
smaller max link rate than the max the platform supports. We call this
in one single place, and are not looking to add another call site.

I haven't had my doze of coffee this morning, but at a glance, I think
this will break MST for most i915 users.

See intel_dp->source_rates[] and intel_dp->num_source_rates for all the
rates the source supports, initialized at encoder
init. intel_dp->source_rates[intel_dp->num_source_rates - 1] would be
the max.

Also, I suggest using kHz for rates throughout, and specifically not the
DPCD "units". Otherwise, this is just another thing that needs fixing
with the DP 2.0 UHBR rates where the bandwidth codes don't follow the
same pattern.

Ten versions of the patch, with a benign looking subject, and none of
the i915 maintainers in Cc. Not cool.


BR,
Jani.


>  	ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, &i915->drm,
> -					   &intel_dp->aux, 16, 3, conn_base_id);
> +					   &intel_dp->aux, 16, 3,
> +					   dig_port->max_lanes,
> +					   bios_max_link_rate / 27000, conn_base_id);
>  	if (ret)
>  		return ret;
>  

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel