Julian Braha [Sat, 2 May 2026 19:19:32 +0000 (20:19 +0100)]
drm/i915: replace select with dependency for visible DEBUG_OBJECTS
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.
drm/i915: remove HAS_PCH_NOP() dependency from clock gating
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.
drm/i915/display: move HSW and BDW clock gating init to display
Move the HSW and BDW display clock gating programming into the display
code. In this case we need two different helpers, because the common
code between these two is split in the middle.
drm/i915/display: move GLK clock gating init to display
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().
drm/i915/display: move CFL clock gating init to display
Move the CFL/CML-specific display clock gating programming into
display intel_display_clock_gating.c, to remove more dependencies from
i915 to display registers.
Move the KBL-specific display clock gating programming into a
display intel_display_clock_gating.c, to remove more dependencies from
i915 to display registers.
Suraj Kandpal [Mon, 4 May 2026 10:11:18 +0000 (15:41 +0530)]
drm/i915/hdcp: Drop mgr->base.lock acquisition in intel_conn_to_vcpi()
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.
Suraj Kandpal [Mon, 4 May 2026 10:11:17 +0000 (15:41 +0530)]
drm/i915/hdcp: Use new MST topology state in intel_conn_to_vcpi()
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.
Jani Nikula [Thu, 30 Apr 2026 08:28:52 +0000 (11:28 +0300)]
drm/i915/display: move display funcs under modeset sub-struct
Move generic crtc-ish modeset related functions under a new modeset
sub-struct of struct intel_display. Rename struct intel_display_funcs to
intel_modeset_funcs to make it a little bit more specific. Remove the
funcs sub-struct.
The funcs sub-struct of struct intel_display seems unnecessary. Instead
of display->funcs.FEATURE, prefer display->FEATURE.funcs.
drm/i915/display: Avoid stale PIPE_SCANLINE values after crtc_enable
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.
drm/i915/psr: Disable Panel Replay on Dell XPS 16 DA16260 as a quirk
We are observing same problems with Dell XPS 16 DA16260 as we saw with XPS
14 DA16260. This device seem to have also LGD panel with same feature as in
XPS 14. Due to this disable Panel Replay as a quirk on this setup as well.
drm/i915/display: Use ceiling division for NV12 UV surface offset calculation
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)
drm/i915/dp: Add a helper to decide if AS SDP can be used
Add a helper that determines whether AS SDP can be used for the
current DP configuration. For now this is true only when the sink
supports AS SDP and VRR is enabled, but more conditions may be added
later.
v2:
- Rename to intel_dp_needs_as_sdp(). (Ville)
- Add a #FIXME documenting non-atomic of DP SDP updates. (Ville)
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.
Jani Nikula [Wed, 15 Apr 2026 11:51:03 +0000 (14:51 +0300)]
drm/i915/ddi: add wrapper for calling ->get_buf_trans() hook
Add intel_ddi_buf_trans_get() wrapper for calling the
encoder->get_buf_trans() hooks, allowing for a centralized place to
e.g. check for VBT overrides for the buf translations.
Ville Syrjälä [Thu, 16 Apr 2026 17:44:47 +0000 (20:44 +0300)]
drm/i915: Don't pass the framebuffer to low level pinning functions
Now that we have the pin_params the low level pinning code no
longer needs the entire framebuffer structure. The gem object
alone (along with the pin_params) is enough.
Ville Syrjälä [Thu, 16 Apr 2026 17:44:46 +0000 (20:44 +0300)]
drm/xe: Eliminate intel_fb_uses_dpt() call from __xe_pin_fb_vma()
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.
Ville Syrjälä [Thu, 16 Apr 2026 17:44:43 +0000 (20:44 +0300)]
drm/i915: Introduce pin_params.needs_physical
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.
Ville Syrjälä [Thu, 16 Apr 2026 17:44:41 +0000 (20:44 +0300)]
drm/i915: Extract intel_plane_needs_low_address()
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.
Add a new flag pin_params.neeeds_cpu_lmem_access so that the
low level pinning code doesn't need to peek into the display
driver's framebuffer structure.
Ville Syrjälä [Thu, 16 Apr 2026 17:44:39 +0000 (20:44 +0300)]
drm/i915: Extract intel_fb_needs_cpu_access()
Replace the naked "does the framebuffer have a clear color
plane?" checks with a more abstract helper that simply tells
us whether we require CPU access to the framebuffer's memory.
Ville Syrjälä [Thu, 16 Apr 2026 17:44:38 +0000 (20:44 +0300)]
drm/i915: Introduce struct intel_fb_pin_params
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).
Ville Syrjälä [Thu, 16 Apr 2026 17:44:37 +0000 (20:44 +0300)]
drm/xe/fb: Use the correct gtt view for remapped FBs
Use the proper gtt view from the plane state rather than always
assuming that it came directly from the FB. This is in the DPT
codepath so the view should currently always come from the FB,
but in the future we may also want per-plane remapping with DPT.
Ville Syrjälä [Wed, 15 Apr 2026 21:04:11 +0000 (00:04 +0300)]
drm/i915/reset: Disable execlist per-engine reset for display reset tests
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.
Expose the number of display resets performed in a new
"display_reset_count" debugfs file. kms_busy can use this to
confirm that the kernel actually took the full display reset path.
v2: Give the file an "intel_" namespace (Jani)
Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Testcase: igt/kms_busy/*-with-reset Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260415210411.24750-7-ville.syrjala@linux.intel.com
Ville Syrjälä [Wed, 15 Apr 2026 21:04:09 +0000 (00:04 +0300)]
drm/xe/display: Add init_clock_gating.h stubs
Add static inline stubs for init_clock_gating.h functions
so that we don't need ifdefs in the actual code. We already
have one in intel_display_power.c, and now I need to bring
over intel_display_reset.c.
Ville Syrjälä [Wed, 15 Apr 2026 21:04:08 +0000 (00:04 +0300)]
drm/i915/reset: Move pending_fb_pin handling to i915
Only i915 uses the pending_fb_pin counter to potentially whack
the GPU harder if the display gets nuked during a GPU reset.
Move the atomic counter into the i915 specific bits of code, so
that we don't need to worry about on the display side.
For some reason the overlay code kept the pending_fb_pin counter
elevated for longer than just for the pin, but from now on it'll
just cover the actual pinning part.
Ville Syrjälä [Wed, 15 Apr 2026 21:04:07 +0000 (00:04 +0300)]
drm/i915/reset: Reorganize display reset code
Stop returning the "is there a display?" status from
intel_display_reset_prepare(). I plan to move the pending_fb_pin
into the i915 code, so I need to make that determination already
before intel_display_reset_prepare() is called. Add a new
intel_display_reset_supported() function for that.
Ville Syrjälä [Wed, 15 Apr 2026 21:04:05 +0000 (00:04 +0300)]
drm/i915: Clear i915->display when no longer valid
Don't leave a stale i915->display pointer hanging around after
the display driver has been torn down. Apparently the gt code
calls into the reset codepaths after this, and if the display
pointer is still around we may try to access freed memory.
The whole teardown sequence here seems rather suspect. Why is
display done first and then everything else via the managed
release? Who the heck knows. Someone really needs to dig into
this stuff and figure out the proper init/cleanup sequence for
both i915 (real and mock) and xe...
Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260415210411.24750-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Changes have been introduced in Bspec regarding the Tx Swing level,
Tx pre/post coefficients. Update the Tx Swing Level and the Tx
pre/post-cursor co-effecients to incorporate these changes
Jani Nikula [Mon, 13 Apr 2026 08:16:09 +0000 (11:16 +0300)]
drm/i915/display: change pipe allocation order for discrete platforms
When big joiner is enabled, it reserves the adjacent pipe as the
secondary pipe. This happens without the user space knowing, and
subsequent attempts at using the CRTC with that pipe will fail. If the
user space does not have a coping mechanism, i.e. trying another CRTC,
this leads to a black screen.
Try to reduce the impact of the problem on discrete platforms by mapping
the CRTCs to pipes in order A, C, B, and D. If the user space reserves
CRTCs in order, this should trick it to using pipes that are more likely
to be available for and after joining.
Limit this to discrete platforms, which have four pipes, and no eDP, a
combination that should benefit the most with least drawbacks.
Ville Syrjälä [Fri, 10 Apr 2026 15:04:49 +0000 (18:04 +0300)]
drm/i915: Reject BIOS FB rotation in common code
Reject 90/270 degree rotated BIOS framebuffers in common
code. Currently skl_get_initial_plane_config() already rejects
these, but we may want to implement the missing parts there
so that skl_get_initial_plane_config() could be reused for
general plane state verification purposes.
90/270 degree rotated framebuffers require two completely
separate GGTT mappings (0 degree for the CPU, 270 degree
for the display engine), and the rest of the BIOS FB
takeover code is not prepared for that.
Ville Syrjälä [Fri, 10 Apr 2026 15:04:48 +0000 (18:04 +0300)]
drm/i915: Completely reject DPT BIOS FBs.
Our BIOS FB handling can't deal with DPT, and instead everything
just assumes a direct GGTT mapping. Reject any BIOS FB using DPT.
Most likely this should never happen anyway.
Ville Syrjälä [Fri, 10 Apr 2026 15:04:47 +0000 (18:04 +0300)]
drm/i915: Reject X/Y tiled BIOS FB if we don't have fenced regions
The CPU always needs linear view into the BIOS FB, and for X/Y tiled
buffers that is achieved by the use of a fenced region. If the
underlying driver doesn't support fenced regions then we can't keep
the X/Y tiled BIOS FB. i915 has fenced regions, xe does not.
Probably not a big deal since I don't think we've seen tiled BIOS
FBs outside of some MacBooks. See eg. commit d9a515867bdb
("drm/i915/gen9+: Fix initial readout for Y tiled framebuffers").
Ville Syrjälä [Fri, 10 Apr 2026 15:04:46 +0000 (18:04 +0300)]
drm/i915: Reject tile4 BIOS FB
There is no such thing as tile4 fenced region, so there is no
way to have a linear view of the tile4 framebuffer for the CPU.
Thus we should never encounter a tile4 BIOS FB, but if we somehow
do, then reject it.
Ville Syrjälä [Fri, 10 Apr 2026 15:04:45 +0000 (18:04 +0300)]
drm/i915: Use a 1 second timeout for the polling vblank wait
40 msec seems like a very random number for a vblank wait timeout.
Considering ~24Hz display modes are definitely a thing this seems
way too low. Just bump it to a full second to match what we've been
using for normal vblank waits.
Ville Syrjälä [Fri, 10 Apr 2026 15:04:44 +0000 (18:04 +0300)]
drm/i915: Move initial plane vblank wait into display code
The initial plane vblank wait operates on display registers,
so it really belongs in the display code proper. Move it there.
We can use intel_parent_irq_enabled() to determine if we can
rely on interrupts or not.
On average we should end up waiting half a frame here, so the
polling interval can be fairly long. 1 ms (which actually
makes poll_timeout_us() use ~250-1000 usec) seems good enough
to me.
Ville Syrjälä [Fri, 10 Apr 2026 15:04:43 +0000 (18:04 +0300)]
drm/i915: Make plane_config->fb a struct drm_framebuffer*
There's no need to use the intel specific struct intel_framebuffer*
type in the initial plane_config structure. Just make it a
struct drm_framebuffer*.
I think the fewer special types we expose in the interface (even
if just pointers) the better. At least then there is no need to
change the interface definition if we ever change the internal
types. And I hope that the existing examples will generally
encourage people to not expose more special types unless
absolutely necessary.
Ville Syrjälä [Fri, 10 Apr 2026 15:04:42 +0000 (18:04 +0300)]
drm/i915: Don't pass the whole plane_config to initial_plane_phys()
initial_plane_phys() only needs the 'base' (== ggtt virtual address)
from the plane_config. Stop passing the whole plane_config and just
pass the 'base'.
Ville Syrjälä [Fri, 10 Apr 2026 15:04:41 +0000 (18:04 +0300)]
drm/i915: Remove 'mem' and 'phy_base' from struct intel_initial_plane_config
The 'mem' and 'phy_base' members of struct intel_initial_plane_config
only exist to be passed from initial_plane_phys() to its sole caller.
Just return them via function arguments.
Ville Syrjälä [Fri, 10 Apr 2026 15:04:40 +0000 (18:04 +0300)]
drm/i915: Introduce sanity to the plane_config pointer vs. array thing
The "plane_config" vs. "plane_configs" naming difference is very
subtle, making it far too easy to use the wrong thing by accident.
Introduce a separate type for the array, making it impossible to
pass in the wrong thing. And while at it name the variable
"all_plane_configs" to help the poor reader make sense of things.
The .config_fini() prototype also mistakenly used the plural
form despite only taking in a singular plane_config. So fix that
one up as well.
Ville Syrjälä [Thu, 9 Apr 2026 10:15:39 +0000 (13:15 +0300)]
drm/i915/dp: Make the RGB fallback for "4:2:0 only" modes the last resort
Currently we take the Hail Mary RGB fallback for "4:2:0 only" modes
already during the first pass when respect_downstream_limits==true.
It seems better to try everything else first (like ignoring TMDS
clock limits) while still preferring 4:2:0, and only if everything
else has failed fall back to RGB.
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-10-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Ville Syrjälä [Thu, 9 Apr 2026 10:15:38 +0000 (13:15 +0300)]
drm/i915/hdmi: Make the RGB fallback for "4:2:0 only" modes the last resort
Currently we take the Hail Mary RGB fallback for "4:2:0 only" modes
already during the first pass when respect_downstream_limits==true.
It seems better to try everything else first (like ignoring TMDS
clock limits) while still preferring 4:2:0, and only if everything
else has failed fall back to RGB.
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-9-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Ville Syrjälä [Thu, 9 Apr 2026 10:15:37 +0000 (13:15 +0300)]
drm/i915/dp: Validate sink format in .mode_valid()
Make sure the sink supports our chosen sink format. I suppose it
might be at least possible that some PCONs might not snoop the EDID
hard enough and filter out all the modes that they should.
Also if we ever want to add a similar "force DVI" knob to DP
outputs that we have for native HDMI, we'd need to manually
get rid of anything DVI sinks can't handle.
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-8-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Ville Syrjälä [Thu, 9 Apr 2026 10:15:35 +0000 (13:15 +0300)]
drm/i915/dp: Validate "4:2:0 also" modes twice
Currently we only validate "4:2:0 also" modes as RGB. But
if that fails we could perhaps still use the mode in with
4:2:0 output. All we have to do is retry the validation with
the different sink format.
So far we did the double validation only so far as it affects
PCON TMDS clock limits. But validating everything twice seems
a bit more sane.
Note that intel_dp_output_format() might still end up picking
RGB for the actual output format (and letting PCON deal with
the YCbCr conversion). So I suppose we could still fail the
validation due to that, and forcing even the output format
to 4:2:0 might solve it on a third try. But we'd need the
same fallback logic in intel_dp_compute_config(). For now
this seems sufficient.
v2: Pass output_format to intel_dp_mode_min_link_bpp_x16()
Add TODO about remaining issues
Nuke intel_dp_sink_format()
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-6-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Ville Syrjälä [Thu, 9 Apr 2026 10:15:32 +0000 (13:15 +0300)]
drm/i915/hdmi: Restructure the sink/output format selection
intel_hdmi_compute_output_format() is a bit of a mess. Try to
restructure it into a more readable form.
Right now we basically have two main code paths:
- YCbCr 4:2:0 only modes
- everything else including YCbCr 4:2:0 also modes
Those two basically do the same two steps (try 4:2:0 and try 4:4:4)
but in opposite orders. Let's write that out in a more explicit
if-else form. And since I'm running out of function names I'll
rename the function with that high level logic into
intel_hdmi_compute_formats() and it will call (the new)
intel_hdmi_compute_output_format() with an explicit sink_format
as needed.
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-3-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Ville Syrjälä [Thu, 9 Apr 2026 10:15:31 +0000 (13:15 +0300)]
drm/i915/hdmi: Add missing intel_pfit_mode_valid() for 4:2:0 also modes
intel_hdmi_mode_valid() is calling intel_pfit_mode_valid() only
on the first attempt (4:2:0 for "4:2:0 only" modes, 4:4:4 for
everything else). Add the call also for the "4:2:0 also" modes case
so that we actually know the pipe scaler can actually produce the
4:2:0 output.
Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260409101539.22032-2-ville.syrjala@linux.intel.com Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
The entire crtc_state is zeroed by default, there is no need
to fiddle with crtc_state->has_pch_encoder unless we are actually
dealing with a port on the PCH (which we never are for DP MST).
Ville Syrjälä [Thu, 9 Apr 2026 10:08:40 +0000 (13:08 +0300)]
drm/i915/mst: Call intel_pfit_compute_config() for sharpness filter
The sharpness filter property is on the CRTC (as opposed to the
connector) so the expectation is that it's usable on all output
types. Since the sharpness filter is now fully integrateds into
the normal pfit code intel_pfit_compute_config() must be called
from the encoder .compute_config() on all relevant output types.
Sharpness filter is supported on LNL+ so only HDMI and DP SST/MST
outputs are actually relevant. I already took care of HDMI and
DP SST, but (as usual) forgot about DP MST. Add the missing
intel_pfit_compute_config() call to make the sharpness filter
operational on DP MST as well.
Ville Syrjälä [Wed, 8 Apr 2026 15:57:44 +0000 (18:57 +0300)]
drm/i915: Walk crtcs in pipe order
Currently our crtcs are registered in pipe order, and thus
all the for_intel_crtc*() iterators walk the crtcs in pipe
order. There are a bunch of places that more or less depend
on that. Eg. during plane updates and such we want joined
pipes to be processed back-to-back to give a better chance
of an atomic update across the whole set.
When we start to register crtcs in a different order we don't
want to change the order in which the pipes get handled.
Decouple the for_each_intel_crtc*() iterators from the crtc
registration order by using a separate list which will be
sorted by the pipe rather than the crtc index.
We could probably use a simple array or something, but that
would require some kind of extra iterator variable for the
macros, and thus would require a lot more changes. Using
a linked list keeps the fallout minimal. We can look at
using a more optimal data structure later.
I also added this extra junk to the atomic state iterators:
"(__i) = drm_crtc_index(&(crtc)->base), (void)(__i)"
even though the macro itself no longer needs the "__i" iterator.
This in case the "__i" is used by the caller, and to
avoid compiler warnings if it's completely unused now.
Ville Syrjälä [Wed, 8 Apr 2026 15:57:43 +0000 (18:57 +0300)]
drm/i915/joiner: Make joiner "nomodeset" state copy independent of pipe order
Currently the joiner primary->secondary hw state copy still happens from
the main compute_config loop alongside the primary uapi->hw state copy.
The primary uapi->hw state copy must therefore happen first, or else
we'll end up copying stale junk into the secondary.
We have a WARN in intel_atomic_check_joiner() to make sure the CRTCs
will be walked in the correct order. The plan is to reoder the CRTCs,
which would mess up the order, unless we also adjust the iterators
to keep the pipe order. The actual plan is to do both, so technically
we should be able to just remove the WARN and call it a day.
But relying on the iteration order like this is fragile and confusing,
so let's move the "nomodeset" joiner state copy into the later loop
where the "modeset" state copy is also done. The first loop having
completely finished, we are guaranteed to have up to date hw state
on the primary when we do the copy to the secondary.
Ville Syrjälä [Tue, 7 Apr 2026 15:50:53 +0000 (18:50 +0300)]
drm/i915/fb: Use intel_fb_needs_pot_stride_remap() in intel_fb_view_init()
Replace the open coded intel_fb_needs_pot_stride_remap() check
inside intel_fb_view_init() with the real thing.
The current check doesn't have the intel_fb_uses_dpt() in there, but
that is the only situation when we use the remapped view, and thus
was always implied.
Ville Syrjälä [Tue, 7 Apr 2026 15:50:48 +0000 (18:50 +0300)]
drm/i915/vma: Add helpers to check GTT view type
I915_GTT_VIEW_ROTATED is going away and being replaced by just
I915_GTT_VIEW_REMAPPED, so we're going to need another way to
determine if the view is rotated or not (since width/height
will need to be swapped when operating on the destination
coordinate space). Provide small helper functions to hide
such implementation details from most of the code using GTT views.
Ville Syrjälä [Tue, 24 Mar 2026 13:48:43 +0000 (15:48 +0200)]
drm/i915/wm: Allow SAGV with multiple pipes on pre-icl
There was never any documented reason for limiting SAGV to
single active pipe configuration on pre-icl. Allow SAGV
with multiple active pipes.
At least my CFL NUC seems happy with this when using
multiple displays. The machine actually has working
SAGV because the memory clock can be observed changing
via SA_PERF_STATUS/mchbar:0x5918.
Ville Syrjälä [Tue, 24 Mar 2026 13:48:42 +0000 (15:48 +0200)]
drm/i915/wm: Reduce copy-pasta in skl_print_plane_wm_changes()
skl_print_plane_wm_changes() is rather ugly with the copy-pasted
massive printk arguments. Reduce the duplication a bit by defining
a few FMT/ARG macros. Still ugly, but perhaps a bit less fragile.
Ville Syrjälä [Tue, 24 Mar 2026 13:48:37 +0000 (15:48 +0200)]
drm/i915/wm: Consolidate SAGV pipe active/interlace checks to common code
There are no differences between the platforms when
considering whether SAGV can be used when the pipe is
inactive or using an interlaced mode. Consolidate the
checks to common code.
Note that we weren't even checking for interlaced modes
on TGL+, but since we've previously soft defeatured
interlaced modes on TGL+ that was more or less fine.
The hardware does still have the capability though,
and in case we ever decide to resurrect it having the
check seems like a good idea.
Ville Syrjälä [Tue, 24 Mar 2026 13:48:35 +0000 (15:48 +0200)]
drm/i915/wm: Reject SAGV consistently when block_time_us==0
We have three ways for the platform to indicate that
SAGV is not supported:
- pcode returns zero block time
- pcode returns only a single QGV point (icl+)
- pcode rejects the SAGV enable/disable command (pre-icl)
We don't currently consider all those factors when computing
pipe_sagv_reject, meaning we might still try to enable
SAGV when we should not.
I think one plausible scenario is when pcode returns a
zero block time, and all the pipes are disabled. In
that case intel_crtc_can_enable_sagv() will return true
for all pipes, and thus we might try to enable SAGV
despite pcode indicating that it's not supported.
Make sure pipe_sagv_reject will consistently reject
SAGV when our cached block time is zero. That will cover
all the aforementioned mechanisms by which SAGV can be
disabled.
Jani Nikula [Mon, 30 Mar 2026 13:02:36 +0000 (16:02 +0300)]
drm/i915/display: switch to including common step file directly
Instead of using the proxy intel_step.h in display, just include the
common step file directly where needed. This allows us to remove the
compat intel_step.h header.
__intel_dmc_wl_release() schedules delayed work which releases the DMC
wakelock after a fixed timeout of 50 ms. Until the delayed work runs,
the wakelock remains held and prevents entry into deeper DC states.
Reduce DMC_WAKELOCK_HOLD_TIME from 50 ms to 5 ms.
This should allow the system to enter deeper DC states sooner once MMIO
activity settles down.
Changes in v2:
- Drop detailed explanation from commit message
and keep it concise (Suraj Kandpal, Luca Coelho)
Ville Syrjälä [Tue, 7 Apr 2026 18:30:15 +0000 (21:30 +0300)]
drm/i915/dp: Don't use DP link min bpp for the FRL link bandwidth check
intel_dp_mode_min_link_bpp_x16() gives us the min bpp for the
DP link before the PCON, however intel_dp_mode_valid_downstream()
is trying to check for sufficient bandwidth on the HDMI FRL link
after the PCON. So the use of intel_dp_mode_min_link_bpp_x16() here
is incorrect.
Presumably even with FRL HDMI still can't go below 8bpc, so we should
just use that to give us the minimum required FRL bandwidth. And this
needs to account for the sink format (for 4:2:0 sub-sampling) since
that is what will be flowing over the HDMI link.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260407183015.16256-1-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Ville Syrjälä [Tue, 7 Apr 2026 17:52:43 +0000 (20:52 +0300)]
drm/i915/casf: Integrate the sharpness filter properly into the scaler code
The sharpness filter is just a special mode of the pipe scaler.
It doesn't warrant all this special casing everywhere. Just
integrate it properly into the scaler code so that it's treated
no different from the other pipe scaler uses (scaling,centering,
YCbCr 4:2:0 output).
projects / thirdparty / kernel / linux.git / log
