Jani Nikula [Mon, 17 Nov 2025 09:16:17 +0000 (11:16 +0200)]
drm/xe/rps: build RPS as part of xe
Reduce the conditional compilation in i915 by building
intel_display_rps.c as part of the xe module. This doesn't actually
enable RPS on xe, because there's no parent interface implementation on
xe side, but it's a step in the right direction.
Jani Nikula [Mon, 17 Nov 2025 09:16:10 +0000 (11:16 +0200)]
drm/{i915,xe}/display: move irq calls to parent interface
Add an irq parent driver interface for the .enabled and .synchronize
calls. This lets us drop the dependency on i915_drv.h and i915_irq.h in
multiple places, and subsequently remove the compat i915_irq.h and
i915_irq.c files along with the display/ext directory from xe
altogether.
Introduce new intel_parent.[ch] as the wrapper layer to chase the
function pointers and convert between generic and more specific display
types.
v2: Keep static wrappers in intel_display_irq.c (Ville)
v3: Full blown wrappers in intel_parent.[ch] (Ville)
Jani Nikula [Mon, 17 Nov 2025 09:16:08 +0000 (11:16 +0200)]
drm/{i915, xe}/display: duplicate gen2 irq/error init/reset in display irq
Duplicate gen2_irq_reset(), gen2_assert_iir_is_zero(), gen2_irq_init(),
gen2_error_reset(), and gen2_error_init() in intel_display_irq.c.
This allows us to drop the duplicates from xe, and prepares for future
cleanups. Although duplication is undesirable in general, in this case
the local duplicates lead to a cleaner end result.
There's a slight wrinkle in gen2_assert_iir_is_zero(). We need to use
non-device based logging until we pass in struct intel_display in a
separate change.
v2:
- Keep xe compat stuff due to series reorder and rebase
- Keep the WARN as regular WARN
- Rename the functions in the same go
Ville Syrjälä [Wed, 29 Oct 2025 20:42:15 +0000 (22:42 +0200)]
drm/i915/dram: Fix ICL DIMM_S decoding
Unfortunately the MAD_DIMM DIMM_S and DIMM_L bits on ICL are
not idential, so we are currently decoding DIMM_S incorrectly.
Fix the problem by defining the DIMM_S and DIMM_L bits separately.
And for consistency do that same for SKL, even though there the
bits do match between the two DIMMs. The result is rather
repetitive in places, but I didn't feel like obfuscatign things
with cpp macros/etc.
Broken decoding on Dell XPS 13 7390 2-in-1:
CH0 DIMM L size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH0 DIMM S size: 32 Gb, width: X32, ranks: 3, 16Gb+ DIMMs: no
CH0 ranks: 2, 16Gb+ DIMMs: no
CH1 DIMM L size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH1 DIMM S size: 32 Gb, width: X32, ranks: 3, 16Gb+ DIMMs: no
CH1 ranks: 2, 16Gb+ DIMMs: no
Memory configuration is symmetric? no
Fixed decoding on Dell XPS 13 7390 2-in-1:
CH0 DIMM L size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH0 DIMM S size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH0 ranks: 2, 16Gb+ DIMMs: no
CH1 DIMM L size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH1 DIMM S size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH1 ranks: 2, 16Gb+ DIMMs: no
Memory configuration is symmetric? yes
Mika Kahola [Tue, 18 Nov 2025 13:28:59 +0000 (15:28 +0200)]
drm/i915/cx0: Enable dpll framework for MTL+
MTL+ platforms are 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 MTL+ platforms and remove the redirections
to the legacy code paths from the following interfaces:
v2: Rebase on !HAS_LT_PHY check in intel_ddi_update_active_dpll()
v3: Rebase on !display->dpll.mgr check in intel_ddi_update_active_dpll()
Add check for NVL as the platform is not part of pll framework (Suraj)
Imre Deak [Mon, 17 Nov 2025 10:46:01 +0000 (12:46 +0200)]
drm/i915/cx0: Add MTL+ Thunderbolt PLL hooks
Add the PLL hooks for the TBT PLL on MTL+. These are simple stubs
similarly 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 [Mon, 17 Nov 2025 10:46:00 +0000 (12:46 +0200)]
drm/i915/cx0: Get encoder configuration for C10 and C20 PHY PLLs
For DDI initialization get encoder configuration for C10 and C20
chips.
v2: Get configuration either for a C10 or on the PTL port B
eDP on TypeC PHY case for a C20 PHY PLL. Hence refer to this
case as "non_tc_phy" instead of "c10phy".
Mika Kahola [Mon, 17 Nov 2025 10:45:53 +0000 (12:45 +0200)]
drm/i915/cx0: Add MTL+ .dump_hw_state hook
Add .dump_hw_state function pointer for MTL+ platforms
to support dpll framework. While at it, switch to use
drm_printer structure to print hw state information.
v2: Keep debug messages on one line if they not
necessarily needed to split into two or more
lines (Suraj)
Mika Kahola [Mon, 17 Nov 2025 10:45:49 +0000 (12:45 +0200)]
drm/i915/cx0: Add MTL+ .get_dplls hook
Add .get_dplls function pointer for MTL+ platforms
to support dpll framework. Reuse the ICL function
pointer.
v2: Getting configuration either for a C10 or on the PTL port B
eDP on TypeC PHY case for a C20 PHY PLL. Hence refer to this
case as "non_tc_phy" instead of "c10phy".
v3: Fix comment to "eDP over TypeC" (Suraj)
Fix pll id as separate variable (Suraj)
Mika Kahola [Mon, 17 Nov 2025 10:45:48 +0000 (12:45 +0200)]
drm/i915/cx0: Compute plls for MTL+ platform
To bring MTL+ platform aligned call and calculate PLL state
from dpll framework.
v2: Rename mtl_compute_c10phy_dpll() to mtl_compute_non_tc_phy_dpll().
The state is computed either for a C10 or on the PTL port B eDP
over TypeC PHY case for a C20 PHY PLL. Hence refer to this case as
"non_tc_phy" instead of "c10phy".
Rename mtl_compute_c20phy_dplls() to mtl_compute_tc_phy_dplls() for
symmetry with mtl_compute_non_tc_phy_dpll().
v3: Reword commit message (Suraj)
Mika Kahola [Mon, 17 Nov 2025 10:45:47 +0000 (12:45 +0200)]
drm/i915/cx0: Update C10/C20 state calculation
Update several functions in intel_cx0_phy.c to make PLL state
management more explicit.
Changes include
* add 'const' qualifiers to intel_crtc_state parameter for
cx0 state calculation functions
* refactor C10/C20 PLL state calculations helpers to take
explicit hardware state pointers instead of directly modifying
'crtc_state->dpll_hw_state'
Imre Deak [Mon, 17 Nov 2025 10:45:43 +0000 (12:45 +0200)]
drm/i915/cx0: Zero Cx0 PLL state before compute and HW readout
Ensure Cx0 pll state is initialized to zero before any computation or HW
readouts, to prevent leaving some parameter in the state uninitialized
in the actual compute/HW readout functions later.
Imre Deak [Mon, 17 Nov 2025 10:45:42 +0000 (12:45 +0200)]
drm/i915/cx0: Determine Cx0 PLL port clock from PLL state
The port clock is tracked in the PLL state, so there is no need to pass
it separately to __intel_cx0pll_enable(). Drop the port clock function
param accordingly.
Imre Deak [Mon, 17 Nov 2025 10:45:41 +0000 (12:45 +0200)]
drm/i915/cx0: Determine Cx0 PLL DP mode from PLL state
The Cx0 PLL enable programming needs to know if the PLL is in DP or HDMI
mode. The PLL manager framework doesn't pass the CRTC state to the PLL's
enable hook, so prepare here for the conversion to use the PLL manager
for Cx0 PHY PLLs by determining the DP/HDMI mode from the PLL state.
For C10 PHYs use the fact that the HDMI divider value in the PLL
registers are set if and only if the PLL is in HDMI mode.
For C20 PHYs use the DP mode flag programmed to the VDR SERDES register,
which is set if and only if the PLL is in DP mode.
Assert that the above PLL/VDR SERDES register values match the DP/HDMI
mode being configured already during state computation.
This also allows dropping the is_dp param from the
__intel_cx0pll_enable() function, since it can retrieve this now from
the PLL state.
Imre Deak [Mon, 17 Nov 2025 10:45:40 +0000 (12:45 +0200)]
drm/i915/cx0: Read out the Cx0 PHY SSC enabled state
Read out the C10, C20 PHY PLLs SSC enabled state, so the PLL HW/SW state
verification can check this state as well.
C10 PHY PLLs program some PLL registers zeroed out for the non-SSC case,
while programming non-zero values to the same registers for the SSC
case, so check that these PLL registers being zero or non-zero matches
the PLL's overall SSC-enabled state (stored in the
intel_c10pll_state::ssc_enabled flag).
Imre Deak [Mon, 17 Nov 2025 10:45:38 +0000 (12:45 +0200)]
drm/i915/cx0: Track the Cx0 PHY enabled lane count in the PLL state
The Cx0 PLL enable programming requires the enabled lane count. The PLL
manager framework doesn't pass the CRTC state to the PLL's enable hook,
so prepare here for the conversion to use the PLL manager, by tracking
the enabled lane count in the PLL state as well. This has the advantage,
that the enabled lane count can be verified against the PHY/PLL's
enabled TX lanes.
This also allows dropping the lane count param from the
__intel_cx0pll_enable() function, since it can retrieve this now from
the PLL state.
Imre Deak [Mon, 17 Nov 2025 10:45:37 +0000 (12:45 +0200)]
drm/i915/cx0: Add macro to get DDI port width from a register value
A follow-up change will need to retrieve the DDI port field from the
register value, add a macro for this. Make things symmetric with setting
the field in the register.
Imre Deak [Mon, 17 Nov 2025 10:45:36 +0000 (12:45 +0200)]
drm/i915/cx0: Move definition of Cx0 PHY functions earlier
Move the definitions of the
intel_c10pll_calc_port_clock()
intel_c20_get_dp_rate()
intel_c20_get_hdmi_rate()
is_hdmi_frl()
is_dp2()
intel_get_c20_custom_width()
functions earlier to avoid the forward declarations.
Imre Deak [Mon, 17 Nov 2025 10:45:35 +0000 (12:45 +0200)]
drm/i915/cx0: Track the C20 PHY VDR state in the PLL state
The Cx0 PLL enable programming needs to know if the PLL is in DP or HDMI
mode. The PLL manager framework doesn't pass the CRTC state to the PLL's
enable hook, so prepare here for the conversion to use the PLL manager
for Cx0 PHY PLLs by tracking the DP/HDMI mode in the PLL state.
This change has the advantage, that the VDR HW/SW state can be verified
now.
A follow up change will convert the PLL enable function to retrieve the
DP/HDMI mode parameter from the PLL state.
This also allows dropping the is_dp and port clock params from the
intel_c20_pll_program() function, since it can retrieve these now from
the PLL state.
v2: Fix comment to under same multicomment line (Suraj)
Imre Deak [Mon, 17 Nov 2025 10:45:34 +0000 (12:45 +0200)]
drm/i915/cx0: Sanitize calculating C20 PLL state from tables
A follow up change adds a computation for the C20 PLL VDR state, which
is common to both the HDMI algorithmic and DP/HDMI table based method.
To prepare for that streamline the code. The C10 counterpart would
benefit from the same change, leave that for later adding a TODO
comment.
Imre Deak [Mon, 17 Nov 2025 10:45:33 +0000 (12:45 +0200)]
drm/i915/cx0: Sanitize setting the Cx0 PLL use_c10 flag
Sanitize setting the Cx0 PLL use_c10 flag during state computation and
HW readout, making sure they happen the same way in the
intel_c{10,20}pll_calc_state() and intel_c{10,20}pll_readout_hw_state()
functions.
Follow-up changes will add more state computation/HW readout, this
change prepares for those as well.
Jonathan Cavitt [Tue, 4 Nov 2025 16:41:51 +0000 (16:41 +0000)]
drm/i915/display: Add default case to mipi_exec_send_packet
Add a default case to the switch case statement in mipi_exec_send_packet
to prevent attempts to read an uninitialized ret value. It's unlikely
the default case will ever occur during regular exeuction, but if more
MIPI DSI Processor-to-Peripheral transaction types are ever added, then
having this in place will be a useful safety guard.
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Fixes: 23db1577ce2d ("drm/i915/dsi: log send packet sequence errors") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20251104164150.16795-2-jonathan.cavitt@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Fri, 7 Nov 2025 18:11:24 +0000 (20:11 +0200)]
drm/i915: Use mode_config->cursor_width for cursor DDB allocation
Replace the hardcoded 256 with mode_config->cursor_width
when doing the cursor DDB allocation. Currently 256 is correct
for all SKL+, but this might change in the future. One less place
to change should that happen.
Ville Syrjälä [Fri, 7 Nov 2025 18:11:23 +0000 (20:11 +0200)]
drm/i915/wm: Use drm_get_format_info() in SKL+ cursor DDB allocation
Replace the technically inaccurate drm_format_info() with the
accurate drm_get_format_info() in the SKL+ cursor DDB
allocation code.
Since we're only interested in the linear modifier here, the two
functions do actually return the same information. But let's not
use drm_format_info() to avoid setting a bad example.
Ville Syrjälä [Fri, 7 Nov 2025 18:11:22 +0000 (20:11 +0200)]
drm/i915/fb: Init 'ret' in each error branch in intel_framebuffer_init()
Make the order of things a bit less fragile in
intel_framebuffer_init() by assigning 'ret' in each
error branch instead of depending on some earlier
assignment.
Ville Syrjälä [Fri, 7 Nov 2025 18:11:21 +0000 (20:11 +0200)]
drm/i915: Nuke intel_plane_config.tiling
Use intel_fb_modifier_to_tiling() to convert the modifier into
the fence tiling mode during BIOS FB readout, rather than hand
rolling it. With this we can also stop tracking the tiling mode
in the intel_plane_config.
Ville Syrjälä [Fri, 7 Nov 2025 18:11:20 +0000 (20:11 +0200)]
drm/i915: Populate fb->format accurately in BIOS FB readout
Use drm_get_format_info() instead of drm_format_info() to populate
fb->format during the BIOS FB readout. The difference being that
drm_get_format_info() knows about compressed formats whereas
drm_format_info() doesn't.
This doesn't actually matter in practice since the BIOS FB should
never be compressed, but no reason we shouldn't use the more accurate
function here anyway.
Ville Syrjälä [Fri, 7 Nov 2025 18:11:19 +0000 (20:11 +0200)]
drm/i915: Pass drm_format_info into plane->max_stride()
Pass the format info into plane->max_stride() from the
caller instead of doing yet another drm_format_info()
lookup on the spot.
drm_format_info() is both rather expensive, and technically
incorrect since it doesn't return the correct format info
for compressed formats (though that doesn't actually matter
for the current .max_stride() implementations since they
are just interested in the cpp value).
Most callers already have the format info available. The
only exception is intel_dumb_fb_max_stride() where we shall
use the actually correct drm_get_format_info() variant.
Ville Syrjälä [Fri, 7 Nov 2025 18:11:18 +0000 (20:11 +0200)]
drm/i915: Introduce intel_dumb_fb_max_stride()
Wrap intel_plane_fb_max_stride() in intel_dumb_fb_max_stride()
for the purposes of dumb fb creation. I want to change
intel_plane_fb_max_stride() to take a 'struct drm_format_info'
instead of the 'u32 pixel_format' so we need an excplicit format
info lookup in the dumb fb path and I don't really want to have
that in i915_gem_dumb_create() directly.
This makes intel_plane_fb_max_stride() internal to the display
code again, and thus we can pass in struct intel_display instead
of struct drm_device.
Ville Syrjälä [Mon, 10 Nov 2025 17:27:53 +0000 (19:27 +0200)]
drm/i915/de: Replace __intel_de_wait_for_register_nowl() with intel_de_wait_fw_us_atomic()
Nuke the remaining _nowl() stuff from the wakelock code in the
form of __intel_de_wait_for_register_nowl(), and replace it with
intel_de_wait_fw_us_atomic() that uses the low level _fw() register
accessors in line with the rest of the code.
No change in behaviour since wakelocks are only supported on xe,
and xe doesn't have uncore.lock nor unclaimed register detection
stuff.
Ville Syrjälä [Mon, 10 Nov 2025 17:27:51 +0000 (19:27 +0200)]
drm/i915/de: Replace __intel_de_rmw_nowl() with intel_de_rmw_fw()
We already have the lower level intel_de_*_fw() stuff, so use
that instead of hand rolling something custom for the DMC
wakelock stuff.
As the wakelock stuff exists only on platforms supported
by the xe driver this doesn't even result in any functional
changes since xe doesn't have uncore.lock nor unclaimed
register access detection.
Add intel_de_wait_for_set_us() and intel_de_wait_for_clear_us()
as the microsecond counterparts to intel_de_wait_for_set_ms()
and intel_de_wait_for_clear_ms().
Ville Syrjälä [Mon, 10 Nov 2025 17:27:45 +0000 (19:27 +0200)]
drm/i915/de: Use intel_de_wait_ms() for the obvious cases
Replace some users of intel_de_wait_custom() with intel_de_wait_ms().
This includes the cases where we pass in the default 2 microsecond
fast timeout, which is also what intel_de_wait_ms() uses so there
are no functional changes here.
Ville Syrjälä [Mon, 10 Nov 2025 17:27:44 +0000 (19:27 +0200)]
drm/i915/de: Use intel_de_wait_us()
Convert some of the intel_de_wait_custom() users over to
intel_de_wait_us(). We'll eventually want to eliminate
intel_de_wait_custom() as it's a hinderance towards using
poll_timeout_us().
This includes all the obvious cases where we only specify
a microsecond timeout to intel_de_wait_custom().
Ville Syrjälä [Mon, 10 Nov 2025 17:27:42 +0000 (19:27 +0200)]
drm/i915/de: Include units in intel_de_wait*() function names
intel_de_wait*() take the timeout in milliseconds. Include
that information in the function name to make life less
confusing. I'll also be introducing microsecond variants
of these later.
Done with cocci:
@@
@@
(
static int
- intel_de_wait
+ intel_de_wait_ms
(...)
{
...
}
|
static int
- intel_de_wait_fw
+ intel_de_wait_fw_ms
(...)
{
...
}
|
static int
- intel_de_wait_for_set
+ intel_de_wait_for_set_ms
(...)
{
...
}
|
static int
- intel_de_wait_for_clear
+ intel_de_wait_for_clear_ms
(...)
{
...
}
)
Ville Syrjälä [Mon, 10 Nov 2025 17:27:41 +0000 (19:27 +0200)]
drm/i915/de: Have intel_de_wait() hand out the final register value
We currently have a bunch of places that want the final register
value after register polling. Currently those places are mostly
using intel_de_wait_custom(). That is not a function that we
want to keep around as it pretty much prevents conversion to
poll_timeout_us().
Have intel_de_wait() also return the final register value so
that some of the current users can be converted over to the
simpler interface.
Ville Syrjälä [Mon, 10 Nov 2025 17:27:40 +0000 (19:27 +0200)]
drm/i915/de: Implement register waits one way
Currently we use a messy mix of intel_wait_for_register*()
and __intel_wait_for_register*() to implement various
register polling functions. Make the mess a bit more understandable
by always using the __intel_wait_for_register*() stuff.
Imre Deak [Fri, 7 Nov 2025 12:41:41 +0000 (14:41 +0200)]
drm/i915/dp_mst: Disable Panel Replay
Disable Panel Replay on MST links until it's properly implemented. For
instance the required VSC SDP is not programmed on MST and FEC is not
enabled if Panel Replay is enabled.
Ville Syrjälä [Thu, 6 Nov 2025 15:20:49 +0000 (17:20 +0200)]
drm/i915/pmdemand: Use the default 2 usec fast polling timeout
For whatever unknown reason the pmdemand code is using a custom
50 usec fast polling timeout instead of the normal 2 usec
value. Switch to the standard value to get rid of the special
case.
The eventual aim is to get rid of the fast vs. slow timeout
entirely and switch over to poll_timeout_us().
Ville Syrjälä [Thu, 6 Nov 2025 15:20:48 +0000 (17:20 +0200)]
drm/i915/hdcp: Use the default 2 usec fast polling timeout
For whatever unknown reason the HDCP code is using a custom
10 usec fast polling timeout instead of the normal 2 usec
value. Switch to the standard value to get rid of the special
case.
The eventual aim is to get rid of the fast vs. slow timeout
entirely and switch over to poll_timeout_us().
Ville Syrjälä [Thu, 6 Nov 2025 15:20:47 +0000 (17:20 +0200)]
drm/i915/ltphy: Nuke bogus weird timeouts
The LT PHY code is abusing intel_de_wait_custom() in all kinds of weird
ways. Get rid of the weird fast timeouts, and just use the slow ones.
For consistency with intel_wait_for_register() we'll stick to the
default 2 usec fast timeout for all cases.
Someone really needs to properly document where all these magic numbers
came from...
This will let us eventually nuke intel_de_wait_custom() and convert
over to poll_timeout_us().
v2: Go for the longer (ms) timeout in case it actually matters
Ville Syrjälä [Thu, 6 Nov 2025 15:20:44 +0000 (17:20 +0200)]
drm/i915/cx0: Get rid of XELPDP_MSGBUS_TIMEOUT_FAST_US
XELPDP_MSGBUS_TIMEOUT_FAST_US looks to be just an obfuscated version
of the default 2 microsecond fast timeout used by
intel_wait_for_register(). Get rid of it to make it clear what's going
on here.
Ville Syrjälä [Thu, 6 Nov 2025 15:20:43 +0000 (17:20 +0200)]
drm/i915/cx0: Replace XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US with XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_MS
There was a completely unjustified change to the cx0 powerdown
timeout, and the way it was done now prevents future conversion
to poll_timeout_us().
Assuming there was some reason the bigger timeout let's nuke
the old short timeout (XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US)
nd replace it with the bigger timeout
(XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_MS).
For consistency with intel_wait_for_register() we'll stick to the
default 2 usec for the fast timeout.
v2: Go for the longer (ms) timeout in case it actually matters
v3: Note the defaullt 2 usec fast timeout (Jani)
The i915_gem_object_get_frontbuffer() name is rather confusing wrt.
intel_frontbuffer_get(). Rename to i915_gem_object_frontbuffer_lookup()
to make things less confusing.
The current attempted split between xe/i915 vs. display
for intel_frontbuffer is a mess:
- the i915 rcu leaks through the interface to the display side
- the obj->frontbuffer write-side is now protected by a display
specific spinlock even though the actual obj->framebuffer
pointer lives in a i915 specific structure
- the kref is getting poked directly from both sides
- i915_active is still on the display side
Clean up the mess by moving everything about the frontbuffer
lifetime management to the i915/xe side:
- the rcu usage is now completely contained in i915
- frontbuffer_lock is moved into i915
- kref is on the i915/xe side (xe needs the refcount as well
due to intel_frontbuffer_queue_flush()->intel_frontbuffer_ref())
- the bo (and its refcounting) is no longer on the display side
- i915_active is contained in i915
I was pondering whether we could do this in some kind of smaller
steps, and perhaps we could, but it would probably have to start
with a bunch of reverts (which for sure won't go cleanly anymore).
So not convinced it's worth the hassle.
After upcoming intel_frontbuffer lifetime related changes we
won't need intel_frontbuffer::obj for anything apart from
getting at the display. Add a direct pointer for that instead
so that the obj pointer can be completely eliminated.
I want to hide the kref from the high level frontbuffer code.
To that end abstract the kref_get() in intel_frontbuffer_queue_flush()
(which is the only high level function that needs this) as a new
intel_frontbuffer_ref().
Ville Syrjälä [Thu, 16 Oct 2025 18:54:03 +0000 (21:54 +0300)]
drm/i915/frontbuffer: Handle the dirtyfb cache flush inside intel_frontbuffer_flush()
intel_bo_frontbuffer_flush_for_display() is a bit too low level
to be directly in the high level dirtyfb code. Move the calls
into intel_frontbuffer_flush().
There is a slight behavioural change here in that we now skip
the flush if the bo is not a current scanout buffer (front->bits
== 0). But that is fine as the flush will eventually happen via
the fb pinning code if/when the bo becomes a scanout buffer again.
Ville Syrjälä [Thu, 16 Oct 2025 18:54:02 +0000 (21:54 +0300)]
drm/i915/frontbuffer: Turn intel_bo_flush_if_display() into a frontbuffer operation
Convert intel_bo_flush_if_display() to be an operation on the
frontbuffer object rather than the underlying gem bo. This
will help with cleaning up the frontbuffer xe/i915 vs. display
split.
Get rid of intel_frontbuffer_flip_{prepare,complete}() (and
the accompanying flip_bits) since they are unused.
I suppose these could technically provide a minor optimization
over intel_frontbuffer_flip() in that the flush would get
deferred further if new rendering were to sneak in between the
prepare() and complete() calls. But for correctness it should
not make any difference since another flush will anyway follow
once the new rendering finishes.
Ville Syrjälä [Thu, 16 Oct 2025 18:54:00 +0000 (21:54 +0300)]
drm/i915/overlay: Switch to intel_frontbuffer_flip()
Get rid of intel_frontbuffer_flip_{prepare,complete}() from
the overlay code and just use intel_frontbuffer_flip() instead.
The only difference between these are the light interactions
with the ORIGIN_CS busyness tracking, but since the only user
of this is the overlay/xf86-video-intel/Xv the buffer will
always be filled by the CPU and thus we'll never see any
ORIGIN_CS frontbuffer activity there anyway. Also I don't
think we actually have anything covered by the frontbuffer
tracking that affects the overlay (FBC is on the primary
plane, DRRS isn't currently enabled on the platforms with
overlay, and PSR doesn't exist in the hardware).
Ville Syrjälä [Thu, 16 Oct 2025 18:53:59 +0000 (21:53 +0300)]
drm/i915/overlay: Drop the DIRTYFB flush
I don't even know why we have this DIRTYFB flush in the overlay
code. We'll anyway call intel_frontbuffer_flip() so there should
be no need to pretend that this is some kind of frontbuffer only
rendering operation.
Jani Nikula [Thu, 6 Nov 2025 20:00:00 +0000 (22:00 +0200)]
drm/i915/psr: fix pipe to vblank conversion
First, we can't assume pipe == crtc index. If a pipe is fused off in
between, it no longer holds. intel_crtc_for_pipe() is the only proper
way to get from a pipe to the corresponding crtc.
Second, drivers aren't supposed to access or index drm->vblank[]
directly. There's drm_crtc_vblank_crtc() for this.
Use both functions to fix the pipe to vblank conversion.
Fixes: f02658c46cf7 ("drm/i915/psr: Add mechanism to notify PSR of pipe enable/disable") Cc: Jouni Högander <jouni.hogander@intel.com> Cc: stable@vger.kernel.org # v6.16+ Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251106200000.1455164-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
projects / thirdparty / kernel / linux.git / log
