All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Animesh Manna" <animesh.manna@intel.com>
Cc: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v6 12/18] drm/i915/alpm: Program LTTPR count for DP 2.1 ALPM
Date: Tue, 15 Sep 2026 18:56:27 +0000	[thread overview]
Message-ID: <20260915185628.790771F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260915180449.277933-13-animesh.manna@intel.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] drm/i915/alpm: DP 2.1 ALPM LTTPR logic is unreachable dead code
- [Medium] drm/i915/alpm: Unchecked negative return from drm_dp_lttpr_count() causes register corruption
- [Low] drm/i915/alpm: Dead code in lttpr_count error check
- [Low] drm/i915/alpm: Comment contradicts LTTPR revision code check
--

commit a317ca0f7af6803f7b3932311f82447dfda1b648
Author: Animesh Manna <animesh.manna@intel.com>
drm/i915/alpm: Program LTTPR count for DP 2.1 ALPM

This commit programs the total number of LTTPRs for DP 2.1 ALPM before
link training by issuing an AUX write transaction to DP_TOTAL_LTTPR_CNT.

> diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c
> index da653a407e97e..06c1a59aa2c51 100644
> --- a/drivers/gpu/drm/i915/display/intel_alpm.c
> +++ b/drivers/gpu/drm/i915/display/intel_alpm.c
> @@ -726,7 +726,7 @@ static void lnl_alpm_configure(struct intel_dp *intel_dp,
>  {
>  	struct intel_display *display = to_intel_display(intel_dp);
>  	enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> -	u32 alpm_ctl;
> +	u32 alpm_ctl, alpm_ctl2, lttpr_count;
>  
[ ... ]
> @@ -762,6 +762,11 @@ static void lnl_alpm_configure(struct intel_dp *intel_dp,
>  
>  	alpm_ctl |= ALPM_CTL_ALPM_ENTRY_CHECK(crtc_state->alpm_state.check_entry_lines);
>  
> +	lttpr_count = drm_dp_lttpr_count(intel_dp->lttpr_common_caps);
> +
> +	alpm_ctl2 = ALPM_CTL2_NUMBER_OF_LTTPR(lttpr_count);

[Severity: Medium]
Does this assignment to a u32 variable cause error codes to go unhandled?

The function drm_dp_lttpr_count() can return negative error codes like
-ERANGE or -EINVAL on failure. If this happens, assigning it to the unsigned
lttpr_count variable strips the negative sign and results in a large value
being passed into ALPM_CTL2_NUMBER_OF_LTTPR(). This could corrupt the
register programming by injecting invalid bits via REG_FIELD_PREP.

> +
> +	intel_de_write(display, ALPM_CTL2(display, cpu_transcoder), alpm_ctl2);
>  	intel_de_write(display, ALPM_CTL(display, cpu_transcoder), alpm_ctl);
>  	mutex_unlock(&intel_dp->alpm.lock);
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index cb92cff906146..37c8306a1fa0d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -2265,6 +2265,25 @@ intel_dp_128b132b_link_train(struct intel_dp *intel_dp,
>  	return passed;
>  }
>  
> +static void intel_dp_update_lttpr_count(struct intel_dp *intel_dp,
> +					int lttpr_count)
> +{
> +	u8 val;
> +
> +	/*
> +	 * Program only for DP2.1 and return if LTTPR revison is less than 0x20
> +	 * where 0:3 represents minor rev and 4:7 represent major rev
> +	 */

[Severity: Low]
This isn't a bug, but the comment specifies "less than 0x20", while the
code below implements a less than or equal to 0x20 (<= 0x20) check.

> +	if (!intel_dp_is_edp(intel_dp) ||
> +	    lttpr_count < 0 ||

[Severity: Low]
Is this lttpr_count < 0 check reachable?

In intel_dp_start_link_train(), the lttpr_count is clamped to 0 on error
before being passed to this function:

	if (lttpr_count < 0)
		/* Still continue with enabling the port and link training. */
		lttpr_count = 0;

	intel_dp_prepare_link_train(intel_dp, crtc_state);
	intel_dp_update_lttpr_count(intel_dp, lttpr_count);

> +	    intel_dp->lttpr_common_caps[0] <= 0x20)

[Severity: High]
Can this LTTPR programming ever be reached for either DP or eDP configurations?

For standard DP connections, the function returns immediately because of the
!intel_dp_is_edp(intel_dp) check above.

For eDP connections, intel_dp_init_lttpr_and_dprx_caps() explicitly skips
LTTPR capabilities initialization, leaving intel_dp->lttpr_common_caps[0]
as 0. That causes the function to also return immediately due to this
<= 0x20 check, rendering the feature unreachable.

> +		return;
> +
> +	val = intel_dp->lttpr_common_caps[DP_PHY_REPEATER_CNT -
> +					  DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV];
> +	drm_dp_dpcd_writeb(&intel_dp->aux, DP_TOTAL_LTTPR_CNT, val);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915180449.277933-1-animesh.manna@intel.com?part=12

  reply	other threads:[~2026-09-15 18:56 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 18:04 [PATCH v6 00/18] Enable DP2.1 alpm Animesh Manna
2026-09-15 18:04 ` [PATCH v6 01/18] drm/i915/alpm: Add DPCD definition for DP2.1 ALPM capability Animesh Manna
2026-09-15 18:04 ` [PATCH v6 02/18] drm/i915/alpm: Move alpm sink capability readout into a separate function Animesh Manna
2026-09-28  9:58   ` Hogander, Jouni
2026-09-28 10:02     ` Hogander, Jouni
2026-09-30  8:04   ` Jani Nikula
2026-10-01 11:21     ` Manna, Animesh
2026-09-15 18:04 ` [PATCH v6 03/18] drm/i915/alpm: alpm_init() for DP2.1 Animesh Manna
2026-09-15 18:57   ` sashiko-bot
2026-09-28 10:44   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 04/18] drm/i915/alpm: Enable debugfs " Animesh Manna
2026-09-28 11:22   ` Hogander, Jouni
2026-10-01 11:32     ` Manna, Animesh
2026-10-08  4:40       ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 05/18] drm/i915/alpm: Refactor Auxless wake time calculation Animesh Manna
2026-09-28 11:49   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 06/18] drm/i915/alpm: Auxless wake time calculation for Xe3p Animesh Manna
2026-09-29  5:34   ` Hogander, Jouni
2026-09-29  5:38   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 07/18] drm/i915/alpm: Modify AUX_LESS_WAKE_TIME bitfield for xe3lpd Animesh Manna
2026-09-15 18:46   ` sashiko-bot
2026-09-29  6:20   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 08/18] drm/i915/alpm: table based establishment period Animesh Manna
2026-09-29  7:00   ` Hogander, Jouni
2026-09-29  7:31     ` Hogander, Jouni
2026-10-01 11:40     ` Manna, Animesh
2026-09-15 18:04 ` [PATCH v6 09/18] drm/i915/alpm: Half LFPS cycle calculation Animesh Manna
2026-09-15 18:53   ` sashiko-bot
2026-09-29  9:57   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 10/18] drm/i915/alpm: Modify LFPS cycle count for DP ALPM Animesh Manna
2026-10-01  6:22   ` Hogander, Jouni
2026-10-01 12:10     ` Hogander, Jouni
2026-10-01 12:11       ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 11/18] drm/i915/alpm: Modify LFPS_CYCLE_COUNT bitfield for xe3lpd Animesh Manna
2026-09-15 18:04 ` [PATCH v6 12/18] drm/i915/alpm: Program LTTPR count for DP 2.1 ALPM Animesh Manna
2026-09-15 18:56   ` sashiko-bot [this message]
2026-09-30  8:16   ` Jani Nikula
2026-10-02  4:41   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 13/18] drm/i915/alpm: Enable MAC Transmitting LFPS for LT PHY Animesh Manna
2026-10-02  5:04   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 14/18] drm/i915/alpm: Replace is_edp() with alpm_is_possible() Animesh Manna
2026-09-15 18:57   ` sashiko-bot
2026-10-02  6:41   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 15/18] drm/i915/alpm: Introduce has_alpm to decouple from pr/psr2/lobf Animesh Manna
2026-09-15 19:01   ` sashiko-bot
2026-10-02  8:37   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 16/18] drm/i915/alpm: Compute and program switch to active latency Animesh Manna
2026-09-15 18:55   ` sashiko-bot
2026-10-02  9:00   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 17/18] drm/i915/alpm: Program zero-based LFPS half cycle duration Animesh Manna
2026-09-15 19:02   ` sashiko-bot
2026-10-02  9:08   ` Hogander, Jouni
2026-09-15 18:04 ` [PATCH v6 18/18] drm/i915/alpm: Disallow ALPM for UHBR link rate Animesh Manna
2026-09-15 19:01   ` sashiko-bot
2026-10-02 11:33   ` Hogander, Jouni
2026-09-15 18:50 ` ✗ CI.checkpatch: warning for Enable DP2.1 alpm (rev6) Patchwork
2026-09-15 18:52 ` ✓ CI.KUnit: success " Patchwork
2026-09-15 19:29 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-15 21:11 ` ✓ i915.CI.BAT: " Patchwork
2026-09-16  1:55 ` ✓ Xe.CI.FULL: " Patchwork
2026-09-16  8:14 ` ✗ i915.CI.Full: failure " Patchwork

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=20260915185628.790771F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=animesh.manna@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.