If a queue is currently active on the CS, query the QUEUE TIMESTAMP
register to get an up to date value of the runtime. To do so, ensure
that the primary queue is active and then check if the secondary queue
is executing on the CS.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260507162016.3888309-21-umesh.nerlige.ramappa@intel.com
We need to define more helpers that read engine ID specific register, so
move that logic outside of get_ctx_timestamp().
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260507162016.3888309-20-umesh.nerlige.ramappa@intel.com
In secondary queue LRCs, the QUEUE TIMESTAMP register is saved and
restored allowing us to view the individual queue run times. Add helpers
to read this value from the LRC.
BSpec: 73988
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260507162016.3888309-19-umesh.nerlige.ramappa@intel.com
For an LRC belonging to the secondary queue, in order to check if its
context group is active, we need to check the LRC of the primary queue.
In addition to that we want to compare the secondary queue position to
CSMQDEBUG register to check if the queue itself is active.
To do so, store primary LRC and position information in the LRC.
A note on references involved:
- In general the Queue takes a ref on its LRC.
- In addition, for multi-queue,
a. Primary Queue takes a ref for each Secondary LRC.
b. Each Secondary Queue takes a ref to the Primary Queue
In the current patch, each LRC in the queue group is storing a pointer
to primary LRC. Both primary and secondary LRCs are freed only when
primary queue is destroyed. At this time, all secondary queues are
already destroyed, so there is no one using secondary LRCs. We should be
good without taking any additional references.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260507162016.3888309-18-umesh.nerlige.ramappa@intel.com
xe exec queue code is using a check to see if a class of engines support
multi queue. This check is also needed by other code, so move it to
xe_gt and export it for others.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260507162016.3888309-17-umesh.nerlige.ramappa@intel.com
Add a timestamp in milliseconds to the LRC snapshot to make it easier to
reason about how long the LRC has been running and the average duration
of each job.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260507162016.3888309-15-umesh.nerlige.ramappa@intel.com
Use the 64 bit value when available for the context timestamp in the LRC
snapshot.
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Link: https://patch.msgid.link/20260507162016.3888309-14-umesh.nerlige.ramappa@intel.com
If a reset (GT or engine) happens during EU stall data sampling, all the
EU stall registers can get reset to 0. This will result in EU stall data
buffers' read and write pointer register values to be out of sync with
the cached values. This will result in read() returning invalid data. To
prevent this, check the value of a EU stall base register. If it is zero,
it indicates a reset may have happened that wiped the register to zero.
If this happens, return ENODEV from read() upon which the user space
should disable and enable EU stall data sampling or close the fd and
open a new fd for a new EU stall data collection session.
This patch has been tested by running two IGT tests simultaneously
xe_eu_stall and xe_exec_reset.
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Acked-by: Felix Degrood <felix.j.degrood@intel.com>
Signed-off-by: Harish Chegondi <harish.chegondi@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patch.msgid.link/6935698d70b6c7c347ff8b138209d601030c2c9f.1776200094.git.harish.chegondi@intel.com
Factor the repeated CGP_SYNC action build-and-send sequence into a new
helper guc_exec_queue_send_cgp_sync(). Drop the redundant guc parameter
from __register_exec_queue_group() since it can be derived via
exec_queue_to_guc(q). Remove xe_guc_exec_queue_group_add() which is now
identical to the helper and replace its call site directly.
No functional change.
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260508194428.61819-6-niranjana.vishwanathapura@intel.com
The 'killed_or_banned_or_wedged = true' assignment is redundant
since the variable is never read after that point.
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260508194428.61819-5-niranjana.vishwanathapura@intel.com
struct nvkm_disp_func ends with the user flexible array member. Allocate
the r535 display function table with kzalloc_flex() instead of open-coding
the size calculation with sizeof().
Assisted-by: Codex:GPT-5.5
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
[dropped nothing-burger sentence from commit message]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260508052056.1744665-1-rosenp@gmail.com
Use the proper macro do to these sizeof calculations.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
[fixed style warning from checkpatch]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260312195529.13002-1-rosenp@gmail.com
The blitter engines' MEM_COPY and MEM_SET instructions were added as
part of the same hardware change that introduced service copy engines
(i.e., BCS1-BCS8) which is why the driver checks for service copy engine
presence when deciding whether to use these instructions or the older
XY_* instructions. However when making this decision the driver should
consider which engines are part of the hardware architecture, not which
engines are present/usable on the current device. For graphics IP
versions that architecturally include service copy engines (i.e.,
everything Xe2 and later, plus PVC's Xe_HPC) we should use MEM_SET and
MEM_COPY even in if all of the service copy engines wind up getting
fused off. I.e., we need to decide based on whether the platform's
graphics descriptor contains these engines, rather than whether the
usable engine mask contains them. This logic got broken when
gt->info.__engine_mask was removed, although in practice that mistake
has been harmless so far because there haven't been any hardware
SKUs that fuse off all of the service copy engines yet.
Replace the incorrect has_service_copy_support() function with a GT
feature flag that tracks more accurately whether the new blitter
instructions are usable. In addition to fixing incorrect logic if all
service copies are fused off, the flag also makes it more obvious what
the calling code is trying to do; previously it wasn't terribly obvious
why "has service copy engines" was being used as the condition for using
different instructions on all copy engine types.
The new feature flag is named 'has_xe2_blt_instructions' because we
expect this flag to be set for all Xe2 and later platforms (i.e.,
everything officially supported by the Xe driver). Technically there's
also one Xe1-era platform (PVC) that supports these engines/instructions
and will set this flag, but this still seems to be the most clear and
understandable name for the flag.
Fixes: 61549a2ee5 ("drm/xe: Drop __engine_mask")
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260507-xe2_copy-v1-1-26506381b821@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
When ttm_tt_swapout() fails, the current code calls
ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail()
to restore the resource's bulk_move membership.
However, ttm_resource_move_to_lru_tail() places the resource at the tail
of the LRU list which, relative to the walk cursor's hitch node (placed
immediately after the resource when it was yielded), puts the resource
*in front of the* the hitch. The next list_for_each_entry_continue() from
the hitch finds the same resource again, causing an infinite loop.
Fix by deferring del_bulk_move to the success path only.
On the success path, TTM_TT_FLAG_SWAPPED has just been set by
ttm_tt_swapout() but the resource is still tracked in the bulk_move range,
so ttm_resource_del_bulk_move()'s !ttm_resource_unevictable() guard would
incorrectly skip the removal. Introduce
ttm_resource_del_bulk_move_unevictable() which bypasses that guard.
Reported-by: Jatin Kataria <jkataria@netflix.com>
Fixes: fc5d96670e ("drm/ttm: Move swapped objects off the manager's LRU list")
Cc: Christian König <christian.koenig@amd.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: <dri-devel@lists.freedesktop.org>
Cc: <stable@vger.kernel.org> # v6.13+
Assisted-by: GitHub_Copilot:claude-sonnet-4.6
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Boqun Feng <boqun@kernel.org>
Link: https://patch.msgid.link/20260428094442.16985-1-thomas.hellstrom@linux.intel.com
Stolen memory requires physically contiguous allocations for display
scanout and compressed framebuffers. The stolen memory manager was
sharing the gpu_buddy allocator backend with the VRAM manager, but
buddy manages non-contiguous power-of-two blocks making it a poor fit.
Stolen memory also has fundamentally different allocation patterns:
- Allocation sizes are not power-of-two. Since buddy rounds up to the
next power-of-two block size, a ~17MB request can fail even with
~22MB free, because the free space is fragmented across non-fitting
power-of-two blocks.
- Hardware restrictions prevent using the first 4K page of stolen for
certain allocations (e.g., FBC). The display code sets fpfn=1 to
enforce this, but when fpfn != 0, gpu_buddy enables
GPU_BUDDY_RANGE_ALLOCATION mode which disables the try_harder
coalescing path, further reducing allocation success.
This combination caused FBC compressed framebuffer (CFB) allocation
failures on platforms like NVL/PTL. In case of NVL where stolen memory
is ~56MB and the initial plane framebuffer consumes ~34MB at probe time,
leaving ~22MB for subsequent allocations.
Use ttm_range_man_init_nocheck() to set up a drm_mm-backed TTM resource
manager for stolen memory. This reuses the TTM core's ttm_range_manager
callbacks, avoiding duplicate implementations.
Tested on NVL with a 4K DP display: stolen_mm shows a single ~22MB
contiguous free hole after initial plane framebuffer allocation, and
FBC successfully allocates its CFB from that region. The corresponding
IGT was previously skipped and now passes.
v2:
- Clarify that stolen memory requires contiguous allocations (Matt B)
- Properly handle xe_ttm_resource_visible() for stolen instead of
unconditionally returning true (Matt A)
v3:
- Rebase
- Fix xe_display_bo_fbdev_prefer_stolen() to compare in pages, since
ttm_range_manager stores stolen->size in pages not bytes (Matt A)
v4:
- Add kernel-doc for struct xe_ttm_stolen_mgr (Matt B)
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7631
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Suggested-by: Matthew Auld <matthew.auld@intel.com>
Assisted-by: GitHub Copilot:claude-sonnet-4.6
Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260422125502.3088222-2-sanjay.kumar.yadav@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
gpu_buddy APIs are expected to be called with the driver-provided lock
held, but there is no runtime enforcement of this contract. Add lockdep
annotations to catch locking violations early.
Introduce gpu_buddy_driver_set_lock() for the driver to register the
lock that protects the buddy manager. Add gpu_buddy_driver_lock_held()
assertions to all exported gpu_buddy and drm_buddy APIs that
access/modify the manager state. The lock_dep_map field is only compiled
in when CONFIG_LOCKDEP is enabled, adding zero overhead to production
builds.
Wire up xe_ttm_vram_mgr to register its mutex with the buddy manager
after initialization.
Assisted-by: Copilot:claude-opus-4.6
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Link: https://patch.msgid.link/20260508065544.4049240-2-tejas.upadhyay@intel.com
xe_bo_recompute_purgeable_state() walks all VMAs of a BO to determine
whether the BO can be made purgeable. This makes VMA create/destroy and
madvise updates O(n) in the number of mappings.
Replace the walk with BO-local counters protected by the BO dma-resv
lock:
- vma_count tracks the number of VMAs mapping the BO.
- willneed_count tracks active WILLNEED holders, including WILLNEED
VMAs and active dma-buf exports for non-imported BOs.
A DONTNEED BO is promoted back to WILLNEED on a 0->1 transition of
willneed_count. A BO is demoted to DONTNEED on a 1->0 transition only
when it still has VMAs, preserving the previous behaviour where a BO
with no mappings keeps its current madvise state.
PURGED remains terminal, preserving the existing "once purged, always
purged" rule.
Fixes: 4f44961eab ("drm/xe/vm: Prevent binding of purged buffer objects")
v2:
- Use early return for imported BOs in all four helpers to avoid
nesting (Matt B).
- Group purgeability state into a purgeable sub-struct on struct
xe_bo (Matt B).
- Reword xe_bo_willneed_put_locked() kernel-doc to explain that a 1->0
transition means all remaining active VMAs are DONTNEED (Matt B).
v3:
- Move DONTNEED/PURGED reject from vma_lock_and_validate() into
xe_vma_create(), gated on attr->purgeable_state == WILLNEED.
Fixes vm_bind bypass and partial-unbind rejection on DONTNEED
BOs (Matt B).
- Drop .check_purged from MAP and REMAP; keep it for PREFETCH and
add a comment why (Matt B).
- Skip BO validation in vma_lock_and_validate() for non-WILLNEED
VMA remnants so cleanup/remap paths do not repopulate
DONTNEED/PURGED BOs.
Suggested-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260506132027.2556046-1-arvind.yadav@intel.com
Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
There was a potential race condition in change_handle. The ioctl
briefly had a single object with two idr entries; a concurrent
gem_close could delete the object and remove one of the handles
while leaving the other one dangling, which could subsequently
be dereferenced for a use-after-free.
To fix this, do the same dance that gem_close itself does.
(f6cd7daecf drm: Release driver references to handle before making it available again)
First idr_replace the old handle to NULL. Later, if the prime
operations are successful, actually close it.
create_tail required a similar dance to avoid a similar problem.
(bd46cece51 drm/gem: Fix race in drm_gem_handle_create_tail())
It idr_allocs the new handle with NULL, then swaps in the correct
object later to avoid races. We don't need to do that here, since
the only operations that could race are drm_prime, and
change_handle holds the prime lock for the entire duration.
v2: cleanups of error paths
Signed-off-by: David Francis <David.Francis@amd.com>
Co-authored-by: Dave Airlie <airlied@gmail.com>
Reported-by: Puttimet Thammasaeng <pwn8official@gmail.com>
Tested-by: Vitaly Prosyak <Vitaly.Prosyak@amd.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: stable@vger.kernel.org
Cc: Christian Koenig <Christian.Koenig@amd.com>
Fixes: 53096728b8 ("drm: Add DRM prime interface to reassign GEM handle")
Signed-off-by: Dave Airlie <airlied@redhat.com>
UAPI Changes:
- Support medium/low power modes in amdxdna.
- Support limiting frequency in ivpu.
- Document license for drm core uAPI headers.
- Add the following DRM formats: P230, Y7, XYYY2101010, T430,
XVUY210101010.
Cross-subsystem Changes:
- Add and improve dt-bindings.
- Remove unused dma-fence-array's signal_on_any support.
Core Changes:
- Do not call drop_master on file close if not master.
- Convert drm-bridge and drm/atomic to use drm_printf_indent.
- Remove the extra call to drm_connector_attach_encoder after
drm_bridge_connector_init().
- Assorted docbook updates.
Driver Changes:
- Bugfixes in amdxdna, ivpu, mipi-dsi, imagination, nouveau, panthor,
bridge/analogix_dp, ipv3, lontium-lt8912b, verisilicon, tve200,
etnaviv, panel/focaltech-ota7290b, panel/jadard-jd9365da-h3,
bridge/ite-it6263, renesas, xlnx, bridge/cdns-dsi, gma500,
bridge/microchip-lvds, mgag200.
- Add support for MStar TSUMU88ADT3-LF-1 bridge.
- Add support for WaveShare 7, Novatek NT35532, Startek KD070HDFLD092,
ChipWealth CH13726A AMOLED, Team Source Display TST070WSNE-196C,
Displaytech DT050BTFT-PTS panels.
- Improve mipi-dsi shutdown and convert a panasonic panel to use the
mipi-dsi wrappers.
- Allowing dumping vbios over debugfs in GSP-RM mode.
- Update maintainers for ivpu, add reviewer for drm-bridge code
and update maintainers for LT8912B DRM HDMI bridge.
- Add test pattern support to bridge/ti-sn65dsi83.
- Convert vmwgfx to vblank timers.
- Add power management to sysfb drm drivers to allow suspend/resume.
- Support the aforementioned new drm formats in xlnx/qynqmp.
- Fix panel Kconfig dependencies.
- Add carveout support for debugging and bringup to amxdna.
- Add support for long command tx via videobuffer in bridge/tc358768.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAmn8fBIACgkQ/lWMcqZw
E8OlSw/+JbotgRTp5I3EwGtOiUoEZF1n20vkwZ5+olbEhP5wVft+Kf5MbD2/Hmja
GEL/3lxXgbvA1QOXFsED+q5UlKwtmEb3jTj+K83CXZ/YHT8Fk+lFCpNR3dGWWpal
3CAk+Xe2MYdhBe4Sce04rKYfI7D7R2p1xrvfGDO/4Z1WicI1P2BhgV+6K2buhNJ3
2FOFRLTQaBdUa/52PgP45lEvQveI5E2UHyjOk2dDEU/uE6JeMHOQzk4d/1VFY+6s
hjgC5Mzw1eRZeX3LgSsSaCZ4/vKOXUg950oMAbmGeucyPoIm2+dOt6k/bRMTolJt
wXDGmh69dJliHm5801riqaEBWwMV0JEt3WBcqAiNycIAitsjf9jACkWMfoXz03At
34qTWxWReXaQXL32ooFD2ZIZhiBSNNbZu50P5xhOAcE2F0siPH8dLSSaamSEKX5P
T+gklhoXnMljgBz/wRKW5oUC1EQrylsc2C3/vvXHopYDPFhHZ77v1m33x5mXu8jn
XvUPjMIIx62dBueGtYcODQEOhfvweeg+XWUJ0uJ1SDfqtTDjkw2oEnNqEbYOwaIF
BR8YjQn3QI5FAFt9VbilQ9lL7XBGgjT4kV8iX4qGedSwKLAzu/b+P3FyTtvNnY71
vYldKKmhVogzHO97JzVvWq3l6H6dush1REgprGCDAISUesk55g4=
=kWIv
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2026-05-07' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for v7.2-rc1:
UAPI Changes:
- Support medium/low power modes in amdxdna.
- Support limiting frequency in ivpu.
- Document license for drm core uAPI headers.
- Add the following DRM formats: P230, Y7, XYYY2101010, T430,
XVUY210101010.
Cross-subsystem Changes:
- Add and improve dt-bindings.
- Remove unused dma-fence-array's signal_on_any support.
Core Changes:
- Do not call drop_master on file close if not master.
- Convert drm-bridge and drm/atomic to use drm_printf_indent.
- Remove the extra call to drm_connector_attach_encoder after
drm_bridge_connector_init().
- Assorted docbook updates.
Driver Changes:
- Bugfixes in amdxdna, ivpu, mipi-dsi, imagination, nouveau, panthor,
bridge/analogix_dp, ipv3, lontium-lt8912b, verisilicon, tve200,
etnaviv, panel/focaltech-ota7290b, panel/jadard-jd9365da-h3,
bridge/ite-it6263, renesas, xlnx, bridge/cdns-dsi, gma500,
bridge/microchip-lvds, mgag200.
- Add support for MStar TSUMU88ADT3-LF-1 bridge.
- Add support for WaveShare 7, Novatek NT35532, Startek KD070HDFLD092,
ChipWealth CH13726A AMOLED, Team Source Display TST070WSNE-196C,
Displaytech DT050BTFT-PTS panels.
- Improve mipi-dsi shutdown and convert a panasonic panel to use the
mipi-dsi wrappers.
- Allowing dumping vbios over debugfs in GSP-RM mode.
- Update maintainers for ivpu, add reviewer for drm-bridge code
and update maintainers for LT8912B DRM HDMI bridge.
- Add test pattern support to bridge/ti-sn65dsi83.
- Convert vmwgfx to vblank timers.
- Add power management to sysfb drm drivers to allow suspend/resume.
- Support the aforementioned new drm formats in xlnx/qynqmp.
- Fix panel Kconfig dependencies.
- Add carveout support for debugging and bringup to amxdna.
- Add support for long command tx via videobuffer in bridge/tc358768.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patch.msgid.link/f73f342d-6efb-416d-81b0-1716bdd98d5f@linux.intel.com
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
Driver Changes:
- Add NULL check for media_gt in intel_hdcp_gsc_check_status (Gustavo)
- Fix EAGAIN sign in pf_migration_consume (Shuicheng)
- Fix MMIO access using PF view instead of VF view during migration (Shuicheng)
- Exclude indirect ring state page from ADS engine state size (Satya)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/afw5lsrjE4pStEml@gsse-cloud1.jf.intel.com
drm_dp_sideband_append_payload() has three related bugs when processing
device-provided sideband reply data:
1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken
directly from the DP sideband header. If a device sends msg_len=0,
curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len)
is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow).
drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy()
writes 255 bytes into msg[], both far out of bounds.
2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is
only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks
until curchunk_idx reaches curchunk_len, writing up to 15 bytes past
the end of chunk[] into msg[].
3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to
msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256],
so the memcpy can spill into adjacent struct fields.
All three are reachable from any DP MST device that can forge sideband
reply messages on a physical connection.
Fixes: ad7f8a1f9c ("drm/helper: add Displayport multi-stream helper (v0.6)")
Cc: <stable@vger.kernel.org> # v3.17+
Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260410041901.2438960-1-ashutoshdesai993@gmail.com
The phys argument to dma_iova_try_alloc() is used only to compute
the sub-granule offset (phys & (granule - 1)). Since HPAGE_PMD_SIZE
is a power of two larger than any IOMMU granule, this expression
always evaluates to zero.
Replace the ternary expressions with a plain 0, which is what the
API documentation recommends for callers doing PAGE_SIZE-aligned
transfers. This also removes the dependency on HPAGE_PMD_SIZE and
thus on CONFIG_PGTABLE_HAS_HUGE_LEAVES / HAVE_ARCH_TRANSPARENT_HUGEPAGE,
fixing build failures on architectures such as arm32 that lack that
config.
Signed-off-by: Francois Dugast <francois.dugast@intel.com>
Assisted-by: GitHub Copilot:claude-sonnet-4.6 # Documentation
Link: https://lore.kernel.org/intel-xe/c36e7dfb-cf62-4d21-a3b1-f54cb43e0832@infradead.org/
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260507091606.1067973-1-francois.dugast@intel.com
Fixes: 2e0cd372b8 ("drm/pagemap: Use dma-map IOVA alloc, link, and sync API for DRM pagemap")
Fixes: 37ad039fb3 ("drm/gpusvm: Use dma-map IOVA alloc, link, and sync API in GPU SVM")
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
dma_resv_wait_timeout() returns a positive 'remaining jiffies' value
on success, 0 on timeout, and -errno on failure.
panfrost_ioctl_wait_bo() returns this 'long' result from an int-typed
ioctl handler, so positive values reach userspace as bogus errors.
Explicitly set ret to 0 on the success path.
Fixes: f3ba91228e ("drm/panfrost: Add initial panfrost driver")
Cc: stable@vger.kernel.org
Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com
Signed-off-by: Steven Price <steven.price@arm.com>
Recent changes to add shrinker support introduced a use after free
vulnerability.
When a BO is evicted from the shrinker callback, all its CPU and GPU
mappings are invalidated. It can happen that another GPU mapping is
created for the BO after the eviction. Because of the new GPU mapping,
BO will be added back to one of the reclaim list but the state of
corresponding vm_bo will not be changed.
If vm_bo remains in evicted state and shrinker callback is invoked
again then the new GPU mapping won't be invalidated. As a result the
backing pages, which were acquired on the creation of new GPU mapping,
can get reclaimed and reused whilst they are still mapped to the GPU.
To prevent the use after free possibility, this commit removes the
evicted check for vm_bo so that all GPU mappings are checked for
invalidation.
v2:
- Update comment and add a newline in
panthor_vm_evict_bo_mappings_locked().
Fixes: fb42964e2a ("drm/panthor: Add a GEM shrinker")
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Akash Goel <akash.goel@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20260413080253.1288157-1-akash.goel@arm.com
After a GPU reset the HWSP is zeroed, so previously completed
requests appear incomplete. If such a request is picked up during
reset_rewind() and marked guilty, i915_request_set_error_once()
returns early (fence already signaled), leaving fence.error without
a fatal error code. The subsequent __i915_request_skip() then hits:
```
GEM_BUG_ON(!fatal_error(rq->fence.error))
```
Fixes a kernel BUG observed on Sandy Bridge (Gen6) during
heartbeat-triggered engine resets.
```
kernel BUG at drivers/gpu/drm/i915/i915_request.c:556!
RIP: __i915_request_skip+0x15e/0x1d0 [i915]
...
__i915_request_reset+0x212/0xa70 [i915]
reset_rewind+0xe4/0x280 [i915]
intel_gt_reset+0x30d/0x5b0 [i915]
heartbeat+0x516/0x530 [i915]
```
Guard __i915_request_skip() with i915_request_signaled(), if the
fence is already signaled, the ring content is committed and there
is nothing left to skip.
Fixes: 36e191f064 ("drm/i915: Apply i915_request_skip() on submission")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/13729
Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
Cc: stable@vger.kernel.org # v5.7+
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com
TC358768 has two ways to send DSI commands: 1) buffer the payload data
into registers (DSICMD_WDx), which supports up to 8 bytes of payload, 2)
buffer the payload data into the video buffer, which supports up to 1024
bytes of payload.
The driver currently supports method 1).
Add support for transmitting long DSI commands (more than 8 bytes, up to
1024 bytes) using the video buffer. This mode can only be used before
the actual video transmission is enabled, i.e. the initial configuration.
Original version from Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: João Paulo Gonçalves <joao.goncalves@toradex.com> # Toradex Verdin AM62
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20260311-tc358768-v2-7-e75a99131bd5@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Sending long commands using the video buffer (to be implemented in
following patches) requires setting TC358768_DATAFMT and
TC358768_DSITX_DT registers for command transfer. The same registers
also need to be configured properly for video transfer.
The long commands will be sent between the bridge's pre_enable() and
enable(), and currently we configure the registers for video transfer in
pre_enable(). Thus, they would be overwritten by the long command
transfer code.
To prevent that from happening, set those registers for video transfer
in enable(), not in pre_enable().
Based on code from Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: João Paulo Gonçalves <joao.goncalves@toradex.com> # Toradex Verdin AM62
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20260311-tc358768-v2-6-e75a99131bd5@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Currently the driver ignores MIPI_DSI_MODE_LPM and always uses HS mode.
Add code to enable HS mode in pre_enable() only if MIPI_DSI_MODE_LPM is
not set, and always enable HS mode in enable() for video transmission.
Tested-by: João Paulo Gonçalves <joao.goncalves@toradex.com> # Toradex Verdin AM62
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20260311-tc358768-v2-5-e75a99131bd5@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The driver prints a warning if MIPI_DSI_CLOCK_NON_CONTINUOUS is set, and
falls back to continuous clock mode. This was added in commit
fbc5a90e82 ("drm/bridge: tc358768: Disable non-continuous clock mode").
However, there have been multiple changes to the driver since then, and
at least in my setup, non-continuous clock mode works: I can see an
image on the panel, and I can see the clock lanes being non-continuous
with an oscilloscope.
So, let's enable MIPI_DSI_CLOCK_NON_CONTINUOUS support.
Cc: Dmitry Osipenko <digetx@gmail.com>
Tested-by: João Paulo Gonçalves <joao.goncalves@toradex.com> # Toradex Verdin AM62
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Acked-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://patch.msgid.link/20260311-tc358768-v2-4-e75a99131bd5@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Some registers can only be written indirectly, using DSI_CONFW register.
We don't have many uses for those registers (in fact, only DSI_CONTROL
is currently written), but the code to do those writes inline is a bit
confusing.
Add a new function, tc358768_confw_update_bits() which can be used to
write the bits indirectly. Only DSI_CONTROL is currently supported.
Tested-by: João Paulo Gonçalves <joao.goncalves@toradex.com> # Toradex Verdin AM62
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20260311-tc358768-v2-3-e75a99131bd5@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Enable the pre_enable_prev_first flag on the tc358768 bridge to reverse
the pre-enable order, calling bridge pre_enable before panel prepare.
This ensures the bridge is ready before sending panel init commands in
the case of panels sending init commands in panel prepare function.
Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
Tested-by: João Paulo Gonçalves <joao.goncalves@toradex.com> # Toradex Verdin AM62
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20260311-tc358768-v2-2-e75a99131bd5@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
It's "DSI_MODE", not "DIS_MODE".
Tested-by: João Paulo Gonçalves <joao.goncalves@toradex.com> # Toradex Verdin AM62
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20260311-tc358768-v2-1-e75a99131bd5@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
bochs_pci_probe() allocates the DRM device with devm_drm_dev_alloc(),
which registers a devres action to drop the initial DRM device reference
on driver detach or probe failure.
The error path currently calls drm_dev_put() manually. If probe then
returns an error, devres will run the registered release action and put
the same device again, after the first put may already have released it.
Return the probe error directly and let devres own the final put.
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Fixes: 04826f5886 ("drm/bochs: Allocate DRM device in struct bochs_device")
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260424123506.32275-1-mhun512@gmail.com
The <drm/drm_pciids.h> header only defines radeon_PCI_IDS which isn't
used in the mgag200 driver. So drop the useless include statement.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/b81a4830b3c287e9360197693a823a0dc72c674c.1777545446.git.u.kleine-koenig@baylibre.com
sparse reports:
drivers/gpu/drm/panthor/panthor_drv.c:1805:6: warning: symbol 'panthor_transparent_hugepage' was not declared. Should it be static?
Make it clean.
Signed-off-by: gyeyoung <gye976@gmail.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Link: https://patch.msgid.link/20260503144234.2150138-1-gye976@gmail.com
Fix __xe_pin_fb_vma_ggtt() to actually respect the GGTT alignment
specified by the display code. Misalignment can cause GTT faults
etc.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260430154602.11393-2-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Instead of just looking at the first plane use the fb cached overall
minimum alignment.
This aligns with how the i915 version of intel_plane_pin_fb works.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
[vsyrjala: Rebase due to pin_params]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260430154602.11393-1-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
This reverts commit 025f89b01e.
025f89b01e ("drm/i915: replace select with dependency for visible
DEBUG_OBJECTS") breaks the build in certain scenarios, presumably
because config DRM_I915_DEBUG selects DRM_I915_SW_FENCE_DEBUG_OBJECTS
without looking at its dependencies, allowing
DRM_I915_SW_FENCE_DEBUG_OBJECTS=y and DEBUG_OBJECTS=n.
Fixes: 025f89b01e ("drm/i915: replace select with dependency for visible DEBUG_OBJECTS")
Cc: Julian Braha <julianbraha@gmail.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Link: https://patch.msgid.link/20260506101957.202271-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Modify all CPUID call sites which implicitly include any of the CPUID
headers to explicitly include them instead.
For KVM's reverse_cpuid.h, just include <asm/cpuid/types.h> since it
references the CPUID_EAX..EDX symbols without using the CPUID APIs.
Note, this allows removing the inclusion of <asm/cpuid/api.h> from within
<asm/processor.h> next. That allows the CPUID API headers to include
<asm/processor.h> without introducing a circular dependency.
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20260327021645.555257-1-darwi@linutronix.de
The LVDS controller was hardcoded to JEIDA mapping, which leads to
distorted output on panels expecting VESA mapping.
Update the driver to dynamically select the appropriate mapping and
pixel size based on the panel's advertised media bus format. This
ensures compatibility with both JEIDA and VESA displays.
Signed-off-by: Sandeep Sheriker M <sandeep.sheriker@microchip.com>
Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20250625-microchip-lvds-v6-3-7ce91f89d35a@microchip.com
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Drop the unused drm_panel field from the mchp_lvds structure, and remove
the unnecessary port device node lookup, as devm_drm_of_get_bridge()
already performs the required checks internally.
Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20250625-microchip-lvds-v6-1-7ce91f89d35a@microchip.com
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
