From: sashiko-bot@kernel.org
To: "Animesh Manna" <animesh.manna@intel.com>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v7 16/20] drm/i915/alpm: Replace is_edp() with alpm_is_possible()
Date: Mon, 26 Oct 2026 07:16:53 +0000 [thread overview]
Message-ID: <sashiko-outbox-184653@kernel.org> (raw)
In-Reply-To: <20261026054001.799894-17-animesh.manna@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/i915/alpm: uninitialized mutex lock in intel_alpm_lobf_disable()
--
commit 3691f816d97c5d3f84209f1900c4bc02406c352b
Author: Animesh Manna <animesh.manna@intel.com>
drm/i915/alpm: Replace is_edp() with alpm_is_possible()
This commit introduces intel_alpm_is_possible() to check ALPM capability
from DPCD and LTTPR info instead of checking intel_dp_is_edp() in
intel_alpm_lobf_compute_config(). It also removes the intel_dp_is_edp()
checks from intel_alpm_lobf_enable() and intel_alpm_lobf_disable().
> diff --git a/drivers/gpu/drm/i915/display/intel_alpm.c b/drivers/gpu/drm/i915/display/intel_alpm.c
> index 4e761022485d7..205f1ae10d431 100644
> --- a/drivers/gpu/drm/i915/display/intel_alpm.c
> +++ b/drivers/gpu/drm/i915/display/intel_alpm.c
[ ... ]
> @@ -829,9 +848,6 @@ void intel_alpm_lobf_disable(const struct intel_crtc_state *new_crtc_state)
>
> intel_dp = enc_to_intel_dp(encoder);
>
> - if (!intel_dp_is_edp(intel_dp))
> - continue;
> -
> mutex_lock(&intel_dp->alpm.lock);
> intel_de_write(display, ALPM_CTL(display, cpu_transcoder), 0);
> drm_dbg_kms(display->drm, "Link off between frames (LOBF) disabled\n");
[Severity: High]
Can removing the intel_dp_is_edp() check in intel_alpm_lobf_disable() cause
mutex_lock(&intel_dp->alpm.lock) to be called on an uninitialized mutex?
In drivers/gpu/drm/i915/display/intel_alpm.c, intel_alpm_init() only
initializes alpm.lock when intel_alpm_source_supported(intel_dp) is true:
void intel_alpm_init(struct intel_dp *intel_dp)
{
if (!intel_alpm_source_supported(intel_dp))
return;
mutex_init(&intel_dp->alpm.lock);
}
On platforms with DISPLAY_VER between 20 and 34, intel_alpm_source_supported()
is only true for eDP encoders, so non-eDP DP encoders leave alpm.lock
uninitialized.
In drivers/gpu/drm/i915/display/intel_display.c, intel_pre_plane_update()
checks whether LOBF is being disabled via intel_crtc_lobf_disabling(), which
inspects old_crtc_state->has_lobf, but then passes new_crtc_state to
intel_alpm_lobf_disable():
if (intel_crtc_lobf_disabling(old_crtc_state, new_crtc_state))
intel_alpm_lobf_disable(new_crtc_state);
If a CRTC with LOBF active on an eDP encoder (old_crtc_state->has_lobf is
true) is switched in an atomic modeset to a non-eDP DP encoder
(new_crtc_state->has_lobf is false), intel_alpm_lobf_disable() iterates over
new_crtc_state->uapi.encoder_mask and calls mutex_lock(&intel_dp->alpm.lock)
on the non-eDP encoder whose mutex was never initialized.
Additionally, because intel_alpm_lobf_disable() inspects new_crtc_state
rather than old_crtc_state, disabling a CRTC by detaching its connector
(leaving new_crtc_state->uapi.encoder_mask empty) skips the loop and leaves
ALPM_CTL enabled, or on DISPLAY_VER >= 35 locks the new encoder's alpm.lock
instead of the old encoder's.
Should intel_pre_plane_update() pass old_crtc_state to
intel_alpm_lobf_disable(const struct intel_crtc_state *old_crtc_state) so it
operates on the encoder and transcoder where LOBF was previously enabled?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261026054001.799894-1-animesh.manna@intel.com?part=16
next prev parent reply other threads:[~2026-10-26 7:17 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 5:39 [PATCH v7 00/20] Enable DP2.1 alpm Animesh Manna
2026-10-26 5:39 ` [PATCH v7 01/20] drm/i915/alpm: Program zero-based LFPS half cycle duration Animesh Manna
2026-10-27 15:33 ` Jani Nikula
2026-10-28 5:42 ` Manna, Animesh
2026-10-26 5:39 ` [PATCH v7 02/20] drm/dp: Add DPCD definitions for DP2.1 ALPM capability Animesh Manna
2026-10-26 5:39 ` [PATCH v7 03/20] drm/i915/alpm: Move alpm sink capability readout into a separate function Animesh Manna
2026-10-26 5:39 ` [PATCH v7 04/20] drm/i915/alpm: alpm_init() for DP2.1 Animesh Manna
2026-10-26 7:11 ` sashiko-bot
2026-10-26 5:39 ` [PATCH v7 05/20] drm/i915/alpm: Enable debugfs " Animesh Manna
2026-10-26 5:39 ` [PATCH v7 06/20] drm/i915/alpm: Refactor Auxless wake time calculation Animesh Manna
2026-10-26 5:39 ` [PATCH v7 07/20] drm/i915/alpm: Auxless wake time calculation for Xe3p Animesh Manna
2026-10-26 5:39 ` [PATCH v7 08/20] drm/i915/alpm: Modify AUX_LESS_WAKE_TIME bitfield for xe3lpd Animesh Manna
2026-10-26 5:39 ` [PATCH v7 09/20] drm/i915/alpm: table based establishment period Animesh Manna
2026-10-26 5:39 ` [PATCH v7 10/20] drm/i915/alpm: Half LFPS cycle calculation Animesh Manna
2026-10-26 7:06 ` sashiko-bot
2026-10-26 5:39 ` [PATCH v7 11/20] drm/i915/alpm: Modify LFPS cycle count for DP ALPM Animesh Manna
2026-10-26 5:39 ` [PATCH v7 12/20] drm/i915/alpm: Modify LFPS_CYCLE_COUNT bitfield for xe3lpd Animesh Manna
2026-10-26 5:39 ` [PATCH v7 13/20] drm/i915/alpm: Program LTTPR count for DP 2.1 ALPM Animesh Manna
2026-10-26 5:39 ` [PATCH v7 14/20] drm/i915/alpm: Enable MAC Transmitting LFPS for LT PHY Animesh Manna
2026-10-26 5:39 ` [PATCH v7 15/20] drm/i915/alpm: Compute and program switch to active latency Animesh Manna
2026-10-26 5:39 ` [PATCH v7 16/20] drm/i915/alpm: Replace is_edp() with alpm_is_possible() Animesh Manna
2026-10-26 7:16 ` sashiko-bot [this message]
2026-10-26 5:39 ` [PATCH v7 17/20] drm/i915/alpm: Disallow ALPM for UHBR link rate Animesh Manna
2026-10-26 5:39 ` [PATCH v7 18/20] drm/i915/alpm: Compute ALPM config before PSR config Animesh Manna
2026-10-26 5:39 ` [PATCH v7 19/20] drm/i915/alpm: Introduce has_alpm to decouple from pr/psr2/lobf Animesh Manna
2026-10-26 7:23 ` sashiko-bot
2026-10-26 5:39 ` [PATCH v7 20/20] drm/i915/dp: Enable AS SDP for DP Panel Replay with AUX-less ALPM Animesh Manna
2026-10-26 5:50 ` ✗ CI.checkpatch: warning for Enable DP2.1 alpm (rev7) Patchwork
2026-10-26 5:52 ` ✓ CI.KUnit: success " Patchwork
2026-10-26 6:28 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-26 8:06 ` ✗ Xe.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=sashiko-outbox-184653@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox