Ville Syrjälä [Thu, 26 Mar 2026 11:18:13 +0000 (13:18 +0200)]
drm/i915/dsi: Fill BLLPs with blanking packets if requested
TGL/ADL DSI can be configured to fill all BLLPs with blanking
packets. Currently we enable that always, but the VBT actually
tells us whether this is desired or not. Hook that up.
Ville Syrjälä [Thu, 26 Mar 2026 11:18:12 +0000 (13:18 +0200)]
drm/i915/dsi: Make 'clock_stop' boolean
The DSI 'clock_stop' parameter is a boolean, so use a real
'bool' for it. And pimp the debug print while at it.
Note that we also remove the incorrect negation of the value
in the debug print. That has been there since the code was
introduced in commit 2ab8b458c6a1 ("drm/i915: Add support for
Generic MIPI panel driver"). An earlier version of the patch
https://lore.kernel.org/intel-gfx/1397454507-10273-5-git-send-email-shobhit.kumar@intel.com/
got it right, but looks like it got fumbled while dealing
with other review comments.
Ville Syrjälä [Thu, 26 Mar 2026 11:18:10 +0000 (13:18 +0200)]
drm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode
Stop adjusting the horizontal timing values based on the
compression ratio in command mode. Bspec seems to be telling
us to do this only in video mode, and this is also how the
Windows driver does things.
This should also fix a div-by-zero on some machines because
the adjusted htotal ends up being so small that we end up with
line_time_us==0 when trying to determine the vtotal value in
command mode.
Note that this doesn't actually make the display on the
Huawei Matebook E work, but at least the kernel no longer
explodes when the driver loads.
Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12045 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260326111814.9800-2-ville.syrjala@linux.intel.com Fixes: 53693f02d80e ("drm/i915/dsi: account for DSC in horizontal timings") Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Dell seems to be changing device ID even within same device model. Due to
this we need to ignore device ID when applying quirk for Dell XPS 14 DA14260. Do this by adding DEVICE_ID_ANY and assign it to Dell XPS 14 DA14260 quirk. Also apply the quirk only for eDP Panel Replay.
Fixes: 45c77d4bf8d4 ("drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk") Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260320080403.1396926-1-jouni.hogander@intel.com
Luca Coelho [Tue, 24 Mar 2026 08:04:27 +0000 (10:04 +0200)]
drm/i915: move LPT clock gating init into intel_pch
Move the LPT PCH clock gating programming into
intel_pch_init_clock_gating() and switch the corresponding
Haswell/Broadwell callers to the display-specific code.
Ville Syrjälä [Mon, 23 Mar 2026 09:43:04 +0000 (11:43 +0200)]
drm/i915/de: Implement register polling in the display code
The plan is to move all the mmio stuff into the display code itself.
As a first step implement the register polling in intel_de.c.
Currently i915 and xe implement this stuff in slightly different
ways, so there are some functional changes here. Try to go for a
reasonable middle ground between the i915 and xe implementations:
- the exponential backoff limit is the simpler approach taken
by i915 (== just clamp the max sleep duration to 1 ms)
- the fast vs. slow timeout handling is similar to i915 where
we first try the fast timeout and then again the slow timeout
if the condition still isn't satisfied. xe just adds up the
timeouts together, which is a bit weird.
- the atomic wait variant uses udelay() like xe, whereas i915
has no udelay()s in its atomic loop. As a compromise go for a
fixed 1 usec delay for short waits, instead of the somewhat
peculiar xe behaviour where it effectively just does one
iteration of the loop.
- keep the "use udelay() for < 10 usec waits" logic (which
more or less mirrors fsleep()), but include an explicit
might_sleep() even for these short waits when called from
a non-atomic intel_de_wait*() function. This should prevent
people from calling the non-atomic functions from the wrong
place.
Eventually we may want to switch over to poll_timeout*(),
but that lacks the exponential backoff, so a bit too
radical to change in one go.
v2: Initialize ret in intel_de_wait_for_register() to avoid a
warning from the compiler. This is actually a false positive
since we always have fast_timeout_us!=0 when slow_timeout_us!=0,
but the compiler can't see that
Ville Syrjälä [Fri, 13 Mar 2026 11:10:27 +0000 (13:10 +0200)]
drm/i915/de: Move intel_de_wait*() into intel_de.c
intel_de_wait*() end up doing quite a bit of stuff, so the one
function call overhead from them seems insignificant. Move the
implementation intel_de.c.
Ville Syrjälä [Fri, 13 Mar 2026 11:10:26 +0000 (13:10 +0200)]
drm/i915/de: Introduce intel_de.c and move intel_de_{read,write}8() there
intel_de_{read,write}8() aren't performance critical so having them
as static inline is pointless. Introduce intel_de.c and move the
implementation there.
Mika Kahola [Thu, 12 Mar 2026 08:06:57 +0000 (08:06 +0000)]
drm/i915/lt_phy: Replace crtc compute clock
The existing DPLL compute clock callback for the XE3PLPD platform
(`xe3plpd_crtc_compute_clock`) was specific to that platform. Replace it
with the more generic Haswell (`hsw_crtc_compute_clock`) implementation
so that the compute clock path does not rely on the XE3PLPD hook.
Mika Kahola [Thu, 12 Mar 2026 10:14:15 +0000 (10:14 +0000)]
drm/i915/lt_phy: Enable dpll framework for xe3plpd
xe3plpd platform is supported by dpll framework remove a separate
check for hw comparison and rely solely on dpll framework
hw comparison.
Finally, all required hooks are now in place so initialize
PLL manager for xe3plpd platform and remove the redirections
to the legacy code paths for clock enable/disable as well as
state mismatch checks that are no longer needed.
Mika Kahola [Thu, 12 Mar 2026 08:06:55 +0000 (08:06 +0000)]
drm/i915/lt_phy: Remove LT PHY specific state verification
Remove LT PHY specific state verification as DPLL framework
has state verification check.
v2: Reuse intel_lt_phy_pll_compare_hw_state() as only config[0]
and config[0] parameters are reliable with LT PHY (Suraj)
v3: Rephrase handling of LT PHY case when verifying the state (CI)
v4: Fix checkpatch warning of line length exceeding 100 columns
Add the PLL hooks for the TBT PLL on xe3plpd. These are simple stubs
similar to the TBT PLL on earlier platforms, since this PLL is always
on from the display POV - so no PLL enable/disable programming is
required as opposed to the non-TBT PLLs - and the clocks for different
link rates are enabled/disabled at a different level, via the
intel_encoder::enable_clock()/disable_clock() interface.
Mika Kahola [Thu, 12 Mar 2026 08:06:50 +0000 (08:06 +0000)]
drm/i915/lt_phy: Add .disable_clock hook on DDI
Add new pll_disable_clock functions so that they can be
hooked up to dpll->disable. This is just a wrapper over
the exitisting intel_xe3plpd_pll_disable to make it
compatible With dpll->disable function
v2: Revise commit message (Suraj)
Drop wrapper for TBT clock disabling and reuse
intel_mtl_pll_disable_clock() for DDI clock
disabling hook (Suraj)
Mika Kahola [Thu, 12 Mar 2026 08:06:46 +0000 (08:06 +0000)]
drm/i915/lt_phy: Add xe3plpd .get_hw_state hook
Add .get_hw_state hook to xe3plpd platform for dpll framework
and update intel_lt_phy_pll_readout_hw_state() function
accordingly to support dpll framework.
Mika Kahola [Thu, 12 Mar 2026 08:06:44 +0000 (08:06 +0000)]
drm/i915/lt_phy: Add xe3plpd .dump_hw_state hook
Add .dump_hw_state function pointer for xe3plpd platform
to support dpll framework. While at it, switch to use
drm_printer structure to print hw state information.
Mika Kahola [Thu, 12 Mar 2026 08:06:37 +0000 (08:06 +0000)]
drm/i915/lt_phy: Refactor LT PHY PLL handling to use explicit PLL state
The LT PHY implementation currently pulls PLL and port_clock
information directly from the CRTC state. This ties the PHY
programming logic too tightly to the CRTC state and makes it
harder to clearly express the PHY’s own PLL configuration.
Introduce an explicit "struct intel_lt_phy_pll_state" argument
for the PHY functions and update callers accordingly.
No functional change is intended — this is a preparatory cleanup for
to bring LT PHY PLL handling as part of PLL framework.
v2: DP, HDMI 2.0, and HDMI FRL modes are port of the VDR configuration 0
register. These modes are defined by bits 2:0. Decode these to
differentiate DP and HDMI modes when programming PLL's. (Imre, Suraj)
v3: Pass port_clock as argument instead of recalculating it (Suraj)
v4: Fix checkpatch warning of line length exceeding 100 columns
Imre Deak [Fri, 20 Mar 2026 09:29:00 +0000 (11:29 +0200)]
drm/i915/dp_tunnel: Fix error handling when clearing stream BW in atomic state
Clearing the DP tunnel stream BW in the atomic state involves getting
the tunnel group state, which can fail. Handle the error accordingly.
This fixes at least one issue where drm_dp_tunnel_atomic_set_stream_bw()
failed to get the tunnel group state returning -EDEADLK, which wasn't
handled. This lead to the ctx->contended warn later in modeset_lock()
while taking a WW mutex for another object in the same atomic state, and
thus within the same already contended WW context.
Moving intel_crtc_state_alloc() later would avoid freeing saved_state on
the error path; this stable patch leaves that simplification for a
follow-up.
Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.9+ Fixes: a4efae87ecb2 ("drm/i915/dp: Compute DP tunnel BW during encoder state computation") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7617 Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260320092900.13210-1-imre.deak@intel.com
Ville Syrjälä [Thu, 19 Mar 2026 11:40:33 +0000 (13:40 +0200)]
drm/i915/wm: Include ddb_y in skl_print_wm_changes() on pre-icl
Pre-icl doesn't use a separate hardware plane for Y scanout,
and instead it's all handled magically by the hardware. We
do still need to allocate DDB space for the Y color plane
though (PLANE_NV12_BUF_CFG). Include that information in the
debugs so that we know where it ended up.
On icl+ the equivalent information is dumped as the hardware
Y plane's normal ddb allocation.
We have skl_print_plane_wm_changes() but the DDB counterpart is
just inline in the main loop. Extract it into a function. We'll
have a second use for this soon.
The "ddb" part is already parametrized in anticipation of the
second user.
Ville Syrjälä [Thu, 19 Mar 2026 11:40:30 +0000 (13:40 +0200)]
drm/i915/wm: Nuke wm->uv_wm[]
We currently keep around the full watermarks for the UV plane
on pre-icl, even though the hardware doesn't need most of this
information. The only thing we need to keep is the min_ddb_alloc
for the UV plane. Move that into the main wm->wm[].min_ddb_alloc_uv
alongside the other min_ddb_alloc (used for Y/RGB).
This makes our state tracking match the hardware more closely,
and avoids having to justify everwhere why uv_wm[] is being
ignored.
Extract skl_allocate_plane_ddb_nv12() as the compute counterpart to
skl_check_wm_level_nv12(). Mainly to hide some of the clutter from
skl_crtc_allocate_plane_ddb().
Rename skl_check_nv12_wm_level() to skl_check_wm_level_nv12(). There
will be a sort of DDB counterparts to skl_check_wm_level*(), and
putting the "nv12" part to the end will allow consistent naming.
Ville Syrjälä [Thu, 19 Mar 2026 11:40:27 +0000 (13:40 +0200)]
drm/i915/wm: Reorder the arguments to skl_allocate_plane_ddb()
Group the ddb and data_rate together in the skl_allocate_plane_ddb()
arguments. Upcoming changes will adjust the UV plane handling and
keeing the ddb allocation and the data rate used to calculate it
together will help with clarity.
Ville Syrjälä [Mon, 16 Mar 2026 16:39:53 +0000 (18:39 +0200)]
drm/i915: Skip redundant NV12 plane unlinking
plane_atomic_check() will already have unlinked the
old NV12 planes by the time icl_check_nv12_planes()
gets called. Drop the redundant second unlinking.
Ville Syrjälä [Mon, 16 Mar 2026 16:39:51 +0000 (18:39 +0200)]
drm/i915: Unlink NV12 planes earlier
unlink_nv12_plane() will clobber parts of the plane state
potentially already set up by plane_atomic_check(), so we
must make sure not to call the two in the wrong order.
The problem happens when a plane previously selected as
a Y plane is now configured as a normal plane by user space.
plane_atomic_check() will first compute the proper plane
state based on the userspace request, and unlink_nv12_plane()
later clears some of the state.
This used to work on account of unlink_nv12_plane() skipping
the state clearing based on the plane visibility. But I removed
that check, thinking it was an impossible situation. Now when
that situation happens unlink_nv12_plane() will just WARN
and proceed to clobber the state.
Rather than reverting to the old way of doing things, I think
it's more clear if we unlink the NV12 planes before we even
compute the new plane state.
Ville Syrjälä [Fri, 13 Mar 2026 11:07:40 +0000 (13:07 +0200)]
drm/i915: Order OP vs. timeout correctly in __wait_for()
Put the barrier() before the OP so that anything we read out in
OP and check in COND will actually be read out after the timeout
has been evaluated.
Currently the only place where we use OP is __intel_wait_for_register(),
but the use there is precisely susceptible to this reordering, assuming
the ktime_*() stuff itself doesn't act as a sufficient barrier:
Jouni Högander [Tue, 17 Mar 2026 06:24:02 +0000 (08:24 +0200)]
drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk
Add new quirk (QUIRK_DISABLE_PANEL_REPLAY) for disabling Panel Replay as
quirk for problematic setups. Apply this newly added quirk on Dell XPS 14 DA14260 if specific panel model is installed.
We are observing problems with Dell XPS 14 DA14260. This device has certain
LGD panel model which seems to be problematic. We have seen other LGD panel
model with same OUI is working fine. Due to this we can't apply the quirk
only based on panel OUI. There are also cases where same device model has
differing panel model. We don't want to disable Panel Replay on such
devices. Best we can do is to apply the quirk based on both device model
and panel model.
drm/i915/gmbus: fix spurious timeout on 512-byte burst reads
When reading exactly 512 bytes with burst read enabled, the
extra_byte_added path breaks out of the inner do-while without
decrementing len. The outer while(len) then re-enters and gmbus_wait()
times out since all data has been delivered. Decrement len before the
break so the outer loop terminates correctly.
Suraj Kandpal [Mon, 16 Mar 2026 03:18:51 +0000 (08:48 +0530)]
drm/i915/backlight: Check if VESA backlight is possible
Check if BACKLIGHT_BRIGHTNESS_AUX_SET_CAPABLE bit is
set then EDP_PWMGEN_BIT_COUNT_CAP_MIN and EDP_PWMGEN_BIT_COUNT_CAP_MAX
follow the eDP 1.4b Section 10.3. Which states min should
be >= 1 and max should be >= min. Some legacy panels
do not follow this properly. They set the
BACKLIGHT_BRIGHTNESS_AUX_SET_CAPABLE bit while not correctly
populating the min and max fields leading to a 0 max value.
Jonathan Cavitt [Wed, 4 Feb 2026 16:19:46 +0000 (16:19 +0000)]
drm/i915/gvt: Swap read and write checks
The function intel_gvt_i2c_handle_aux_ch_write currently does not
support the DP_AUX_I2C_WRITE operation. Notably, we check if
op & 0x1 == DP_AUX_I2C_WRITE (one), and if it does not, assert that
op & 0x1 == DP_AUX_I2C_READ (zero). This is unnecessary because if
op & 0x1 != 1, then op & 0x1 == 0. But beyond that, it probably makes
more sense to check for the condition that is implemented, rather than
check for the condition that is not.
Swap the conditions. We can also get rid of the unnecessary drm_WARN_ON
while we're here.
Jonathan Cavitt [Fri, 23 Jan 2026 15:21:22 +0000 (15:21 +0000)]
drm/i915/display: PORT_NONE is not valid
Static analysis issue:
In assert_port_valid, add a check to ensure port != PORT_NONE, as that
is not a valid port. The check must be explicit to prevent a bad bit
shift operation in the general case via short-circuiting. It's not
likely this will ever come up in a real use case, but it's at least
worth guarding against.
It would probably also be pertinent to modify the behavior of the
port_name function to correctly print PORT_NONE in this case, as
currently the port would be reported as 'port @' by the debugger. But
that should be done separately, and given port_name is mostly just a
debug printing helper function anyways, fixing it is a low priority.
v2:
- Conditional check was backwards. Fix it. (Jani)
Jouni Högander [Thu, 12 Mar 2026 08:37:10 +0000 (10:37 +0200)]
drm/i915/psr: Compute PSR entry_setup_frames into intel_crtc_state
PSR entry_setup_frames is currently computed directly into struct
intel_dp:intel_psr:entry_setup_frames. This causes a problem if mode change
gets rejected after PSR compute config: Psr_entry_setup_frames computed for
this rejected state is in intel_dp:intel_psr:entry_setup_frame. Fix this by
computing it into intel_crtc_state and copy the value into
intel_dp:intel_psr:entry_setup_frames on PSR enable.
Fixes: 2b981d57e480 ("drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier") Cc: Mika Kahola <mika.kahola@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312083710.1593781-3-jouni.hogander@intel.com
Jouni Högander [Thu, 12 Mar 2026 08:37:09 +0000 (10:37 +0200)]
drm/i915/psr: Disable PSR on update_m_n and update_lrr
PSR/PR parameters might change based on update_m_n or update_lrr. Disable
on update_m_n and update_lrr to ensure proper parameters are taken into use
on next PSR enable in intel_psr_post_plane_update.
Jani Nikula [Wed, 11 Mar 2026 14:18:18 +0000 (16:18 +0200)]
drm/{i915,xe}: move framebuffer bo to parent interface
Add .framebuffer_init, .framebuffer_fini and .framebuffer_lookup to the
bo parent interface. While they're about framebuffers, they're
specifically about framebuffer objects, so the bo interface is a good
enough fit, and there's no need to add another interface struct.
Jani Nikula [Wed, 11 Mar 2026 14:18:16 +0000 (16:18 +0200)]
drm/{i915, xe}/bo: move display bo calls to parent interface
Continue i915 and xe separation from display by moving the bo calls to
the display parent interface. Instead of adding all these functions to
intel_parent.[ch], reuse the now vacated intel_bo.[ch], and avoid mass
renames to calls of these functions. This is similar to
intel_display_rpm.[ch].
Make many of the hooks optional to avoid having to implement dummy
functions in xe. Indeed now we can remove many of the existing dummy
functions.
Imre Deak [Wed, 11 Mar 2026 15:31:52 +0000 (17:31 +0200)]
drm/i915/dp: Simplify forcing a link retraining
Since both the DP SST and MST HPD IRQ handlers call
intel_dp_handle_link_service_irq() with LINK_STATUS_CHANGED set in
irq_mask if intel_dp->link.force_retrain is set, checking for the former
flag is sufficient to determine if the link status needs to be checked
(which includes retraining the link if this is forced); remove checking
for the latter flag.
Since LINK_STATUS_CHANGED is currently set unconditionally for DP SST,
extend the related comment to note that it must be set if
intel_dp->link.force_retrain is set (in case setting LINK_STATUS_CHANGED
becomes conditional on DPCD_REV).
Imre Deak [Wed, 11 Mar 2026 15:31:51 +0000 (17:31 +0200)]
drm/i915/dp_mst: Fix forced link retrain handling in MST HPD IRQ handler
Handling of a forced link retraining debugfs request via the DP MST HPD
IRQ handler is incorrectly skipped, if the IRQ handler doesn't see any
HPD IRQs raised by the sink. Fix this by ensuring that the request is
always handled (in the Fixes: commit below by directly calling
intel_dp_check_link_state(), later by the same call moved to
intel_dp_handle_link_service_irq()).
Cc: Luca Coelho <luciano.coelho@intel.com> Fixes: db4855d90363 ("drm/i915/dp_mst: Reuse intel_dp_check_link_state() in the HPD IRQ handler") Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260311153152.133744-1-imre.deak@intel.com
Suraj Kandpal [Wed, 25 Feb 2026 06:50:45 +0000 (12:20 +0530)]
drm/i915/hdcp: Take force_hdcp14 into account during check_link
During intel_hdcp_check_link phase we need to take into account
if we are currently forcing HDCP 1.4 or not. This is because
we check for HDCP 2.x Link first and only if HDCP 2.x is not being
used check for HDCP 1.4. With force_hdcp14 in picture we should not
be going into intel_hdcp2_check_link because of which we may end
up trying to disable HDCP2.x even if HDCP 1.4 was enabled causing
a lot of issues while IGT tests this.
Imre Deak [Mon, 9 Mar 2026 16:48:03 +0000 (18:48 +0200)]
drm/i915/dmc: Fix an unlikely NULL pointer deference at probe
intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been
initialized, and dmc is thus NULL.
That would be the case when the call path is
intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() ->
gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as
intel_power_domains_init_hw() is called *before* intel_dmc_init().
However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count()
conditionally, depending on the current and target DC states. At probe,
the target is disabled, but if DC6 is enabled, the function is called,
and an oops follows. Apparently it's quite unlikely that DC6 is enabled
at probe, as we haven't seen this failure mode before.
It is also strange to have DC6 enabled at boot, since that would require
the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and
the driver stopping / reprogramming the firmware is a poorly specified
sequence and as such unlikely an intentional BIOS behaviour. It's more
likely that BIOS is leaving an unintentionally enabled DC6 HW state
behind (without actually loading the required DMC firmware for this).
The tracking of the DC6 allowed counter only works if starting /
stopping the counter depends on the _SW_ DC6 state vs. the current _HW_
DC6 state (since stopping the counter requires the DC5 counter captured
when the counter was started). Thus, using the HW DC6 state is incorrect
and it also leads to the above oops. Fix both issues by using the SW DC6
state for the tracking.
This is v2 of the fix originally sent by Jani, updated based on the
first Link: discussion below.
Do away with the redundant intel_frontbuffer_get(),
intel_frontbuffer_put(), and intel_frontbuffer_ref() functions, and call
the parent interface functions directly.
Jani Nikula [Mon, 2 Mar 2026 18:17:37 +0000 (20:17 +0200)]
drm/{i915, xe}/frontbuffer: move frontbuffer handling to parent interface
Move the get/put/ref/flush_for_display calls to the display parent
interface.
For i915, move the hooks next to the other i915 core frontbuffer code in
i915_gem_object_frontbuffer.c. For xe, add new file xe_frontbuffer.c for
the same.
Note: The intel_frontbuffer_flush() calls from
i915_gem_object_frontbuffer.c will partially route back to i915 core via
the parent interface. This is less than stellar.
Jani Nikula [Mon, 2 Mar 2026 18:17:35 +0000 (20:17 +0200)]
drm/i915/overlay: convert from struct intel_frontbuffer to i915_frontbuffer
The intel_frontbuffer_get() and intel_frontbuffer_put() calls are routed
through intel_frontbuffer.c to i915_gem_object_frontbuffer.c. We might
as well call the functions directly, instead of going through display
code. This would only get worse with get/put being moved to the parent
interface.
To make this easier, convert overlay code from struct intel_frontbuffer
to struct i915_frontbuffer, and add a
i915_gem_object_frontbuffer_track() wrapper for clarity.
Jani Nikula [Mon, 2 Mar 2026 18:17:34 +0000 (20:17 +0200)]
drm/i915/gem: unify i915 gem object frontbuffer function names
Many of the i915 gem object frontbuffer function names follow the file
name as prefix. Follow suit with the remaining functions, renaming them
i915_gem_object_frontbuffer_*().
Move __i915_gem_object_{flush,invalidate}_frontbuffer() to
i915_gem_object_frontbuffer.c. All the other i915 gem object frontbuffer
functions are there already, and the relevant declarations are in
i915_gem_object_frontbuffer.h too.
Simon Richter [Fri, 6 Mar 2026 15:13:16 +0000 (00:13 +0900)]
drm/i915: handle failure from vga_get_uninterruptible()
The vga_get_uninterruptible() function can return an error if it fails to
set up VGA decoding for the requested device.
If VGA decoding is unavailable, we don't need to be careful to leave the
VGA emulation in a usable state, as vgacon will also be unable to get
access later on, so just skip over the VGA accesses and the vga_put() call
matching the failed vga_get_uninterruptible().
Randy Dunlap [Fri, 6 Mar 2026 22:10:32 +0000 (14:10 -0800)]
iopoll: fix function parameter names in read_poll_timeout_atomic()
Correct the function parameter names to avoid kernel-doc warnings
and to emphasize this function is atomic (non-sleeping).
Warning: include/linux/iopoll.h:169 function parameter 'sleep_us' not
described in 'read_poll_timeout_atomic'
Warning: ../include/linux/iopoll.h:169 function parameter
'sleep_before_read' not described in 'read_poll_timeout_atomic'
Fixes: 9df8043a546d ("iopoll: Generalize read_poll_timeout() into poll_timeout_us()") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260306221033.2357305-1-rdunlap@infradead.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Luca Coelho [Thu, 5 Mar 2026 09:59:19 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in skl_watermark.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:18 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in skl_universal_plane.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:17 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_psr.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:16 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_pmdemand.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:15 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_modeset_setup.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:14 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_flipq.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:13 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_fbc.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:12 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_dp_mst.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:11 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_display_device.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:10 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_display.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:09 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_ddi.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:08 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_cursor.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:07 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_cdclk.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:06 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_display_power.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:05 +0000 (11:59 +0200)]
drm/i915/display: convert audio workaround to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:04 +0000 (11:59 +0200)]
drm/i915/display: remove enum macro magic in intel_display_wa()
There's not much use in passing a number to the macro and let it
convert that into the enum and a string. It just hides the symbols.
Remove the number to enum conversion magic in intel_display_wa().
This has the side-effect of changing the print in the drm_WARN() that
is issued when the number is not implemented, but that is moot anyway
and can be changed later to something cleaner if needed.
projects / thirdparty / kernel / linux.git / log
