Imre Deak [Wed, 18 Feb 2026 10:57:08 +0000 (12:57 +0200)]
drm/i915/dp_mst: Fix ww mutex lock failure in for_each_joiner_candidate() loop
Handle modeset WW mutex lock failures due to contention properly.
Return -EDEADLK to the caller instead of attempting to lock the same
mutex again in a subsequent joiner candidate iteration, where the WW
mutex is already in a contended state.
This fixes the following warning:
WARNING: drivers/gpu/drm/drm_modeset_lock.c:298 at modeset_lock+0x1c0/0x210
Imre Deak [Wed, 18 Feb 2026 10:57:07 +0000 (12:57 +0200)]
drm/i915/dp: Fix ww mutex lock failure in for_each_joiner_candidate() loop
Handle modeset WW mutex lock failures due to contention properly.
Return -EDEADLK to the caller instead of attempting to lock the same
mutex again in a subsequent joiner candidate iteration, where the WW
mutex is already in a contended state.
This fixes the following warning:
WARNING: drivers/gpu/drm/drm_modeset_lock.c:298 at modeset_lock+0x1c0/0x210
Imre Deak [Mon, 16 Feb 2026 07:04:21 +0000 (09:04 +0200)]
drm/i915/dp_mst: Allow modes requiring compression for DSC passthrough
The DSC passthrough mode allows a compressed stream to be forwarded
to the sink instead of being decompressed at the last MST branch
device, provided that the branch device supports passthrough and
the sink supports decompression. This enables modes that would not
be possible without compression, as the bandwidth required for the
uncompressed stream exceeds what is available on the full MST path
from source to sink.
Currently, MST mode validation assumes the stream is uncompressed
and uses the corresponding uncompressed minimum link BPP for
bandwidth calculation. Use the minimum compressed link BPP instead
when DSC passthrough is available to enable the modes described
above.
The non-passthrough DSC mode, where the last MST branch device
decompresses the stream, may also allow enabling additional modes.
This would require determining the link bandwidth between the last
branch device and the sink based on the
DFP_Link_Available_Payload_Bandwidth_Number reported by the branch
device for the sink via the ENUM_PATH_RESOURCES MST message.
Supporting this is left for a follow-up for the following reasons:
1. DFP Link Available PBN reporting is not supported by any of the
available MST devices used for testing.
2. Non-passthrough mode would enable additional modes only if the link
bandwidth between the last branch device and the sink exceeded that
of the full MST path. Unless multiple MST devices are used, or link
training forces a reduced bandwidth between the source and the first
branch device, both rare cases, this is unlikely.
Rahul Bukte [Tue, 3 Feb 2026 04:48:39 +0000 (10:18 +0530)]
drm/i915/gt: Check set_default_submission() before deferencing
When the i915 driver firmware binaries are not present, the
set_default_submission pointer is not set. This pointer is
dereferenced during suspend anyways.
Add a check to make sure it is set before dereferencing.
Imre Deak [Wed, 11 Feb 2026 11:58:11 +0000 (13:58 +0200)]
drm/i915/dp: Clamp the connector max_bpc request to the valid pipe bpp range
The user's request for a maximum BPC - via the max-bpc connector
property - determines the pipe BPP selected by the encoder, which is in
turn used either as the uncompressed output BPP or as the input BPP for
the DSC engine. This user-requested BPC->BPP can be outside of the
source/sink's supported valid min/max pipe BPP range and atm such an
out-of-bound request will be rejected by the encoder's state
computation.
As opposed to the above, the semantics for the max-bpc connector
property - which the user may reasonably expect - should not be to
fail the modeset in case of an out-of-bound max BPC request, but rather
to adjust the request, clamping it to the valid BPP range.
Based on the above, calculate the baseline (i.e. the non-DP specific
platform/EDID) _maximum_ pipe BPP, storing it in
intel_crtc_state::max_pipe_bpp, separately from the baseline _target_
pipe BPP (which is the lower BPP of the baseline maximum and requested
maximum BPP, stored in intel_crtc_state::pipe_bpp). This allows the
encoder state computation to use the baseline maximum pipe BPP as a hard
limit for the selected pipe BPP, while also letting it use the baseline
target pipe BPP only as a preference, clamping this target BPP to the
valid DP pipe BPP range.
v2:
- Fix typos in the commit message. (Michał)
- Clarify code comment's reference to the baseline max BPP value.
(Ankit)
Imre Deak [Wed, 11 Feb 2026 11:58:10 +0000 (13:58 +0200)]
drm/i915/display: Clarify target pipe bpp variable name in compute_sink_pipe_bpp()
Clarify that the baseline pipe BPP - i.e. the non-DP specific
platform/EDID maximum BPP limited by any user-requested max-bpc setting
- set by compute_sink_pipe_bpp() is a baseline _target_ pipe BPP. This
target BPP can get either rejected or adjusted (lowering or increasing
it as needed) by the encoder state computation based on other
constraints, like a minimum pipe BPP dictated by a non-RGB output format
(24 BPP) or a min/max DSC input BPP dictated by a DSC sink. Whether an
out-of-bound target BPP is adjusted or rejected depends on the max-bpc
property's semantics assumed by the driver, which is atm to reject such a
request.
A follow-up change will also compute the baseline _maximum_ pipe BPP,
which is the non-DP specific platform/EDID maximum BPP w/o the requested
max-bpc adjustment and as such is a hard limit: the encoder state
computation must ensure that the final BPP selected for the modeset is
below this maximum. Tracking the baseline maximum pipe BPP separately
will allow for adjusting the baseline target BPP as needed, clamping it
to the valid DP min/max pipe BPP range, instead of rejecting an
out-of-bound BPC/BPP request.
To clarify the above semantics rename bpp in compute_sink_pipe_bpp() to
target_pipe_bpp in this patch, preparing for a follow-up change also
computing max_pipe_bpp in the same function.
Uma Shankar [Thu, 5 Feb 2026 09:43:33 +0000 (15:13 +0530)]
drm/i915: Remove i915_reg.h from i9xx_wm.c
Move FW_BLC_SELF to common header to make i9xx_wm.c
free from i915_reg.h include. Introduce a common
intel_gmd_misc_regs.h to define common miscellaneous
register definitions across graphics and display.
v3: MISC header included as needed, drop from i915_reg (Jani)
Uma Shankar [Thu, 5 Feb 2026 09:43:22 +0000 (15:13 +0530)]
drm/i915: Extract display registers from i915_reg.h to display
There are certain register definitions which are defined in i915_reg.h
which are exclusively needed by display. Move the same to display
headers to remove i915_reg.h includes from display. This is a step
towards making display independent of i915.
intel_clock_gating.c can include display header directly, since its
usage is planned to be re-factored and will be moved within display.
v3: Updated subject and commit message (Jani)
v2: Drop common header in include and use display_regs.h (Jani)
drm/i915/acpi: free _DSM package when no connectors
acpi_evaluate_dsm_typed() returns an ACPI package in pkg.
When pkg->package.count == 0, we returned without freeing pkg,
leaking memory. Free pkg before returning on the empty case.
Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> Fixes: 337d7a1621c7 ("drm/i915: Fix invalid access to ACPI _DSM objects") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260109032549.1826303-1-kaushlendra.kumar@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Fri, 6 Feb 2026 12:59:49 +0000 (14:59 +0200)]
drm/i915/overlay: remove dead code with MTL platform checks
Commit c5741c5c1122 ("drm/i915/display: Do not use stolen on MTL") added
some checks for MTL in overlay code. However, this is never run on
MTL. Clean it up.
Imre Deak [Mon, 9 Feb 2026 13:38:16 +0000 (15:38 +0200)]
drm/i915/dp: Fix pipe BPP clamping due to HDR
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).
Ankit Nautiyal [Fri, 6 Feb 2026 04:47:53 +0000 (10:17 +0530)]
drm/i915/dp: Restore the missing check for intel_dp_has_joiner
Commit ad121a62d566 ("drm/i915/dp: Rework pipe joiner logic in mode_valid")
replaced intel_dp_num_joined_pipes() with an explicit joiner candidate
iteration. The previous code implicitly checked for DP joiner capability
via intel_dp_has_joiner(), but this check was lost during the refactor.
Restore the missing intel_dp_has_joiner() check in intel_dp_can_join() so
that DP specific joiner conditions are taken into account.
v2: Derive intel_dp from intel_attached_dp(). (Imre)
Fixes: ad121a62d566 ("drm/i915/dp: Rework pipe joiner logic in mode_valid") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260206044753.808631-1-ankit.k.nautiyal@intel.com
Ankit Nautiyal [Thu, 5 Feb 2026 08:36:22 +0000 (14:06 +0530)]
drm/i915/dp: Make intel_dp_can_join() static
intel_dp_can_join() was previously exposed in intel_dp.h, but after the
recent joiner refactor it is only used internally via
intel_dp_joiner_candidate_valid(). It no longer needs external
visibility, so make it static and drop the prototype from intel_dp.h.
Ankit Nautiyal [Fri, 26 Dec 2025 04:33:59 +0000 (10:03 +0530)]
drm/i915/quirks: Fix device id for QUIRK_EDP_LIMIT_RATE_HBR2 entry
Update the device ID for Dell XPS 13 7390 2-in-1 in the quirk
`QUIRK_EDP_LIMIT_RATE_HBR2` entry. The previous ID (0x8a12) was
incorrect; the correct ID is 0x8a52.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969 Fixes: 21c586d9233a ("drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: <stable@vger.kernel.org> # v6.18+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20251226043359.2553-1-ankit.k.nautiyal@intel.com
Ankit Nautiyal [Wed, 4 Feb 2026 05:02:50 +0000 (10:32 +0530)]
drm/i915/alpm: Disable LOBF around transitioning for LRR/seamless MN
When enabling LRR/seamless MN disable LOBF first and re-enable
afterwards.
- pre_plane_update: if LOBF was enabled, disable LOBF before the
update_lrr/update_m_n transition.
- post_plane_update: Re-enable LOBF after the transition.
Ankit Nautiyal [Wed, 4 Feb 2026 05:02:49 +0000 (10:32 +0530)]
drm/i915/alpm: Simplify and align LOBF checks in pre/post plane update
The pre_plane_update and post_plane_update hooks essentially
disable/enable lobf feature. Use the existing _is_enabling/is_disabling
logic for this in the pre_plane_update and post_plane_update paths.
Also rename the helpers to intel_alpm_lobf_{en,dis}able().
v2: Remove redeundant checks during enabling/disabling. (Jouni)
Ankit Nautiyal [Wed, 4 Feb 2026 05:02:48 +0000 (10:32 +0530)]
drm/i915/alpm: Allow LOBF only for platform that have Always on VRR TG
As per bspec the LOBF is allowed when running in fixed refresh rate mode
i.e. when flipline = vmin = vmax and when window1 is non zero. This
implies that we can allow LOBF only when VRR timing generator is running
in the fixed refresh rate mode.
Use the check intel_vrr_always_use_vrr_tg() to avoid LOBF with legacy
timing generator. Also use intel_vrr_is_fixed_rr() to check for fixed
refresh rate mode.
v2: Modify commit message to clarify window1 requirement for LOBF.
(Ville)
Ankit Nautiyal [Wed, 4 Feb 2026 05:02:46 +0000 (10:32 +0530)]
drm/i915/alpm: Compute LOBF late after guardband is already determined
Currently intel_alpm_lobf_compute_config() tries to account for
guardband +SCL requirements during encoder->compute_config() phase,
even before guardband is computed.
Also, LOBF depends on crtc_state->has_psr which can be modified in
encoder->compute_config_late().
Account for lobf requirements while optimizing the guardband and add
checks for final guardband in encoder->compute_config_late() phase after
the guardband and the final state of crtc_state->has_psr are already
computed.
Use crtc_state->vrr.guardband and crtc_state->set_context_latency for
the computation and add more documentation for the dependency of first
sdp position, guardband, set context latency and wake lines.
v2: Add helper to use min guardband required for lobf.
v3: Remove unrelated inadvertent changes. (Michał)
v4: Add a #FIXME note for computing wakelines based on feature. (Jouni)
Suraj Kandpal [Wed, 4 Feb 2026 02:32:47 +0000 (08:02 +0530)]
drm/i915/ltphy: Return true for TBT scenario during lt_phy_state compare
TBT PHY is enablement/disablement is handled by its own TBT module.
We do not play a big part in it's state management, that being take care
by it's own TBT modeule.
The PHY/PLL TypeC mode (TBT, DP-alt) can change after the PLL state was
computed for a modeset, so the state verification after the modeset
sequence would indicate a mismatch in case the mode changed from DP-alt
to TBT, or from TBT to DP-alt mode. To avoid such a mismatch error the
verification is skipped if the mode for either the read-out or the
computed state is TBT (where that TBT PLL state doesn't reflect anyway
the PLL's actual HW state).
Simply return true when we are in tbt mode.
Mika Kahola [Mon, 2 Feb 2026 14:02:42 +0000 (14:02 +0000)]
drm/i915/power_well: Enable workaround for DSS clock gating issue
Prevent display corruption observed after restart, hotplug, or unplug
operations on Meteor Lake and newer platforms. The issue is caused by
DSS clock gating affecting DSC logic when pipe power wells are disabled.
Apply this WA by disabling DSS clock gating for the affected pipes
before turning off their power wells. This avoids DSC corruption on
external displays.
v2: Use single intel_de_rmw() (Jani)
Switch to use drm_dbg_kms() instead of drm_printf() (Jani)
Remove WA number from commit message (Suraj)
rename dss_clock_gating_enable_disable() to
dss_pipe_gating_enable_disable();
v3: Do not use open ended display version when checking
wa (Matt)
drm/i915/display: Extend the max dotclock limit to WCL
Add upper limit check for pixel clock for WCL.
For prior platforms though the bspec mentions the dotclock limits, however
these are intentionally not enforced to avoid regressions, unless real
issues are observed.
drm/i915/display: Add upper limit check for pixel clock
Add upper limit check for pixel clock for DISPLAY_VER >= 30.
Limits don't apply when DSC is enabled.
The helper returns the upper limit for the platforms, capped to the
max dotclock (khz).
For the currently supported versions of HDMI, pixel clock is already
limited to 600Mhz so nothing needs to be done there as of now.
v2:
- Add this limit to the new helper.
v3:
- Rename helper to intel_max_uncompressed_dotclock(). (Imre)
- Limit only for PTL and cap the limit to max_dotclock. (Imre)
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:29 +0000 (16:07 +0530)]
drm/i915/dp: Add helpers for joiner candidate loops
Introduce for_each_joiner_candidate(), intel_dp_joiner_candidate_valid()
and intel_dp_joiner_candidate_valid() to remove duplicated joiner
enumeration and validity checks across DP SST and MST paths.
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:27 +0000 (16:07 +0530)]
drm/i915/dp: Refactor dsc_slice_count handling in intel_dp_mode_valid()
Make dsc_slice_count closer to the block where it is used and promote it
from u8 to int. This aligns it with upcoming DSC bubble pixel-rate
adjustments, where the slice count participates in wider arithmetic.
Currently, for non-eDP (DP/DP_MST) cases the slice count is computed only
inside intel_dp_dsc_mode_valid() and is not used by the caller. Once DSC
bubble handling is added, dp_mode_valid() will need access to its own local
slice count for non-eDP cases as well.
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:26 +0000 (16:07 +0530)]
drm/i915/dp: Introduce helper to check pixel rate against dotclock limits
Add intel_dp_dotclk_valid() helper, that checks the required pixel rate
against platform dotclock limit. With joined pipes the effective dotclock
limit depends upon the number of joined pipes.
Call the helper from the mode_valid phase and from the compute_config
phase where we need to check the limits for the given target clock for a
given joiner candidate.
v2: Rename the helper to intel_dp_dotclk_valid(). (Imre)
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:25 +0000 (16:07 +0530)]
drm/i915/dp: Remove unused joiner helpers
The helpers intel_dp_num_joined_pipes() and intel_dp_needs_joiner() are no
longer used now that joiner selection iterates over all candidates.
Remove them.
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:24 +0000 (16:07 +0530)]
drm/i915/dp_mst: Rework pipe joiner logic in compute_config
Similar to the DP SST, refactor mst_stream_compute_config() to iterate
over joiner candidates and select the minimal joiner configuration that
satisfies the mode requirements. This prepares the logic for future changes
that will consider DSC slice overhead.
v2:
- Move the check for dotclock in the new helper and check for both DSC and
non-DSC case. In case the check fails for non-DSC, fallback to DSC
configuration. (Imre)
- Propagate the return value from the core helper:
mst_stream_compute_link_for_joined_pipes(). (Imre)
v3:
- Use num_joined_pipes instead of num_pipes. (Imre)
v4:
- Switch to 'ret == 0' for break condition to match SST code.
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:23 +0000 (16:07 +0530)]
drm/i915/dp_mst: Extract helper to compute link for given joiner config
Move the joiner-dependent portion of mst_stream_compute_config() into
mst_stream_compute_link_for_joined_pipes(), which computes the MST link
configuration for a specific num_joined_pipes.
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:22 +0000 (16:07 +0530)]
drm/i915/dp_mst: Rework pipe joiner logic in mode_valid
Refactor the logic to get the number of joined pipes. Start with a single
pipe and incrementally try additional pipes only if needed. While DSC
overhead is not yet computed here, this restructuring prepares the code to
support that in follow-up changes.
v2:
- Remove fallback in case force-joiner configuration fails. (Imre)
- Drop redundant MODE_OK assignment (Imre)
v3:
- Align with the changes in intel_dp_mode_valid(). (Imre)
v4:
- Set MODE_CLOCK_HIGH on DSC/rate failures aligning with SST case. (Imre)
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:19 +0000 (16:07 +0530)]
drm/i915/dp: Rework pipe joiner logic in compute_config
Currently, the number of joined pipes are determined early in the flow,
which limits flexibility for accounting DSC slice overhead. To address
this, recompute the joined pipe count during DSC configuration.
Refactor intel_dp_dsc_compute_config() to iterate over joiner candidates
and select the minimal joiner configuration that satisfies the mode
requirements. This prepares the logic for future changes that will
consider DSC slice overhead.
v2:
- Rename helper to intel_dp_compute_link_for_joined_pipes(). (Imre)
- Move the check for max dotclock inside the helper so that if dotclock
check fails for non DSC case for a given number of joined pipes, we
are able to fallback to the DSC mode. (Imre)
v3:
- Drop fallback to other joiner configurations, if the force joiner
configuration fails. (Imre)
- Check for maxdotclock limit for non-DSC case first and fall back to
DSC if the check fails. (Imre)
- Initialize ret to -EINVAL to handle case where we bail out early.
(Imre)
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:18 +0000 (16:07 +0530)]
drm/i915/dp: Rework pipe joiner logic in mode_valid
Currently in intel_dp_mode_valid(), we compute the number of joined pipes
required before deciding whether DSC is needed. This ordering prevents us
from accounting for DSC-related overhead when determining pipe
requirements.
It is not possible to first decide whether DSC is needed and then compute
the required number of joined pipes, because the two depend on each other:
- DSC need is a function of the pipe count (e.g., 4‑pipe always requires
DSC; 2‑pipe may require it if uncompressed joiner is unavailable).
- Whether a given pipe‑join configuration is sufficient depends on
effective bandwidth, which itself changes when DSC is used.
As a result, the only correct approach is to iterate candidate pipe counts.
So, refactor the logic to start with a single pipe and incrementally try
additional pipes only if needed. While DSC overhead is not yet computed
here, this restructuring prepares the code to support that in a follow-up
changes.
If a forced joiner configuration is present, we just check for that
configuration. If it fails, we bailout and return instead of trying with
other joiner configurations.
v2:
- Iterate over number of pipes to be joined instead of joiner
candidates. (Jani)
- Document the rationale of iterating over number of joined pipes.
(Imre)
v3:
- In case the force joiner configuration doesn't work, do not fallback
to the normal routine, bailout instead of trying other joiner
configurations. (Imre)
v4:
- Use num_joined_pipes instead of num_pipes. (Imre)
- Inititialize status before the loops starts. (Imre)
v5:
- Fix status handling by setting MODE_CLOCK_HIGH on DSC/rate failures.
(Imre)
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:16 +0000 (16:07 +0530)]
drm/i915/dp: Move num_joined_pipes and related checks together
Move the calculation of `num_joined_pipes` and other constraints that
depend on it, into a single block.
This groups all joiner-dependent logic together, preparing the code for a
future loop-based evaluation of multiple joiner configurations.
Suraj Kandpal [Mon, 2 Feb 2026 08:18:02 +0000 (13:48 +0530)]
drm/i915/dp: Add a meaningful return to intel_dp_read_dsc_dpcd
Add a meaningful return to intel_dp_read_dsc_dpcd. This is to avoid
unwanted DPCD reads which are not needed once we know DSC DPCD
read fails. To do this convert drm_dp_dpcd_read to drm_dp_dpcd_read_data
which returns a meaningful error which can be propogated up when all
bits are not read.
While we are at it convert the drm_err in intel_dp_read_dsc_dpcd to
drm_dbg_kms. This is because we do not want a hard ERROR when we
call this function, during the intel_dp_detect phase since AUX may not
be up, it is expected to fail but we do not expect a failure in read
when we call intel_dp_dsc_get_sink_cap so we move the drm_err there.
drm/i915/display: fix the pixel normalization handling for xe3p_lpd
Pixel normalizer is enabled with normalization factor as 1.0 for
FP16 formats in order to support FBC for those formats in xe3p_lpd.
Previously pixel normalizer gets disabled during the plane disable
routine. But there could be plane format settings without explicitly
calling the plane disable in-between and we could endup keeping the
pixel normalizer enabled for formats which we don't require that.
This is causing crc mismatches in yuv formats and FIFO underruns in
planar formats like NV12. Fix this by updating the pixel normalizer
configuration based on the pixel formats explicitly during the plane
settings arm calls itself - enable it for FP16 and disable it for
other formats in HDR capable planes.
Jouni Högander [Tue, 27 Jan 2026 12:41:20 +0000 (14:41 +0200)]
drm/i915/psr: Use TRANS_PUSH to trigger frame change event
Now we have everything in place for triggering PSR "frame change" event
using TRANS_PUSH: use TRANS_PUSH for LunarLake and onwards.
v4:
- Added call to intel_vrr_psr_frame_change_enable call
- added setting LNL_TRANS_PUSH_PSR_PR_EN into intel_vrr_send_push
v3: use HAS_PSR_FRAME_CHANGE macro
v2: use AND instead of OR in intel_psr_use_trans_push
Jouni Högander [Tue, 27 Jan 2026 12:41:18 +0000 (14:41 +0200)]
drm/i915/psr: Do PSR exit on frontbuffer flush on LunarLake and onwards
We need to use intel_psr_exit in frontbuffer flush on LunarLake and
onwards if we want to move using trans push mechanism to trigger Frame
Change event.
Keep PSR1 and PSR2 HW tracking as it is for older platforms as this was
seen causing problems there.
Jouni Högander [Tue, 27 Jan 2026 12:41:17 +0000 (14:41 +0200)]
drm/i915/psr: Wait for idle only after possible send push
We are planning to move using trans push mechanism to trigger the Frame
Change event. In that case we can't wait PSR to idle before send push
happens. Due to this move wait for idle to be done after possible send push
is done.
This should be ok for Frame Change event triggered by register write as
well. Wait for idle is needed only for corner case where PSR is
transitioning into DEEP_SLEEP when Frame Change event is triggered. It just
has to be before wait for vblank. Otherwise we may have vblank before PSR
enters DEEP_SLEEP and still using old frame buffers for first frame after
wake up.
Jouni Högander [Tue, 27 Jan 2026 12:41:16 +0000 (14:41 +0200)]
drm/i915/display: Wait for vblank in case of PSR is using trans push
In case PSR uses trans push as a "frame change" event and we need to wait
vblank after triggering PSR "frame change" event. Otherwise we may miss
selective updates.
DSB skips all waits while PSR is active. Check push send is skipped as well
because trans push send bit is not reset by the HW if VRR is not enabled ->
we may start configuring new selective update while previous is not
complete. Avoid this by waiting for vblank after sending trans push.
Jouni Högander [Tue, 27 Jan 2026 12:41:15 +0000 (14:41 +0200)]
drm/i915/dsb: Set DSB_SKIP_WAITS_EN chicken bit for LunarLake and onwards
On LunarLake we are using TRANS_PUSH mechanism to trigger "Frame Change"
event. This way we have more control on when PSR HW is woken up. I.e. not
every display register write is triggering sending update. This allows us
setting DSB_SKIP_WAITS_EN chicken bit as well.
Jouni Högander [Tue, 27 Jan 2026 12:41:14 +0000 (14:41 +0200)]
drm/i915/vrr: Prepare to Use TRANS_PUSH mechanism for PSR frame change
On Lunarlake and onward it is possible to generate PSR Frame Change
event using TRANS_PUSH mechanism:
Ensure push is performed on flip if needed by PSR.
Don't use intel_psr_trigger_frame_change_event if PSR uses trans push as
Frame Change event: When not using trans push to generate Frame Change
event plane/pipe register writes are triggering the event. This is causing
problems when transiting to PSR active/idle and the event is coming in. To
tackle this we are waiting PSR to idle and using
intel_psr_trigger_frame_change_event to ensure PSR exit. If the Frame
change event is triggered after everything is configured (on trans push) we
don't need to worry about all this.
Ensure possible intel_vrr_tg_disable call is not overwriting
LNL_TRANS_PUSH_PSR_PR_EN.
v8:
- split adding intel_vrr_psr_frame_change_enable as a separate change
- update commit message
v7:
- HAS_PSR_FRAME_CHANGE macro moved to separate patch and renamed as
HAS_PSR_TRANS_PUSH_FRAME_CHANGE
- use intel_psr_use_trans_push instead of HAS_PSR_FRAME_CHANGE in
intel_psr_trigger_frame_change
- moved calling intel_vrr_psr_frame_change_enable away from this patch
v6:
- add HAS_PSR_FRAME_CHANGE macro
- use TRANS_PUSH in instead of TRAN_VRR_CTL
v5: use intel_psr_use_trans_push for intel_vrr_psr_frame_change_enable
v4:
- use rmw when enabling/disabling transcoder
- set TRANS_PUSH_EN conditionally in intel_vrr_send_push
- do not call intel_vrr_send_push from intel_psr_trigger_frame_change
- do not enable using TRANS_PUSH mechanism for PSR "Frame Change"
v3:
- use rmw when enabling/disabling
- keep LNL_TRANS_PUSH_PSR_PR_EN set always on LunarLake and onwards
v2: use intel_vrr_trans_push_enabled_set_clear instead of rmw
Jouni Högander [Tue, 27 Jan 2026 12:41:12 +0000 (14:41 +0200)]
drm/i915/vrr: Add helper for parsing value to be written into TRANS_PUSH
On Lunarlake and onwards it is possible to generate PSR "frame change"
event using TRANS_PUSH mechanism. As a preparation add new helper to parse
value to be written into TRANS_PUSH register. Setting
LNL_TRANS_PUSH_PSR_PR_EN is done in upcoming change.
Jouni Högander [Tue, 27 Jan 2026 12:41:11 +0000 (14:41 +0200)]
drm/i915/psr: Add intel_psr_use_trans_push to query if TRANS_PUSH is used
This is a preparation to start using trans push as a PSR "Frame Change"
event. It adds intel_psr_use_trans_push placeholder which return false for
now until we have everything in place.
Michał Grzelak [Thu, 29 Jan 2026 09:01:29 +0000 (10:01 +0100)]
drm/i915: move intel_gvt_init() level higher
Both initialisation and removal of GVT happen at different abstraction
levels. Hence caller of i915_driver_hw_probe() has no way of knowing
status of intel_gvt_init(). This can lead to an unbalanced number of
calls of intel_gvt_init() and intel_gvt_driver_remove() since GVT error
path is currently handled in i915_driver_probe(). One such scenario has
been seen with i915_driver_hw_probe() fault injection, which caused
double entry deletion and list corruption.
Move intel_gvt_init() up to i915_driver_probe(). Add out_cleanup_gvt
error path for removing gvt. Trigger it only after intel_gvt_init()
succeeded.
In case intel_gvt_init() failed, theoretically we should follow err_msi
error path. That is actually impossible since call to intel_gvt_init()
unconditionally returns 0, although it claims to return negative error
code on failure. Thus follow standard out_cleanup_hw error path on a
hypothetical future intel_gvt_init() failure. Remove err_msi label from
i915_driver_hw_probe() since intel_gvt_init() was the only user of it.
Jani Nikula [Wed, 28 Jan 2026 14:59:09 +0000 (16:59 +0200)]
drm/i915/gvt: drop dependency on intel_display_types.h
Avoid even accidental use of display details by dropping the include of
intel_display_types.h. We'll still have to include intel_dpll_mgr.h for
the DPLL IDs, but at least the surface is smaller.
Add duplicate defines of pipe_name() and port_name() to avoid depending
on display. They're trivial enough to be acceptable.
Jani Nikula [Wed, 28 Jan 2026 14:59:07 +0000 (16:59 +0200)]
drm/i915/display: move enum aux_ch to intel_display_limits.h
Move enum aux_ch from intel_display.h to intel_display_limits.h to avoid
having to include the former from gvt. This currently happens via
intel_display_types.h, which we can also drop in favour of
intel_display_limits.h in intel_gvt_mmio_table.c.
Jonathan Cavitt [Fri, 23 Jan 2026 17:09:15 +0000 (17:09 +0000)]
drm/i915/display: vcpi is always greater than zero
Static analysis issue:
intel_conn_to_vcpi currently checks and asserts vcpi >= 0, as grabbed
from payload->vcpi. But payload->vcpi is a u8, so this is always true.
Remove this unnecessary check.
While we're here, the jump statements in this function are largely
defunct now, so remove those as well.
Jani Nikula [Mon, 26 Jan 2026 11:29:25 +0000 (13:29 +0200)]
drm/{i915, xe}/pcode: move display pcode calls to parent interface
Call the parent driver pcode functions through the parent interface
function pointers instead of expecting both to have functions of the
same name.
In i915, add the interface to existing intel_pcode.[ch], while in xe
move them to new display/xe_display_pcode.[ch] and build it only for
CONFIG_DRM_XE_DISPLAY=y.
Do not add separate write and write_timeout calls in the
interface. Instead, handle the default 1 ms timeout in the
intel_parent.c glue layer.
This drops the last intel_pcode.h includes from display, and allows us
to remove the corresponding xe compat header.
Suraj Kandpal [Thu, 22 Jan 2026 04:48:59 +0000 (10:18 +0530)]
drm/i915/cx0: Rename intel_clear_response_ready flag
Rename the non static intel_clear_response_ready_flag to
intel_cx0_clear_response_ready_flag so that we follow the
naming standards of non static function.
Suraj Kandpal [Thu, 22 Jan 2026 04:48:58 +0000 (10:18 +0530)]
drm/i915/cx0: Clear response ready & error bit
Clear the response ready and error bit of PORT_P2M_MESSAGE_BUS_STATUS
before writing the transaction pending bit of
PORT_M2P_MSGBUS_CTL as that is a hard requirement. If not done
we find that the PHY hangs since it ends up in a weird state if left
idle for more than 1 hour.
Jani Nikula [Tue, 20 Jan 2026 15:45:41 +0000 (17:45 +0200)]
drm/{i915, xe}/dsb: move DSB buffer to parent interface
Move the DSB buffer handling to the display parent interface, making
display more independent of i915 and xe driver implementations.
Since the DSB parent interface is only called from intel_dsb.c, add the
wrappers there with smaller visibility instead of the usual
intel_parent.[ch], and using struct intel_dsb as the context parameter
for convenience.
Unfortunately, memset() being a macro in linux/fortify-string.h, we
can't use that as the function pointer name. dsb->memset() would be
using the macro and leading to build failures. Therefore, use .fill()
for the memset() functionality.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:36 +0000 (20:26 +0200)]
drm/i915: Clean up PCI config space reg defines
The PCI config space register defines in i915_drm.h are
a bit of a mess; Whitespace is all over the place, register
masks and values are defined in inconsistent ways.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:33 +0000 (20:26 +0200)]
drm/i915/crt: Use IS0_R instead of VGA_MIS_W
Use the proper IS0_R name for the VGA input status register 0, instead
of using the VGA_MIS_W alias which is meant for write accesses to the
same address. Yes, VGA registers are weird.
Ville Syrjälä [Tue, 9 Dec 2025 07:55:49 +0000 (09:55 +0200)]
video/vga: Add VGA_IS0_R
Add a proper name for the "Input status register 0" IO address.
Currently we have some code that does reads using the aliasing
VGA_MSR_W define, making it unclear what register we're
actually reading.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:30 +0000 (20:26 +0200)]
drm/i915/vga: Introduce intel_vga_{read,write}()
VGA register are rather special since they either get accessed
via the global IO addresses, or possibly through MMIO on
pre-g4x platforms. Wrap all VGA register accesses in
intel_vga_{read,write}() to make it obvious where they get
accessed.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:28 +0000 (20:26 +0200)]
drm/i915/de: Simplify intel_de_read8()
intel_de_read8() is only needed for VGA register MMIO access
by the CRT code on gen2/3. Remove the redundant wakelock stuff,
and add a platform check to make sure this won't get used on
any platform where MMIO VGA register accesses don't work.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:26 +0000 (20:26 +0200)]
drm/i915/vga: Stop trying to use GMCH_CTRL for VGA decode control
intel_gmch_vga_set_state() is a complete lie on ILK+ because
the GMCH_CTRL register is locked and can't actually be written.
But we still need to remove the iGPU from the VGA arbitration
on iGPU+dGPU systems, or else Xorg performance will tank due
to the constant VGA arbiter accesses.
For VGA memory decode we can't turn off the PCI_COMMAND
memory deocde as that would disable even normal MMIO.
Instead we can disable just the VGA memory decode via
the VGA MSR register. And we can do that just once
when disabling the VGA plane. That way we don't have
to touch VGA registers anywhere else.
We can also inform the arbiter that we're no longer decoding
VGA memory. This will stop the arbiter from disabling all
memory decode for the iGPU via PCI_COMMAND (and thus breaking
everything) whenever some other GPU wants to own the VGA memory
accesses.
For IO we can disable all IO decode via the PCI_COMMAND
register, except around the few VGA register accesses that
we need to do in intel_vga_disable(). Unfortunately we can't
disable IO decode permanently as it makes some laptops (eg.
Dell Latitude E5400) hang during reboot/shutdown. One option
would be to re-enable IO decode from the poweroff hooks, but
that won't help the sysrq emergency reboot/shutdown since it
won't call said hooks. So let's try to keep IO decode in its
original setting unless we really need to disable it to
exclude the GPU from VGA arbitration.
I suppose we could keep frobbing GMCH_CTRL on pre-ILK, but
it seems better to not do it since it has other side effects
such as changing the class code of the PCI device.
For discrete GPUs we'll rely on the bridge control instead.
projects / thirdparty / kernel / linux.git / log
