For eDP read the ALPM DPCD caps after DPCD initalization and just before
the PSR init.
v2: Move intel_alpm_init to intel_edp_init_dpcd (Jouni)
v3: Add Fixes with commit-id (Jouni)
v4: Separated the alpm dpcd read caps from alpm_init and moved to
intel_edp_init_dpcd.
v5: Read alpm_caps always for eDP irrespective of the eDP version (Jouni)
v6: replace drm_dp_dpcd_readb with drm_dp_dpcd_read_byte (Jouni)
Fixes: 15438b3259 ("drm/i915/alpm: Add compute config for lobf")
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patch.msgid.link/20260304072157.1123283-1-arun.r.murthy@intel.com
(cherry picked from commit 88442ba208)
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
The pipe BPP value shouldn't be set outside of the source's / sink's
valid pipe BPP range, ensure this when increasing the minimum pipe BPP
value to 30 due to HDR.
While at it debug print if the HDR mode was requested for a connector by
setting the corresponding HDR connector property. This indicates
if the requested HDR mode could not be enabled, since the selected
pipe BPP is below 30, due to a sink capability or link BW limit.
v2:
- Also handle the case where the sink could support the target 30 BPP
only in DSC mode due to a BW limit, but the sink doesn't support DSC
or 30 BPP as a DSC input BPP. (Chaitanya)
- Debug print the connector's HDR mode in the link config dump, to
indicate if a BPP >= 30 required by HDR couldn't be reached. (Ankit)
- Add Closes: trailer. (Ankit)
- Don't print the 30 BPP-outside of valid BPP range debug message if
the min BPP is already > 30 (and so a target BPP >= 30 required
for HDR is ensured).
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7052
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15503
Fixes: ba49a4643c ("drm/i915/dp: Set min_bpp limit to 30 in HDR mode")
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: <stable@vger.kernel.org> # v6.18+
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> # v1
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260209133817.395823-1-imre.deak@intel.com
(cherry picked from commit 08b7ef16b6)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
If dsc_compute_compressed_bpp() failed with a forced pipe BPP value
(where the forced pipe BPP value itself is valid within the min/max pipe
BPP limits), the function will also fail when called with the maximum
pipe BPP value: dsc_compute_compressed_bpp() will try all compressed
BPPs below the passed in pipe BPP value and if the function failed with
a given (low) compressed BPP value it will also fail with a compressed
BPP value higher than the one which failed already.
Based on the above remove the logic to retry computing a compressed BPP
value with the maximum pipe BPP value if computing the compressed BPP
failed already with the (lower) forced pipe BPP value.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-18-imre.deak@intel.com
The maximum pipe BPP value (used as the DSC input BPP) has been aligned
already to the corresponding source/sink input BPP capabilities in
intel_dp_compute_config_limits(). So it isn't needed to perform the same
alignment again in intel_dp_dsc_compute_pipe_bpp() called later, this
function can simply use the already aligned maximum pipe BPP value, do
that.
Also, there is no point in trying pipe BPP values lower than the
maximum: this would only make dsc_compute_compressed_bpp() start with a
lower _compressed_ BPP value, but this lower compressed BPP value has
been tried already when dsc_compute_compressed_bpp() was called with the
higher pipe BPP value (i.e. the first dsc_compute_compressed_bpp() call
tries already all the possible compressed BPP values which are all below
the pipe BPP value passed to it). Simplify the function accordingly
trying only the maximum pipe BPP value.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-17-imre.deak@intel.com
The maximum pipe BPP value (used as the DSC input BPP) has been aligned
already to the corresponding source/sink input BPP capabilities in
intel_dp_compute_config_limits(). So it isn't needed to perform the same
alignment again in intel_edp_dsc_compute_pipe_bpp() called later, this
function can simply use the already aligned maximum pipe BPP value, do
that.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-16-imre.deak@intel.com
The minimum/maximum compressed BPP values are aligned/bounded in
intel_dp_compute_link_bpp_limits() to the corresponding source limits.
The minimum compressed BPP value doesn't change afterwards, so no need
to align it again, remove that.
The maximum compressed BPP, which depends on the pipe BPP value still
needs to be aligned, since the pipe BPP value could change after the
above limits were computed, via intel_dp_force_dsc_pipe_bpp(). Use the
corresponding helper for this alignment instead of open-coding the same.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-15-imre.deak@intel.com
Atm, a DP DSC video mode's required BW vs. the available BW is
determined by calculating the maximum compressed BPP value allowed by
the available BW. Doing that using a closed-form formula as it's done
atm (vs. an iterative way) is problematic, since the overhead of the
required BW itself depends on the BPP value being calculated. Instead of
that calculate the required BW for the minimum compressed BPP value
supported both by the source and the sink and check this BW against the
available BW. This change also aligns the BW calculation during mode
validation with how this is done during state computation, calculating
the required effective data rate with the corresponding BW overhead.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-14-imre.deak@intel.com
Add intel_dp_mode_valid_with_dsc() and call this for an SST/MST mode
validation to prepare for a follow-up change using a way to verify the
mode's required BW the same way this is done elsewhere during state
computation (which in turn depends on the mode's effective data rate
with the corresponding BW overhead).
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-13-imre.deak@intel.com
Align the minimum/maximum DSC compressed BPPs to the corresponding
source compressed BPP limits already when computing the BPP limits. This
alignment is also performed later during state computation, however
there is no reason to initialize the limits to an unaligned/incorrect
value.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-7-imre.deak@intel.com
Align the minimum/maximum DSC input BPPs to the corresponding sink DSC
input BPP capability limits already when computing the BPP limits. This
alignment is also performed later during state computation, however
there is no reason to initialize the limits to an unaligned/incorrect
value.
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251222153547.713360-6-imre.deak@intel.com
The pipe joiner maximum compressed BPP must be limited based on the pipe
joiner memory size and BW, do that for all DP outputs by adjusting the
max compressed BPP value already in
intel_dp_compute_config_link_bpp_limits() (which is used by all output
types).
This way the BPP doesn't need to be adjusted in
dsc_compute_compressed_bpp() (called for DP-SST after the above limits
were computed already), so remove the adjustment from there.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-13-imre.deak@intel.com
A DSC compressed stream requires FEC (except for eDP), which has a BW
overhead on non-UHBR links that must be accounted for explicitly. Do
that during computing the required BW.
Note that the overhead doesn't need to be accounted for on UHBR links
where FEC is always enabled and so the corresponding overhead is part of
the channel coding efficiency instead (i.e. the overhead is part of the
available vs. the required BW).
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-12-imre.deak@intel.com
Use intel_dp_effective_data_rate() to calculate the required link BW for
compressed streams on non-UHBR DP-SST links. This ensures that the BW is
calculated the same way for all DP output types and DSC/non-DSC modes,
during mode validation as well as during state computation.
This approach also allows for accounting with BW overhead due to DSC,
FEC being enabled on a link. Acounting for these will be added by
follow-up changes.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-10-imre.deak@intel.com
Use intel_dp_effective_data_rate() to calculate the required link BW for
eDP, DP-SST and MST links. This ensures that the BW is calculated the
same way for all DP output types, during mode validation as well as
during state computation. This approach also allows for accounting with
BW overheads due to the SSC, DSC, FEC being enabled on a link, as well
as due to the MST symbol alignment on the link. Accounting for these
overheads will be added by follow-up changes.
This way also computes the stream BW on a UHBR link correctly, using the
corresponding symbol size to effective data size ratio (i.e. ~97% link
BW utilization for UHBR vs. only ~80% for non-UHBR).
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-9-imre.deak@intel.com
The encoder state computation should use the
drm_display_mode::crtc_clock member, instead of the clock member, the
former one possibly having a necessary adjustment wrt. to the latter
due to driver specific constraints. In practice the two values should
not differ at spots changed in this patch, since only MSO and 3D modes
would make them different, neither MSO or 3D relevant here, but still
use the expected crtc_clock version for consistency.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-6-imre.deak@intel.com
Convert intel_dp_output_bpp() and intel_dp_mode_min_output_bpp() to
return an x16 fixed point bpp value, as this value will be always the
link BPP (either compressed or uncompressed) tracked in the same x16
fixed point format.
While at it rename
intel_dp_output_bpp() to intel_dp_output_format_link_bpp_x16() and
intel_dp_mode_min_output_bpp() to intel_dp_mode_min_link_bpp_x16() to
better reflect that these functions return an x16 link BPP value
specific to a particular output format or mode.
Also rename intel_dp_output_bpp()'s bpp parameter to pipe_bpp, to
clarify which kind of (pipe vs. link) BPP the parameter is.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251215192357.172201-5-imre.deak@intel.com
As a preparation for MST Panel Replay we need to move Panel Replay sink
related data into intel_connector. Move sink support booleans as well
into intel_connector. Generally this is more correct place for this data so
move PSR versions as well.
Still sink_support and sink_panel_replay_support are kept to keep CAN_PSR
and CAN_PANEL_REPLAY macros. Plan is to keep them that way as they are
widely used from patch where connector is not available.
Later we might want to clear intel_dp->psr.sink_panel_replay_support if any
of the devices in branch is not supporting Panel Replay (mst).
v2:
- commit message updated
- Extra w/s removed
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251204104733.1106145-8-jouni.hogander@intel.com
Currently we are storing only one set of granularity information for panels
supporting both PSR and Panel Replay. As panel is informing own
granularities for PSR and Panel Replay they could be different. Let's use
own granularities for PSR and Panel Replay instead of having only one set
for both. This is done by having intel_connector::psr_caps and
panel_replay_caps both containing granularity information.
Also remove complexity of sharing granularity read between PSR and Panel
Replay.
v3:
- use cpu_to_le16 for default value
v2:
- use __le16 for two byte values in dpcd
- use sizeof instead of hardcoded size in reading dpcd
- drop unnecessarily passing intel_dp pointer
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20251204104733.1106145-3-jouni.hogander@intel.com
The remaining utils display needs from i915_utils.h are primarily
MISSING_CASE() and fetch_and_zero(), with a couple of
i915_inject_probe_failure() uses.
To avoid excessive churn, add duplicates of MISSING_CASE() and
fetch_and_zero() to intel_display_utils.h, and switch display to use the
display utils.
As long as there are display files that include i915_drv.h, which
includes i915_utils.h, we'll need #ifndef guards for MISSING_CASE() and
fetch_and_zero() in both utils headers. We can remove them once display
no longer depends on i915_drv.h.
A couple of files in display still need i915_utils.h for
i915_inject_probe_failure(). Annotate this. They will be handled
separately.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patch.msgid.link/79f9e31ca64c8c045834d48e20ceb0c515d1e9e1.1761146196.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We started seeing "[drm] *ERROR* Timed out waiting PSR idle state" after
taking optimized guardband into use. These are seen because VSC SDPs are
sent on same line as AS SDPs when AS SDP is enabled. AS SDP is sent on line
configured in EMP_AS_SDP_TL register. We are configuring
crtc_state->vrr.vsync_start into that register.
Fix this by ensuring AS SDP is sent on line which is within
guardband. From the bspec:
EMP_AS_SDP_TL < SCL + Guardband
v2: check HAS_AS_SDP
Bspec: 71197
Fixes: 52ecd48b8d ("drm/i915/dp: Add helper to get min sdp guardband")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20251023043140.961104-1-jouni.hogander@intel.com
The intel_crtc_state::fec_enable check in intel_dp_needs_8b10b_fec() is
redundant drop it: originally it ensured that the FEC enabled state for
a CRTC other than the CRTC intel_dp_needs_8b10b_fec() called for is
preserved, even if DSC is not enabled for the latter CRTC. The way FEC
gets enabled for all the CRTCs on an 8b10b MST link is changed by
commit 7c027070e9 ("drm/i915/dp_mst: Track DSC enabled status on the
MST link") and
commit 470b84af45 ("drm/i915/dp_mst: Recompute all MST link CRTCs if
DSC gets enabled on the link")
depending on intel_dsc_enabled_on_link() in intel_dp_needs_8b10b_fec()
instead of the above fec_enable check. Drop the check.
Suggested-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20251020154438.416761-1-imre.deak@intel.com
Add a helper to compute vblank time needed for transmitting specific
DisplayPort SDPs like PPS, GAMUT_METADATA, and VSC_EXT. Latency is
based on line count per packet type.
This will be used to ensure adequate guardband when features like DSC/HDR
are enabled.
v2: Correct the lines required for PPS SDP. (Jouni)
Bspec: 70151
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251017123504.2247954-3-ankit.k.nautiyal@intel.com
Prevent enabling panel replay if the sink doesn't support this due to
DSC being enabled.
Panel replay has two modes, updating full frames or only selected
regions of the frame. If the sink doesn't support Panel Replay in full
frame update mode with DSC prevent Panel Replay completely if DSC is
enabled. If the sink doesn't support Panel Replay only in the selective
update mode while DSC is enabled, it will still support Panel Replay in
the full frame update mode, so only prevent selective updates in this
case.
v2:
- Use Panel Replay instead of PR in debug prints. (Jouni)
- Rebase on change tracking the link DSC state in the crtc state.
Cc: Jouni Högander <jouni.hogander@intel.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14869
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-8-imre.deak@intel.com
Track whether DSC is enabled on any CRTC on a link. On DP-SST (and DSI)
this will always match the CRTC's DSC state, those links having only a
single stream (aka CRTC). For instance, on DP-MST if DSC is enabled for
CRTC#0, but disabled for CRTC#1, the DSC/FEC state for these CRTCs will
be as follows:
CRTC#0:
- compression_enable = true
- compression_enabled_on_link = true
- fec_enable = true for 8b10b, false for 128b132b
CRTC#1:
- compression_enable = false
- compression_enabled_on_link = true
- fec_enable = true for 8b10b, false for 128b132b
This patch only sets compression_enabled_on_link for CRTC#0 above and
enables FEC on CRTC#0 if DSC was enabled on any other CRTC on the 8b10b
MST link. A follow-up change will make sure that the state of all the
CRTCs (CRTC#1 above) on an MST link is recomputed if DSC gets enabled on
any CRTC, setting compression_enabled_on_link and fec_enable for these.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-6-imre.deak@intel.com
Export the helper function to determine if FEC is required on a non-UHBR
(8b10b) SST or MST link. A follow up change will take this into use for
MST as well.
While at it determine the output type from the CRTC state, which allows
dropping the intel_dp argument. Also make the function return the
required FEC state, instead of setting this in the CRTC state, which
allows only querying this requirement, without changing the state.
Also rename the function to intel_dp_needs_8b10b_fec(), to clarify that
the function determines if FEC is required on an 8b10b link (on 128b132b
links FEC is always enabled by the HW implicitly, so the function will
return false for that case).
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-4-imre.deak@intel.com
Atm, in the DP SST case the FEC state is computed before
intel_crtc_state::port_clock is initialized, hence intel_dp_is_uhbr()
will always return false and the FEC state will be always computed
assuming a non-UHBR link.
This happens to work, since the FEC state is recomputed later in
intel_dp_mtp_tu_compute_config(), where port_clock will be set already,
so intel_crtc_state::fec_enable will be reset as expected for UHBR. This
also depends on link rates being tried in an increasing order (i.e. from
non-UHBR -> UHBR link rates) in dsc_compute_link_config(), thus
intel_crtc_state::fec_enable being set for the non-UHBR rates and
getting reset for the first UHBR rate as expected.
A follow-up change will reuse intel_dp_fec_compute_config() for the DP
MST state computation, prepare for that here, making sure that the
function determines the correct intel_crtc_state::fec_enable=false state
for UHBR link rates based on the above.
The DP SST and MST state computation should be further unified to avoid
computing/setting the intel_crtc_state::fec_enable state multiple times,
but that's left for a follow-up change. For now add only code comments
about this.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-3-imre.deak@intel.com
