Currently, most callers of intel_panel_mode_valid() also call
intel_panel_fixed_mode(). This is done either to check for the presence of
a fixed mode for the connector or to get the clock of the fixed mode, which
is then compared against the max dotclock for the pipe.
Since intel_panel_mode_valid() already calls intel_panel_fixed_mode()
internally, we can avoid yet another call to intel_panel_fixed_mode() from
the caller.
Remove the redundant call to intel_panel_fixed_mode() in mode_valid paths.
To get the clock for the fixed mode, extend the helper
intel_panel_mode_valid() to accept 'target_clock' as an out param.
The 'target_clock' can then be used by the callers to check against the
max dotclock.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260430131220.3891497-3-ankit.k.nautiyal@intel.com
intel_hdcp_required_content_stream() walks every connector on the
digital port to populate hdcp_port_data->streams[]. The only filter is
connector_status_disconnected, which reflects physical presence on the
MST topology, not whether the connector currently drives a stream.
On a multi-sink MST setup where only a subset of sinks are modeset,
the loop can pick a sibling MST connector that is connected but has
no active CRTC / VC payload. intel_conn_to_vcpi() then logs "MST
Payload not present" and returns 0, and the bogus StreamID=0 is
written to the repeater in RepeaterAuth_Stream_Manage (DPCD 0x693F0).
Authentication completes, but the repeater shortly raises
LINK_INTEGRITY_FAILURE (RxStatus 0x69493 bit4) because the StreamID
does not match any stream on its input. The HDCP check work then
tears the link down, the Content Protection property drops back to
DESIRED, and userspace observes a spurious HDCP enable failure.
Filter the connector iteration to only those with a CRTC assigned in
the new atomic state, so intel_conn_to_vcpi() is called for the
connector actually being enabled and reads its real VCPI from the MST
topology state.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Link: https://patch.msgid.link/20260505094022.4064256-1-suraj.kandpal@intel.com
DRM_I915_SW_FENCE_DEBUG_OBJECTS currently selects DEBUG_OBJECTS even though
DEBUG_OBJECTS is visible to users. Other config options use 'depends on'
for DEBUG_OBJECTS, so let's do the same here.
This select-visible Kconfig misusage was detected by Kconfirm, a static
analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://patch.msgid.link/20260502191932.4491-1-julianbraha@gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
intel_pch_init_clock_gating() already handles unsupported PCH types,
including PCH_NOP, by doing nothing.
Drop the explicit HAS_PCH_NOP() check from the IVB clock gating
path and always call the display helper directly. This removes one
more direct dependency on display-side PCH macros from
intel_clock_gating.c.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-9-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move the GLK-specific display clock gating programming into display
intel_display_clock_gating.c, to remove more dependencies from i915 to
display registers.
Now that all remaining Gen9-family callers moved into display, we can
move the shared Gen9 display clock gating helper into display and
remove the old local helper from intel_clock_gating.c.
Additionally, the SKL_DE_COMPRESSED_HASH_MODE programming was
protected by HAS_LLC(), but that's incidental, because in Gen9
platforms, only SKL and KBL, for which this workaround applies, have
LLC(). In order not to use HAS_LLC() in display code, we can simply
remove this check from the generic Gen9 function and move the
SKL_DE_COMPRESSED_HASH_MODE programming to the KBL and SKL specific
functions. And, intentionally or not, CFL and CML were also using
this workaround, because they also have LLC, even though the comments
were only mentioning SKL and KBL. In order not to change anything
functionally with this patch, the workaround was also added to
intel_display_cfl_init_clock_gating().
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-6-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Now that intel_conn_to_vcpi() reads the MST topology state via
drm_atomic_get_new_mst_topology_state(), the topology state belongs
to this atomic commit and is already serialized through the atomic
state's private object machinery. There is no need to additionally
take mgr->base.lock here.
Taking it from the HDCP enable path in commit_tail with
state->base.acquire_ctx is also unsafe: by this point the
acquire_ctx is no longer in a state where new modeset locks may be
acquired through it, which produces a modeset-lock splat on MST +
HDCP. Drop the drm_modeset_lock() call.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Link: https://patch.msgid.link/20260504101117.3619984-3-suraj.kandpal@intel.com
intel_conn_to_vcpi() runs from the HDCP enable path in commit_tail
and looks up the VCPI via mgr->base.state. When an ALLOCATE_PAYLOAD
is being driven on the mgr just before HDCP enable, that payload
list is being mutated in place, so the lookup can miss the port and
trip drm_WARN_ON(!payload), causing HDCP to be programmed with
VCPI 0.
Use drm_atomic_get_new_mst_topology_state() to read the topology
state attached to this atomic commit (stable, decided in
atomic_check), and bail out cleanly when no topology state or
payload is present for this port instead of WARNing.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Tested-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com>
Link: https://patch.msgid.link/20260504101117.3619984-2-suraj.kandpal@intel.com
When a CRTC is moved to a different transcoder (e.g. on DP-MST stream
allocation), PIPE_SCANLINE and PIPE_FRMCNT can return values latched
from the previous transcoder/mode for up to one vblank period after
the new pipe is enabled. The vblank evasion code in
intel_pipe_update_start()/end() then samples a stale or boundary
scanline and the frame counter ticks during the critical section,
producing diagnostic errors of the form:
[243.348405] xe 0000:00:02.0: [drm] *ERROR* Atomic update failure on
pipe B (start=300 end=301) time 61 us, min 2128, max 2161, scanline
start 1200, end 2165
[248.536260] xe 0000:00:02.0: [drm] *ERROR* Atomic update failure on
pipe B (start=561 end=562) time 61 us, min 2128, max 2161, scanline
start 2162, end 2167
Here "scanline start 1200" is the vblank_start of a previously
programmed mode on a different transcoder, while "2162" is the current
mode's vblank_start sampled before any real frame has been emitted.
Both indicate a stale read rather than a real evasion miss.
Wait for one vblank after crtc_enable() to give the new transcoder a
chance to start producing live PIPE_SCANLINE/FRMCNT values before any
subsequent atomic commit enters the vblank evasion section. This adds
at most one frame of latency on modeset, which is invisible to users.
Reproduced with igt@kms_rotation_crc@sprite-rotation-180 on a DP-MST
sink; with this patch the failures no longer occur.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Pranay Samala <pranay.samala@intel.com>
Link: https://patch.msgid.link/20260429042650.3335718-1-suraj.kandpal@intel.com
For LNL+, odd source size and panning for YUV 422/420 surfaces is
supported. However, it requires the UV (chroma) surface Start X/Y and
width/height to be calculated as ceiling(half of Y plane value) rather
than floor.
The current code uses (>> 17) which combines the U16.16 fixed-point to
integer conversion (>> 16) with a divide-by-2 for chroma subsampling
(>> 1) into a single floor division. For odd Y plane values this
produces an off-by-one error in the UV plane offset.
On Android systems we see PLANE ATS fault when NV12 overlays are
used with odd source dimensions:
[ 126.854200] xe 0000:00:02.0: [drm:intel_atomic_setup_scaler [xe]] [CRTC:148:pipe A] attached scaler id 0.0 to PLANE:33
[ 126.854617] xe 0000:00:02.0: [drm:skl_update_scaler [xe]] [CRTC:148:pipe A] scaler_user index 0.0: staged scaling request for 1279x719->1340x753
[ 126.854837] xe 0000:00:02.0: [drm:intel_plane_atomic_check [xe]] UV plane [PLANE:33:plane 1A] using Y plane [PLANE:123:plane 4A]
[ 126.854926] xe 0000:00:02.0: [drm] *ERROR* [CRTC:148:pipe A] PLANE ATS fault
With Y plane width 1279:
floor(1279/2) = 639 (current)
ceil(1279/2) = 640 (required)
Introduce fp_16_16_div2() and fp_16_16_to_int_ceil() helpers to cleanly
separate the two operations: first halve the U16.16 fixed-point value
for chroma subsampling (staying in fixed-point domain), then convert
to integer with ceiling rounding.
v2: Use DIV_ROUND_UP(value, 1 << 17) to preserve sub-pixel precision
while making the ceiling division readable (Jani, Uma)
v3: Split into two helpers - fp_16_16_div2() for fixed-point division
by 2 and fp_16_16_to_int_ceil() for ceiling conversion to integer,
cleanly separating chroma subsampling from fixed-point to integer
conversion (Jani)
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patch.msgid.link/20260415165849.187693-1-vidya.srinivas@intel.com
Change the drm_err to drm_dbg_kms when we fail to read the FEC
capability. This is mainly because this is called from intel_dp_detect.
Which ends up in race more frequently in case of MST scenarios,
when we are disabling streams but the downstream Dock still sends
signals which causes intel_dp_detect to be invoked which has DPCD
reads. These pass until the Transcoder and DPLL go down causing
AUX to go down too. At this point AUX Timeouts are expected and not
an issue. But this drm_err gets flagged in CI causing noise even
for passing scenarios.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patch.msgid.link/20260423080355.2744117-1-suraj.kandpal@intel.com
Move the intel_fb_uses_dpt() out from __xe_pin_fb_vma() into
intel_plane_pin_fb() so that we don't do have display stuff
that deep in the pinning code.
And intel_fb_pin_to_ggtt() can just say "this does not need DPT"
always since it's specifically about pinning the fb into GGTT.
The previous logic here was kinda insane with the high level code
assuming GGTT, and low level code potentially deciding otherwise.
In practice it should have been fine because intel_fb_pin_to_ggtt()
only gets used from the initial_plane code, and there we are
not supposed to be have a framebuffer that needs DPT.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Add a new flag pin_params.needs_physical to inform the pinning
code that the display needs a physical address and not GGTT
address.
This isn't strictly necessary as the current phys_alignment!=0
check is enough in practice. But theoretically one could have
needs_physical==true without any alignment requirements. And
having an explicit flag feels a bit less magical.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Extract the naked "gmch? -> need a low ggtt address" check into
a more descriptive helper (intel_plane_needs_low_address()).
The goal being to eliminate all display specific stuff from the
low level pinning code.
The actual implementation still abuses PIN_MAPPABLE to achieve
this goal. I'm not entire convinced that this whole thing even
needs to exist, and the original issue wasn't just caused by
some other bug. But no time to dig into it right now, so let's
keep going.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We need to pass a lot of information between the display driver
and the core driver to get framebuffers mapped into GGTT/DPT
correctly. Rather than passing around a swarm of integers and
boolean as function arguments, let's collect it all into a
structure (struct intel_fb_pin_params).
Start by moving the gtt view, alignment, phys_alignment,
and vtd_guard there. Going forward additional things need
to added as well (mainly various boolean flags).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260416174448.28264-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The display reset only happens from the full reset path. We must
therefore force execlist submission to always take the full reset
path and not the per-engine reset path. Currently the display
reset tests are in fact not testing display resets at all on
platforms using execlist submission. Ring submission and GuC
submission always take the full path anyway.
Also disable the engine reset inside __intel_gt_set_wedged() so
that we simulate the intel_gt_gpu_reset_clobbers_display() behavior
as closely as possible also when taking the full wedge path.
The slight race between the separate intel_display_reset_test()
calls in the overall reset path is harmless. kms_busy will keep
the modparam fixed during the test, and even if someone were to
fiddle with the modparam manually nothing bad should happen if
the calls return different values.
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-8-ville.syrjala@linux.intel.com
