From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/6] drm/i915/dp: Ensure sink/link max lane count values are always valid
Date: Mon, 18 Oct 2021 18:04:18 +0300 [thread overview]
Message-ID: <YW2M8h02rslxYBSO@intel.com> (raw)
In-Reply-To: <20211018094154.1407705-5-imre.deak@intel.com>
On Mon, Oct 18, 2021 at 12:41:52PM +0300, Imre Deak wrote:
> Print an error if the DPCD sink max lane count is invalid and fix it up.
>
> While at it also add an assert that the link max lane count (derived
> from intel_dp_max_common_lane_count(), potentially reduced by the LT
> fallback logic) value is also valid.
>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> ---
> .../drm/i915/display/intel_display_types.h | 2 +
> drivers/gpu/drm/i915/display/intel_dp.c | 44 ++++++++++++++++++-
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 39e11eaec1a3f..1e42bf901263c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1563,6 +1563,8 @@ struct intel_dp {
> int num_sink_rates;
> int sink_rates[DP_MAX_SUPPORTED_RATES];
> bool use_rate_select;
> + /* Max sink lane count as reported by DP_MAX_LANE_COUNT */
> + int max_sink_lane_count;
> /* intersection of source and sink rates */
> int num_common_rates;
> int common_rates[DP_MAX_SUPPORTED_RATES];
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1935eb49f9574..f7711779df132 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -197,6 +197,35 @@ static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
> intel_dp->num_sink_rates = i;
> }
>
> +static void intel_dp_set_default_max_sink_lane_count(struct intel_dp *intel_dp)
> +{
> + intel_dp->max_sink_lane_count = 1;
> +}
> +
> +static void intel_dp_set_max_sink_lane_count(struct intel_dp *intel_dp)
> +{
> + struct intel_connector *connector = intel_dp->attached_connector;
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct intel_encoder *encoder = &intel_dig_port->base;
> +
> + intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> +
> + switch (intel_dp->max_sink_lane_count) {
> + case 1:
> + case 2:
> + case 4:
> + return;
> + }
> +
> + drm_err(&dp_to_i915(intel_dp)->drm,
> + "[CONNECTOR:%d:%s][ENCODER:%d:%s] Invalid DPCD max lane count (%d), using default\n",
> + connector->base.base.id, connector->base.name,
> + encoder->base.base.id, encoder->base.name,
> + intel_dp->max_sink_lane_count);
> +
> + intel_dp_set_default_max_sink_lane_count(intel_dp);
> +}
> +
> /* Get length of rates array potentially limited by max_rate. */
> static int intel_dp_rate_limit_len(const int *rates, int len, int max_rate)
> {
> @@ -230,7 +259,7 @@ static int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
> {
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> int source_max = dig_port->max_lanes;
> - int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
> + int sink_max = intel_dp->max_sink_lane_count;
> int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
> int lttpr_max = drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
>
> @@ -242,7 +271,15 @@ static int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
>
> int intel_dp_max_lane_count(struct intel_dp *intel_dp)
> {
> - return intel_dp->max_link_lane_count;
> + switch (intel_dp->max_link_lane_count) {
> + case 1:
> + case 2:
> + case 4:
> + return intel_dp->max_link_lane_count;
> + default:
> + MISSING_CASE(intel_dp->max_link_lane_count);
> + return 1;
> + }
> }
I guess this is just a second level sanity check. I was wondering it
gets confusing and people start thinking this can actually happen,
but I suppose the MISSING_CASE() should be indication enough that it
in fact should not happen.
Series looks sane to me:
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
BTW there's now some kms_bw thing in igt which seems to forcing
DP connectors on left and right, and thus triggering a bunch of
WARNs.
>
> /*
> @@ -2600,6 +2637,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> intel_dp->use_rate_select = true;
> else
> intel_dp_set_sink_rates(intel_dp);
> + intel_dp_set_max_sink_lane_count(intel_dp);
>
> intel_dp_set_common_rates(intel_dp);
> intel_dp_reset_max_link_params(intel_dp);
> @@ -2645,6 +2683,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> drm_dp_is_branch(intel_dp->dpcd));
>
> intel_dp_set_sink_rates(intel_dp);
> + intel_dp_set_max_sink_lane_count(intel_dp);
> intel_dp_set_common_rates(intel_dp);
> }
>
> @@ -5011,6 +5050,7 @@ intel_dp_init_connector(struct intel_digital_port *dig_port,
>
> intel_dp_set_source_rates(intel_dp);
> intel_dp_set_default_sink_rates(intel_dp);
> + intel_dp_set_default_max_sink_lane_count(intel_dp);
> intel_dp_set_common_rates(intel_dp);
> intel_dp_reset_max_link_params(intel_dp);
>
> --
> 2.27.0
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2021-10-18 15:04 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-18 9:41 [Intel-gfx] [PATCH 0/6] drm/i915/dp: Fix link parameter use in lack of a valid DPCD Imre Deak
2021-10-18 9:41 ` [Intel-gfx] [PATCH 1/6] drm/i915/dp: Skip the HW readout of DPCD on disabled encoders Imre Deak
2021-10-18 9:41 ` [Intel-gfx] [PATCH 2/6] drm/i915/dp: Ensure sink rate values are always valid Imre Deak
2021-10-18 14:34 ` [Intel-gfx] [PATCH v2 " Imre Deak
2021-10-19 7:27 ` [Intel-gfx] [PATCH " Jani Nikula
2021-10-19 7:33 ` Imre Deak
2021-10-19 7:37 ` Jani Nikula
2021-10-19 7:39 ` Imre Deak
2021-10-19 18:37 ` Imre Deak
2021-10-19 19:17 ` Jani Nikula
2021-10-18 9:41 ` [Intel-gfx] [PATCH 3/6] drm/i915/dp: Ensure max link params " Imre Deak
2021-10-18 9:41 ` [Intel-gfx] [PATCH 4/6] drm/i915/dp: Ensure sink/link max lane count values " Imre Deak
2021-10-18 15:04 ` Ville Syrjälä [this message]
2021-10-18 15:13 ` Imre Deak
2021-10-18 15:27 ` Ville Syrjälä
2021-10-18 9:41 ` [Intel-gfx] [PATCH 5/6] drm/i915/dp: Sanitize sink rate DPCD register values Imre Deak
2021-10-18 9:41 ` [Intel-gfx] [PATCH 6/6] drm/i915/dp: Sanitize link common rate array lookups Imre Deak
2021-10-19 19:23 ` Jani Nikula
2021-10-20 9:06 ` Imre Deak
2021-10-20 9:53 ` Jani Nikula
2021-10-20 10:09 ` Ville Syrjälä
2021-10-18 12:31 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Fix link parameter use in lack of a valid DPCD Patchwork
2021-10-18 12:33 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-18 13:06 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-10-18 18:01 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Fix link parameter use in lack of a valid DPCD (rev2) Patchwork
2021-10-18 18:03 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-18 18:31 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-10-19 0:52 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-10-19 12:54 ` Imre Deak
2021-10-19 15:33 ` Vudum, Lakshminarayana
2021-10-19 16:32 ` Imre Deak
2021-10-19 14:45 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
2021-10-20 15:40 ` Imre Deak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YW2M8h02rslxYBSO@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox