From: sashiko-bot@kernel.org
To: "Jouni Högander" <jouni.hogander@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/psr: ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR not valid for eDP
Date: Wed, 07 Oct 2026 08:48:27 +0000 [thread overview]
Message-ID: <sashiko-outbox-162757@kernel.org> (raw)
In-Reply-To: <20261007083443.647649-1-jouni.hogander@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/i915/psr: Incomplete bypass of DP-specific PR bits for eDP
--
commit ec05ee2ea4b73ad11b56cabf344de75a2dc66b32
Author: Jouni Högander <jouni.hogander@intel.com>
drm/i915/psr: ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR not valid for eDP
This commit stops using the ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR bit for
eDP panels when computing AS SDP disablement. The eDP 1.5 specification
states that this bit and the DSC_DECODE_NOT_SUPPORTED_IN_PR bit are
DP-specific and not used in eDP.
> EDP1.5 specification says:
>
> "Although defined for the PR function in DP Standard, the
> ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR and DSC_DECODE_NOT_SUPPORTED_IN_PR
> bits (DPCD 000B1h[3, 2], respectively) are DP-specific and are therefore
> not used in eDP."
>
> Stop using SYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR on eDP.
[Severity: Medium]
Since the DSC decode capability bits are not used in eDP either, does
compute_pr_dsc_support() need to be updated to ignore them? Currently, it
reads the DP_PANEL_REPLAY_CAP_CAPABILITY register and extracts the DSC mode
which includes these DP-specific bits:
drivers/gpu/drm/i915/display/intel_psr.c:
compute_pr_dsc_support() {
val = connector->dp.panel_replay_caps.dpcd[INTEL_PR_DPCD_INDEX(DP_PANEL_REPLAY_CAP_CAPABILITY)];
pr_dsc_mode = REG_FIELD_GET8(DP_PANEL_REPLAY_DSC_DECODE_CAPABILITY_IN_PR_MASK, val);
...
}
Also, does intel_psr_pr_async_video_timing_supported() need the same eDP
bypass that is being added in this patch? It still unconditionally checks
the DP_PANEL_REPLAY_ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR bit:
drivers/gpu/drm/i915/display/intel_psr.c:
intel_psr_pr_async_video_timing_supported() {
...
u8 pr_cap = dpcd[INTEL_PR_DPCD_INDEX(DP_PANEL_REPLAY_CAP_CAPABILITY)];
return (pr_support & DP_PANEL_REPLAY_SUPPORT) &&
!(pr_cap & DP_PANEL_REPLAY_ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR);
}
Could this lead to incorrect capability detection on eDP panels if these
unused bits contain non-zero garbage values?
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
> index 872e253db1786..338a8dab75945 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1694,8 +1694,11 @@ static inline bool compute_link_off_after_as_sdp_when_pr_active(struct intel_con
>
> static inline bool compute_disable_as_sdp_when_pr_active(struct intel_connector *connector)
> {
> - return !(connector->dp.panel_replay_caps.dpcd[INTEL_PR_DPCD_INDEX(DP_PANEL_REPLAY_CAP_CAPABILITY)] &
> - DP_PANEL_REPLAY_ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR);
> + struct intel_dp *intel_dp = intel_attached_dp(connector);
> +
> + return intel_dp_is_edp(intel_dp) ? false :
> + !(connector->dp.panel_replay_caps.dpcd[INTEL_PR_DPCD_INDEX(DP_PANEL_REPLAY_CAP_CAPABILITY)] &
> + DP_PANEL_REPLAY_ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR);
> }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261007083443.647649-1-jouni.hogander@intel.com?part=1
next prev parent reply other threads:[~2026-10-07 8:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 8:34 [PATCH] drm/i915/psr: ASYNC_VIDEO_TIMING_NOT_SUPPORTED_IN_PR not valid for eDP Jouni Högander
2026-10-07 8:48 ` sashiko-bot [this message]
2026-10-07 9:17 ` ✗ CI.checkpatch: warning for " Patchwork
2026-10-07 9:19 ` ✓ CI.KUnit: success " Patchwork
2026-10-07 9:34 ` ✗ i915.CI.BAT: failure " Patchwork
2026-10-07 10:06 ` ✓ Xe.CI.BAT: success " Patchwork
2026-10-07 11:27 ` ✓ Xe.CI.FULL: " Patchwork
2026-10-09 3:47 ` [PATCH] " Jake Steinman
2026-10-09 5:30 ` Hogander, Jouni
2026-10-09 17:52 ` Jake Steinman
2026-10-10 5:18 ` Jake Steinman
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-162757@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jouni.hogander@intel.com \
--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.