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>
Dave Airlie [Fri, 7 Nov 2025 02:40:51 +0000 (12:40 +1000)]
Merge tag 'drm-misc-next-2025-11-05-1' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for v6.19-rc1:
UAPI Changes:
- Add userptr support to ivpu.
- Add IOCTL's for resource and telemetry data in amdxdna.
Core Changes:
- Improve some atomic state checking handling.
- drm/client updates.
- Use forward declarations instead of including drm_print.h
- RUse allocation flags in ttm_pool/device_init and allow specifying max
useful pool size and propagate ENOSPC.
- Updates and fixes to scheduler and bridge code.
- Add support for quirking DisplayID checksum errors.
Driver Changes:
- Assorted cleanups and fixes in rcar-du, accel/ivpu, panel/nv3052cf,
sti, imxm, accel/qaic, accel/amdxdna, imagination, tidss, sti,
panthor, vkms.
- Add Samsung S6E3FC2X01 DDIC/AMS641RW, Synaptics TDDI series DSI,
TL121BVMS07-00 (IL79900A) panels.
- Add mali MediaTek MT8196 SoC gpu support.
- Add etnaviv GC8000 Nano Ultra VIP r6205 support.
- Document powervr ge7800 support in the devicetree.
Dave Airlie [Thu, 6 Nov 2025 23:45:38 +0000 (09:45 +1000)]
Merge tag 'drm-intel-next-2025-11-04' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
drm/i915 feature pull for v6.19:
Features and functionality:
- Enable LNL+ content adaptive sharpness filter (CASF) (Nemesa)
- Use optimized VRR guardband (Ankit, Ville)
- Enable Xe3p LT PHY (Suraj)
- Enable FBC support for Xe3p_LPD display (Sai Teja, Vinod)
- Specify DMC firmware for display version 30.02 (Dnyaneshwar)
- Report reason for disabling PSR to debugfs (Michał)
- Extend i915_display_info with Type-C port details (Khaled)
- Log DSI send packet sequence errors and contents
Refactoring and cleanups:
- Refactoring to prepare for VRR guardband optimization (Ankit)
- Abstract VRR live status wait (Ankit)
- Refactor VRR and DSB timing to handle Set Context Latency explicitly (Ankit)
- Helpers for prefill latency calculations (Ville)
- Refactor SKL+ watermark latency setup (Ville)
- VRR refactoring and cleanups (Ville)
- SKL+ universal plane cleanups (Ville)
- Decouple CDCLK from state->modeset refactor (Ville)
- Refactor VLV/CHV clock functions (Jani)
- Refactor fbdev handling (Jani)
- Call i915 and xe runtime PM from display via function pointers (Jouni)
- IRQ code refactoring (Jani)
- Drop display dependency on i915 feature check macros (Jani)
- Refactor and unify i915 and xe stolen memory interfaces towards display (Jani)
- Switch to driver agnostic drm to display pointer chase (Jani)
- Use display version over graphics version in display code (Matt A)
- GVT cleanups (Jonathan, Andi)
- Rename a VLV clock function to unify (Michał)
- Explicitly sanitize DMC package header num entries (Luca)
- Remove redundant port clock check from ALPM (Jouni)
- Use sysfs_emit() instead of sprintf() in PMU sysfs (Madhur Kumar)
- Clean up C20 PHY PLL register macros (Imre, Mika))
- Abstract "address in MMIO table" helper for general use (Matt A)
- Improve VRR platform abstractions (Ville)
- Move towards more standard PCI PM code usage (Ville)
- Framebuffer refactoring (Ville)
- Drop display dependency on i915_utils.h (Jani)
- Include cleanups (Jani)
Fixes:
- Workaround docking station DSC issues with high pixel clock and bpp (Imre)
- Fix Panel Replay in DSC mode (Imre)
- Disable tracepoints for PREEMPT_RT as a workaround (Maarten)
- Fix intel_crtc_get_vblank_counter() on PREEMPT_RT (Maarten)
- Fix C10 PHY identification on PTL/WCL (Dnyaneshwar)
- Take AS SDP into account with optimized guardband (Jouni)
- Fix panic structure allocation memory leak (Jani)
- Adjust an FBC workaround platforms (Vinod)
- Add fallback for CDCLK selection (Naladala)
- Avoid using invalid transcoder in MST transport select (Suraj)
- Don't use cursor size reduction on display version 14+ (Nemesa)
- Fix C20 PHY PLL register programming (Imre, Mika)
- Fix PSR frontbuffer flush handling (Jouni)
- Store ALPM parameters in crtc state (Jouni)
- Defeature DRRS on LNL+ (Ville)
- Fix the scope of the large DRAM DIMM workaround (Ville)
- Fix PICA vs. AUX power ordering issue (Gustavo)
- Fix pixel rate for computing watermark line time (Ville)
- Fix framebuffer set_tiling vs. addfb race (Ville)
- DMC event handler fixes (Ville)
DRM Core:
- CRTC sharpness strength property (Nemesa)
- DPCD DSC quirk for Synaptics Panamera devices (Imre)
- Helpers to query the branch DSC max throughput/line-width (Imre)
Merges:
- Backmerge drm-next for v6.18-rc and to sync with drm-xe-next (Jani)
drm/i915/xe3p_lpd: Adapt to updates on MBUS_CTL/DBUF_CTL registers
Xe3p_LPD updated fields of registers MBUS_CTL and DBUF_CTL to
accommodate for higher MDCLK:CDCLK ratios. Update the code to use the
new fields.
The field MBUS_TRANSLATION_THROTTLE_MIN_MASK was changed from range
[15:13] to [16:13]. Since bit 16 is not reserved in previous display
IPs and already used for something else, we can't simply extend the mask
definition to include it, but rather define an Xe3p-specific mask and
select the correct one to use based on the IP version.
Similarly, DBUF_MIN_TRACKER_STATE_SERVICE_MASK was changed from range
[18:16] to [20:16]. For the same reasons stated above, it needs a
Xe3p-specific mask definition.
v2:
- Keep definitions in the same line (i.e. without line continuation
breaks) for better readability. (Jani)
v3:
- Keep mask fields sorted by the upper limit. (Matt)
- Extend commit message to indicate why we need Xe3p-specific
definitions of the masks instead of just extending the existing
ones. (Matt)
When reading memory latencies for watermark calculations, previous
display releases instructed to apply an adjustment of adding a certain
value (e.g. 6us) to all levels when the level 0's memory latency read
from hardware was zero.
For Xe3p_LPD, the instruction is to always use 6us for level 0 and to
add that value to the other levels. Add the necessary code in
sanitize_wm_latency() so that WaWmMemoryReadLatency is always applied
for Xe3p_LPD and beyond.
v2:
- Rebased after addition of prep patch "drm/i915/wm: Reorder
adjust_wm_latency() for Xe3_LPD" (dropped in v3).
v3:
- Back to the simpler approach of doing the 'wm[0] = 0' step without
modifying the rest of the code, and that inside
sanitize_wm_latency(). (Matt Roper, Ville)
Gustavo Sousa [Wed, 5 Nov 2025 14:07:04 +0000 (11:07 -0300)]
drm/i915/dram: Add field ecc_impacting_de_bw
Starting with Xe3p_LPD, we now have a new field in MEM_SS_INFO_GLOBAL
that indicates whether the memory has enabled ECC that limits display
bandwidth. Add the field ecc_impacting_de_bw to struct dram_info to
contain that information and set it appropriately when probing for
memory info.
Currently there are no instructions in Bspec on how to handle that case,
so let's throw a warning if we ever find such a scenario.
v2:
- s/ecc_impacting_de/ecc_impacting_de_bw/ to be more specific. (Matt
Atwood)
- Add warning if ecc_impacting_de_bw is true, since we currently do
not have instructions on how to handle it. (Matt Roper)
v3:
- Check on ecc_impacting_de_bw for the warning only for Xe3p_LPD and
beyond.
- Change warning macro from drm_WARN_ON_ONCE() to drm_WARN_ON().
Gustavo Sousa [Wed, 5 Nov 2025 14:07:02 +0000 (11:07 -0300)]
drm/i915/xe3p_lpd: Reload DMC MMIO for pipes C and D
Xe3p_LPD has the same behavior as for Xe3_LPD with respect to DMC
context data for pipes C and D, which are lost when their power wells
are disabled. As such, let's extend the condition for Xe3_LPD in
need_pipedmc_load_mmio() to also catch Xe3p_LPD.
Ankit Nautiyal [Wed, 5 Nov 2025 14:06:59 +0000 (11:06 -0300)]
drm/i915/xe3p_lpd: Drop support for interlace mode
Interlace mode is officially removed from HW from Xe3p_LPD. The
register TRANS_VSYNCSHIFT and the bits in TRANS_CONF are now removed, so
make sure we do not set/get these anymore.
drm/i915/xe3p_lpd: Remove gamma,csc bottom color checks
With Xe3p_LPD, the SKL_BOTTOM_COLOR_GAMMA_ENABLE and
SKL_BOTTOM_COLOR_CSC_ENABLE bits are being removed. Thus, we need not
set gamma_enable nor csc_enable in crtc_state.
Note that GAMMA_MODE.POST_CSC_GAMMA_ENABLE and CSC_MODE.ICL_CSC_ENABLE
are the documented alternatives for the bottom color bits being removed.
But as these suggested bits are being checked in state checker as part
of gamma_mode, csc_mode fields and as gamma_enable/csc_enable are not
being used anywhere else functionally post ICL, we need not set these
fields in crtc_state.
On Xe3p_LPD, the dbuf blocks fields of different registers are now
documented as 13-bit fields. The dbuf isn't really large enough to need
the 13th bit, but let's go ahead and update the definition now just in
case some new display IP in future ends up needing the larger size. The
extra bit is an unused bit in previous display versions, so we can
safely just extend the existing definition.
Matt Atwood [Wed, 5 Nov 2025 14:06:53 +0000 (11:06 -0300)]
drm/i915/xe3p_lpd: Update bandwidth parameters
Bandwidth parameters for Xe3p_LPD are the same as for Xe3_LPD. Re-use
them.
Since handling for Xe3_LPD version 30.02 is more like a special case,
let's use a "== 3002" check for it inside the ">= 30" branch instead of
adding a new branch for version 35. That allows us to re-use the ">=
30" branch for Xe3p_LPD.
v2:
- Do not have a special case for ecc_impacting_de_bw, since there are
no specific instructions in Bspec for this scenario. (Matt Roper)
v3:
- Re-use the ">= 30" branch in the if-ladder. (Matt Roper)
Gustavo Sousa [Wed, 5 Nov 2025 14:06:52 +0000 (11:06 -0300)]
drm/i915/display: Use braces for if-ladder in intel_bw_init_hw()
Looking at the current if-ladder in intel_bw_init_hw(), we see that
Xe2_HPD contains two entries, differing only for ECC memories. Let's
improve readability by using braces and allowing adding extra conditions
for each case.
v2:
- Tweaked commit message, since we are not going to add the ECC case
for Xe3p_LPD anymore.
drm/i915/xe3p_lpd: Add Xe3p_LPD display IP features
Xe3p_LPD (display version 35) is similar to Xe2_LPD with respect to the
features described by struct intel_display_device_info, so reuse its
device descriptor.
Alok Tiwari [Mon, 3 Nov 2025 13:23:31 +0000 (05:23 -0800)]
drm/i915/dmc: Fix extra bracket and wrong variable in PIPEDMC error logs
Fixes two issues in intel_pipedmc_irq_handler():
- Removed an extra ']' in the PIPEDMC error and interrupt vector log.
- Corrected the interrupt vector log to print int_vector instead of tmp,
as tmp will be zero in this case.
Alok Tiwari [Fri, 17 Oct 2025 19:16:21 +0000 (12:16 -0700)]
drm: rcar-du: fix incorrect return in rcar_du_crtc_cleanup()
The rcar_du_crtc_cleanup() function has a void return type, but
incorrectly uses a return statement with a call to drm_crtc_cleanup(),
which also returns void.
Remove the return statement to ensure proper function semantics.
No functional change intended.
Karol Wachowski [Tue, 4 Nov 2025 13:24:18 +0000 (14:24 +0100)]
accel/ivpu: Improve debug and warning messages
Add IOCTL debug bit for logging user provided parameter validation
errors.
Refactor several warning and error messages to better reflect fault
reason. User generated faults should not flood kernel messages with
warnings or errors, so change those to ivpu_dbg(). Add additional debug
logs for parameter validation in IOCTLs.
Check size provided by in metric streamer start and return -EINVAL
together with a debug message print.
Lizhi Hou [Tue, 4 Nov 2025 06:25:43 +0000 (22:25 -0800)]
accel/amdxdna: Add hardware specific attributes
Add three hardware specific attributes to describe device capabilities:
hwctx_limit: The maximum number of hardware context supported.
max_tops: The maximum TOPS supported.
curr_tops: The TOPS achievable with the current power and frequency
configuration.
Jani Nikula [Tue, 28 Oct 2025 20:07:27 +0000 (22:07 +0200)]
drm/displayid: add quirk to ignore DisplayID checksum errors
Add a mechanism for DisplayID specific quirks, and add the first quirk
to ignore DisplayID section checksum errors.
It would be quite inconvenient to pass existing EDID quirks from
drm_edid.c for DisplayID parsing. Not all places doing DisplayID
iteration have the quirks readily available, and would have to pass it
in all places. Simply add a separate array of DisplayID specific EDID
quirks. We do end up checking it every time we iterate DisplayID blocks,
but hopefully the number of quirks remains small.
There are a few laptop models with DisplayID checksum failures, leading
to higher refresh rates only present in the DisplayID blocks being
ignored. Add a quirk for the panel in the machines.
Jani Nikula [Tue, 4 Nov 2025 10:02:53 +0000 (12:02 +0200)]
drm/hyperv: include drm_print.h where needed
hyperv_drm_drv.c and hyperv_drm_modeset.c depend on drm_print.h being
indirectly included via drm_buddy.h, drm_mm.h, or
ttm/ttm_resource.h. Include drm_print.h explicitly.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20251104101158.1cc9abcd@canb.auug.org.au Fixes: f6e8dc9edf96 ("drm: include drm_print.h where needed") Cc: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251104100253.646577-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
drm/i915/display: Extend i915_display_info with Type-C port details
Expose key Type-C port data in i915_display_info to make it easier to
understand the port configuration and active mode, especially whether
the link is in DP-Alt or TBT-Alt, without having to scan kernel logs.
v2: Use drm_printer (Ville)
Lock/Unlock around the printf (Imre)
v3: Forward Declaration drm_printer struct (Jani)
v4: Handle MST connector with no active encoder (Imre)
Add a delimiter between fields and ":" after the port name (Imre)
v5: Init dig_port and use it in intel_encorder_is_tc and tc_info (Imre)
Move tc->port_name to a newline (Imre)
v6: Use intel_tc_port_lock/Unlock (Imre)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251028190753.3089937-1-khaled.almahallawy@intel.com
Dan Carpenter [Fri, 24 Oct 2025 11:15:23 +0000 (14:15 +0300)]
drm/vkms: Fix use after frees on error paths
These error paths free a pointer and then dereference it on the next line
to get the error code. Save the error code first and then free the
memory.
Fixes: 3e4d5b30d2b2 ("drm/vkms: Allow to configure multiple CRTCs via configfs") Fixes: 2f1734ba271b ("drm/vkms: Allow to configure multiple planes via configfs") Fixes: 67d8cf92e13e ("drm/vkms: Allow to configure multiple encoders via configfs") Fixes: 272acbca96a3 ("drm/vkms: Allow to configure multiple connectors via configfs") Fixes: 13fc9b9745cc ("drm/vkms: Add and remove VKMS instances via configfs") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/aPtfy2jCI_kb3Df7@stanley.mountain Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
On SoCs where the GPU's power-domain is in charge of setting performance
levels, the OPP table of the GPU node will have already been populated
during said power-domain's attach_dev operation.
To avoid initialising an OPP table twice, only set the OPP regulator and
the OPPs from DT if there's no OPP table present.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20251017-mt8196-gpufreq-v8-4-98fc1cc566a1@collabora.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
drm/panthor: call into devfreq for current frequency
As it stands, panthor keeps a cached current frequency value for when it
wants to retrieve it. This doesn't work well for when things might
switch frequency without panthor's knowledge.
Instead, implement the get_cur_freq operation, and expose it through a
helper function to the rest of panthor.
Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Karunika Choo <karunika.choo@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20251017-mt8196-gpufreq-v8-3-98fc1cc566a1@collabora.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
The Mali-based GPU on the MediaTek MT8196 SoC uses a separate MCU to
control the power and frequency of the GPU. This is modelled as a power
domain and clock provider.
It lets us omit the OPP tables from the device tree, as those can now be
enumerated at runtime from the MCU.
Add the necessary schema logic to handle what this SoC expects in terms
of clocks and power-domains.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://patch.msgid.link/20251017-mt8196-gpufreq-v8-1-98fc1cc566a1@collabora.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Marek Vasut [Sun, 2 Nov 2025 16:09:06 +0000 (17:09 +0100)]
dt-bindings: gpu: mali-valhall-csf: Document i.MX95 support
The instance of the GPU populated in Freescale i.MX95 is the
Mali G310, document support for this variant.
Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Link: https://patch.msgid.link/20251102160927.45157-1-marek.vasut@mailbox.org Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Rain Yang [Wed, 22 Oct 2025 09:26:04 +0000 (17:26 +0800)]
drm/panthor: attach the driver's multiple power domains
Some platforms, such as i.MX95, utilize multiple power domains that need
to be attached explicitly. This patch ensures that the driver properly
attaches all available power domains using devm_pm_domain_attach_list().
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Suggested-by: Steven Price <steven.price@arm.com> Signed-off-by: Prabhu Sundararaj <prabhu.sundararaj@nxp.com> Signed-off-by: Rain Yang <jiyu.yang@nxp.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20251022092604.181752-1-jiyu.yang@oss.nxp.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Boris Brezillon [Fri, 31 Oct 2025 15:48:15 +0000 (16:48 +0100)]
drm/panthor: Fix UAF on kernel BO VA nodes
If the MMU is down, panthor_vm_unmap_range() might return an error.
We expect the page table to be updated still, and if the MMU is blocked,
the rest of the GPU should be blocked too, so no risk of accessing
physical memory returned to the system (which the current code doesn't
cover for anyway).
Proceed with the rest of the cleanup instead of bailing out and leaving
the va_node inserted in the drm_mm, which leads to UAF when other
adjacent nodes are removed from the drm_mm tree.
Ketil Johnsen [Wed, 22 Oct 2025 10:32:41 +0000 (12:32 +0200)]
drm/panthor: Fix race with suspend during unplug
There is a race between panthor_device_unplug() and
panthor_device_suspend() which can lead to IRQ handlers running on a
powered down GPU. This is how it can happen:
- unplug routine calls drm_dev_unplug()
- panthor_device_suspend() can now execute, and will skip a lot of
important work because the device is currently marked as unplugged.
- IRQs will remain active in this case and IRQ handlers can therefore
try to access a powered down GPU.
The fix is simply to take the PM ref in panthor_device_unplug() a
little bit earlier, before drm_dev_unplug().
Signed-off-by: Ketil Johnsen <ketil.johnsen@arm.com> Fixes: 5fe909cae118a ("drm/panthor: Add the device logical block") Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20251022103242.1083311-1-ketil.johnsen@arm.com Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Ketil Johnsen [Wed, 29 Oct 2025 11:14:10 +0000 (12:14 +0100)]
drm/panthor: disable async work during unplug
A previous change, "drm/panthor: Fix UAF race between device unplug and
FW event processing", fixes a real issue where new work was unexpectedly
queued after cancellation. This was fixed by a disable instead.
Apply the same disable logic to other device level async work on device
unplug as a precaution.
Ketil Johnsen [Mon, 27 Oct 2025 14:02:15 +0000 (15:02 +0100)]
drm/panthor: Fix UAF race between device unplug and FW event processing
The function panthor_fw_unplug() will free the FW memory sections.
The problem is that there could still be pending FW events which are yet
not handled at this point. process_fw_events_work() can in this case try
to access said freed memory.
Simply call disable_work_sync() to both drain and prevent future
invocation of process_fw_events_work().
Boris Brezillon [Fri, 31 Oct 2025 16:03:18 +0000 (17:03 +0100)]
drm/panthor: Fix group_free_queue() for partially initialized queues
group_free_queue() can be called on a partially initialized queue
object if something fails in group_create_queue(). Make sure we don't
call drm_sched_entity_destroy() on an entity that hasn't been
initialized.
projects / thirdparty / kernel / linux.git / log
