summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorLines
2026-03-27rust: drm: gem: shmem: Add DRM shmem helper abstractionAsahi Lina-0/+7
The DRM shmem helper includes common code useful for drivers which allocate GEM objects as anonymous shmem. Add a Rust abstraction for this. Drivers can choose the raw GEM implementation or the shmem layer, depending on their needs. Signed-off-by: Asahi Lina <lina@asahilina.net> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Janne Grunau <j@jananu.net> Tested-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260316211646.650074-6-lyude@redhat.com [ * DRM_GEM_SHMEM_HELPER is a tristate; when a module driver selects it, it becomes =m. The Rust kernel crate and its C helpers are always built into vmlinux and can't reference symbols from a module, causing link errors. Thus, add RUST_DRM_GEM_SHMEM_HELPER bool Kconfig that selects DRM_GEM_SHMEM_HELPER, forcing it built-in when Rust drivers need it; use cfg(CONFIG_RUST_DRM_GEM_SHMEM_HELPER) for the shmem module. * Add cfg_attr(not(CONFIG_RUST_DRM_GEM_SHMEM_HELPER), expect(unused)) on pub(crate) use impl_aref_for_gem_obj and BaseObjectPrivate, so that unused warnings are suppressed when shmem is not enabled. * Enable const_refs_to_static (stabilized in 1.83) to prevent build errors with older compilers. * Use &raw const for bindings::drm_gem_shmem_vm_ops and add #[allow(unused_unsafe, reason = "Safe since Rust 1.82.0")]. * Fix incorrect C Header path and minor spelling and formatting issues. * Drop shmem::Object::sg_table() as the current implementation is unsound. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-27drm/i915/uncore: Do GT FIFO checks in early sanitize and forcewake getVille Syrjälä-22/+50
We're mixing up the GT FIFO debug checks (overflows and such) with RMbus unclaimed register checks. The two are quite different things as RMbus is only relevant for display registers, and the GT FIFO only relevant for GT registers. Split the GT FIFO debugs out from the unclaimed register logic and just do the checks during forcewake_get() and early init. That is still sufficient to detect if any errors have happened. Any errors would anyway be caused by overflowing the FIFO rather than accessing specific registers, so trying to figure out exactly when the error happened isn't particularly useful. To fix such issues we'd rather have to do something to slow down the rate at which registers are accessed (eg. increase GT_FIFO_NUM_RESERVED_ENTRIES or something). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260323101609.8391-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-27drm/i915/selftests: Nuke live_forcewake_domains selftestVille Syrjälä-62/+0
The live_forcewake_domains selftest doesn't really test anything particularly sensible. It only runs on platforms that have RMbus unclaimer error detection, but that only catches display registers which the test doesn't even access. I suppose if we really wanted to we might try to make the test exercise the GT FIFO instead by writing GT registers as fast as possible, and then checking GTFIFODBG to see if the FIFO has overflowed. But dunno if there's much point in that. I think a GT FIFO overflow might even be fatal to the machine. So in its current for the test doesn't really make sense, and it's in the way of moving all the RMbus noclaim stuff to the display driver side. So let's just get rid of it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260323101609.8391-2-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2026-03-27drm/i915/dsi: Place clock into LP during LPM if requestedVille Syrjälä-0/+10
TGL/ADL DSI can be configured to place the clock lane into LP state during LPM, if otherwise configured for continuous HS clock. Hook that up. VBT tells us whether this should be done. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260326111814.9800-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-27drm/i915/dsi: Fill BLLPs with blanking packets if requestedVille Syrjälä-5/+9
TGL/ADL DSI can be configured to fill all BLLPs with blanking packets. Currently we enable that always, but the VBT actually tells us whether this is desired or not. Hook that up. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260326111814.9800-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-27drm/i915/dsi: Make 'clock_stop' booleanVille Syrjälä-3/+3
The DSI 'clock_stop' parameter is a boolean, so use a real 'bool' for it. And pimp the debug print while at it. Note that we also remove the incorrect negation of the value in the debug print. That has been there since the code was introduced in commit 2ab8b458c6a1 ("drm/i915: Add support for Generic MIPI panel driver"). An earlier version of the patch https://lore.kernel.org/intel-gfx/1397454507-10273-5-git-send-email-shobhit.kumar@intel.com/ got it right, but looks like it got fumbled while dealing with other review comments. v2: Highlight the removal of the '!' (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260326111814.9800-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-27drm/i915/dsi: s/eotp_pkt/eot_pkt/Ville Syrjälä-6/+5
eotp == "End of Transmission Packet". Drop the redundant extra 'p' from 'eotp_pkt', and make the thing a boolean while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260326111814.9800-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-27drm/i915/dsi: Don't do DSC horizontal timing adjustments in command modeVille Syrjälä-2/+2
Stop adjusting the horizontal timing values based on the compression ratio in command mode. Bspec seems to be telling us to do this only in video mode, and this is also how the Windows driver does things. This should also fix a div-by-zero on some machines because the adjusted htotal ends up being so small that we end up with line_time_us==0 when trying to determine the vtotal value in command mode. Note that this doesn't actually make the display on the Huawei Matebook E work, but at least the kernel no longer explodes when the driver loads. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12045 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260326111814.9800-2-ville.syrjala@linux.intel.com Fixes: 53693f02d80e ("drm/i915/dsi: account for DSC in horizontal timings") Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2026-03-27Merge tag 'drm-xe-fixes-2026-03-26' of ↵Dave Airlie-11/+33
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Fix UAF in SRIOV migration restore (Winiarski) - Updates to HW W/a (Roper) - VMBind remap fix (Auld) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/acUgq2q2DrCUzFql@intel.com
2026-03-27Merge tag 'drm-misc-fixes-2026-03-26' of ↵Dave Airlie-24/+30
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A page mapping fix for shmem fault handler, a power-off fix for ivpu, a GFP_* flag fix for syncobj, and a MAINTAINERS update. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260326-lush-cuddly-limpet-ab2aa9@houat
2026-03-27Merge tag 'drm-intel-fixes-2026-03-26' of ↵Dave Airlie-15/+41
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - DP tunnel error handling fix - Spurious GMBUS timeout fix - Unlink NV12 planes earlier - Order OP vs. timeout correctly in __wait_for() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/acTdjAoOGkzl3dcc@jlahtine-mobl
2026-03-27Merge tag 'mediatek-drm-next-20260325' of ↵Dave Airlie-18/+34
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next - 20260325 1. mtk_dsi: enable hs clock during pre-enable 2. Remove all conflicting aperture devices during probe 3. Add support for mt8167 display blocks Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20260325160721.4891-1-chunkuang.hu@kernel.org
2026-03-26drm/xe/madvise: Accept canonical GPU addresses in xe_vm_madvise_ioctlArvind Yadav-4/+12
Userspace passes canonical (sign-extended) GPU addresses where bits 63:48 mirror bit 47. The internal GPUVM uses non-canonical form (upper bits zeroed), so passing raw canonical addresses into GPUVM lookups causes mismatches for addresses above 128TiB. Strip the sign extension with xe_device_uncanonicalize_addr() at the top of xe_vm_madvise_ioctl(). Non-canonical addresses are unaffected. Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-13-arvind.yadav@intel.com
2026-03-26drm/xe/madvise: Enable purgeable buffer object IOCTL supportArvind Yadav-17/+7
Hook the madvise_purgeable() handler into the madvise IOCTL now that all supporting infrastructure is complete: - Core purge implementation (patch 3) - BO state tracking and helpers (patches 1-2) - Per-VMA purgeable state tracking (patch 6) - Shrinker integration for memory reclamation (patch 10) This final patch enables userspace to use the DRM_XE_VMA_ATTR_PURGEABLE_STATE madvise type to mark buffers as WILLNEED/DONTNEED and receive the retained status indicating whether buffers were purged. The feature was kept disabled in earlier patches to maintain bisectability and ensure all components are in place before exposing to userspace. Userspace can detect kernel support for purgeable BOs by checking the DRM_XE_QUERY_CONFIG_FLAG_HAS_PURGING_SUPPORT flag in the query_config response. Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-12-arvind.yadav@intel.com
2026-03-26drm/xe/bo: Add purgeable shrinker state helpersArvind Yadav-1/+42
Encapsulate TTM purgeable flag updates and shrinker page accounting into helper functions to prevent desynchronization between the TTM tt->purgeable flag and the shrinker's page bucket counters. Without these helpers, direct manipulation of xe_ttm_tt->purgeable risks forgetting to update the corresponding shrinker counters, leading to incorrect memory pressure calculations. Update purgeable BO state to PURGED after successful shrinker purge for DONTNEED BOs. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-11-arvind.yadav@intel.com
2026-03-26drm/xe/dma_buf: Block export of DONTNEED/purged BOsArvind Yadav-0/+24
Don't allow exporting BOs marked DONTNEED or PURGED as dma-bufs. DONTNEED BOs can have their contents discarded at any time, making the exported dma-buf unusable for external devices. PURGED BOs have no backing store and are permanently invalid. Return -EBUSY for DONTNEED BOs (temporary purgeable state) and -EINVAL for purged BOs (permanent, no backing store). The export path now checks the BO's purgeable state before creating the dma-buf, preventing external devices from accessing memory that may be purged at any time. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-10-arvind.yadav@intel.com
2026-03-26drm/xe/bo: Block mmap of DONTNEED/purged BOsArvind Yadav-1/+26
Don't allow new CPU mmaps to BOs marked DONTNEED or PURGED. DONTNEED BOs can have their contents discarded at any time, making CPU access undefined behavior. PURGED BOs have no backing store and are permanently invalid. Return -EBUSY for DONTNEED BOs (temporary purgeable state) and -EINVAL for purged BOs (permanent, no backing store). The mmap offset ioctl now checks the BO's purgeable state before allowing userspace to establish a new CPU mapping. This prevents the race where userspace gets a valid offset but the BO is purged before actual faulting begins. Existing mmaps (established before DONTNEED) may still work until pages are purged, at which point CPU faults fail with SIGBUS. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-9-arvind.yadav@intel.com
2026-03-26drm/xe/madvise: Block imported and exported dma-bufsArvind Yadav-0/+37
Prevent marking imported or exported dma-bufs as purgeable. External devices may be accessing these buffers without our knowledge, making purging unsafe. Check drm_gem_is_imported() for buffers created by other drivers and obj->dma_buf for buffers exported to other drivers. Silently skip these BOs during madvise processing. This follows drm_gem_shmem's purgeable implementation and prevents data corruption from purging actively-used shared buffers. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-8-arvind.yadav@intel.com
2026-03-26drm/xe/madvise: Implement per-VMA purgeable state trackingArvind Yadav-7/+153
Track purgeable state per-VMA instead of using a coarse shared BO check. This prevents purging shared BOs until all VMAs across all VMs are marked DONTNEED. Add xe_bo_all_vmas_dontneed() to check all VMAs before marking a BO purgeable. Add xe_bo_recheck_purgeable_on_vma_unbind() to handle state transitions when VMAs are destroyed - if all remaining VMAs are DONTNEED the BO can become purgeable, or if no VMAs remain it transitions to WILLNEED. The per-VMA purgeable_state field stores the madvise hint for each mapping. Shared BOs can only be purged when all VMAs unanimously indicate DONTNEED. This prevents the bug where unmapping the last VMA would incorrectly flip a DONTNEED BO back to WILLNEED. The enum-based state check preserves BO state when no VMAs remain, only updating when VMAs provide explicit hints. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-7-arvind.yadav@intel.com
2026-03-26drm/xe/vm: Prevent binding of purged buffer objectsArvind Yadav-13/+70
Add purge checking to vma_lock_and_validate() to block new mapping operations on purged BOs while allowing cleanup operations to proceed. Purged BOs have their backing pages freed by the kernel. New mapping operations (MAP, PREFETCH, REMAP) must be rejected with -EINVAL to prevent GPU access to invalid memory. Cleanup operations (UNMAP) must be allowed so applications can release resources after detecting purge via the retained field. REMAP operations require mixed handling - reject new prev/next VMAs if the BO is purged, but allow the unmap portion to proceed for cleanup. The check_purged flag in struct xe_vma_lock_and_validate_flags distinguishes between these cases: true for new mappings (must reject), false for cleanup (allow). Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-6-arvind.yadav@intel.com
2026-03-26drm/xe/bo: Block CPU faults to purgeable buffer objectsArvind Yadav-0/+19
Block CPU page faults to buffer objects marked as purgeable (DONTNEED) or already purged. Once a BO is marked DONTNEED, its contents can be discarded by the kernel at any time, making access undefined behavior. Return VM_FAULT_SIGBUS immediately to fail consistently instead of allowing erratic behavior where access sometimes works (if not yet purged) and sometimes fails (if purged). For DONTNEED BOs: - Block new CPU faults with SIGBUS to prevent undefined behavior. - Existing CPU PTEs may still work until TLB flush, but new faults fail immediately. For PURGED BOs: - Backing store has been reclaimed, making CPU access invalid. - Without this check, accessing existing mmap mappings would trigger xe_bo_fault_migrate() on freed backing store, causing kernel hangs or crashes. The purgeable check is added to both CPU fault paths: - Fastpath (xe_bo_cpu_fault_fastpath): Returns VM_FAULT_SIGBUS immediately under dma-resv lock, preventing attempts to migrate/validate DONTNEED/purged pages. - Slowpath (xe_bo_cpu_fault): Returns -EFAULT under drm_exec lock, converted to VM_FAULT_SIGBUS. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-5-arvind.yadav@intel.com
2026-03-26drm/xe/madvise: Implement purgeable buffer object supportArvind Yadav-22/+298
This allows userspace applications to provide memory usage hints to the kernel for better memory management under pressure: Add the core implementation for purgeable buffer objects, enabling memory reclamation of user-designated DONTNEED buffers during eviction. This patch implements the purge operation and state machine transitions: Purgeable States (from xe_madv_purgeable_state): - WILLNEED (0): BO should be retained, actively used - DONTNEED (1): BO eligible for purging, not currently needed - PURGED (2): BO backing store reclaimed, permanently invalid Design Rationale: - Async TLB invalidation via trigger_rebind (no blocking xe_vm_invalidate_vma) - i915 compatibility: retained field, "once purged always purged" semantics - Shared BO protection prevents multi-process memory corruption - Scratch PTE reuse avoids new infrastructure, safe for fault mode Note: The madvise_purgeable() function is implemented but not hooked into the IOCTL handler (madvise_funcs[] entry is NULL) to maintain bisectability. The feature will be enabled in the final patch when all supporting infrastructure (shrinker, per-VMA tracking) is complete. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-4-arvind.yadav@intel.com
2026-03-26drm/xe/bo: Add purgeable bo state tracking and field madv to xe_boArvind Yadav-0/+62
Add infrastructure for tracking purgeable state of buffer objects. This includes: Introduce enum xe_madv_purgeable_state with three states: - XE_MADV_PURGEABLE_WILLNEED (0): BO is needed and should not be purged. This is the default state for all BOs. - XE_MADV_PURGEABLE_DONTNEED (1): BO is not currently needed and can be purged by the kernel under memory pressure to reclaim resources. Only non-shared BOs can be marked as DONTNEED. - XE_MADV_PURGEABLE_PURGED (2): BO has been purged by the kernel. Accessing a purged BO results in error. Follows i915 semantics where once purged, the BO remains permanently invalid ("once purged, always purged"). Add madv_purgeable field to struct xe_bo for state tracking of purgeable state across concurrent access paths Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-3-arvind.yadav@intel.com
2026-03-27Merge tag 'drm-misc-next-2026-03-26' of ↵Dave Airlie-1562/+4011
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.1: UAPI Changes: amdxdna: - support per-BO memory-usage queries docs: - Improve UAPI documentation panthor: - extend timestamp query with flags Core Changes: edid: - provide enum drm_output_color_format; mass-convert drivers gem-dma: - use drm_dev_dma_dev() for DMA mappings - set VM_DONTDUMP on mmap mipi-dbi: - drop simple-display; mass-convert drivers prime: - use drm_dev_dma_dev() for DMA mappings ttm: - improve handling of gfp_retry_mayfail Driver Changes: amdgpu: - use atomic_create_state for private_obj amdxdna: - refactor GEM implementation - fixes bridge: - provide clear-and-put helper for reliable cleanup - analogix_dp: Use DP helpers for link training - lontium-lt8713sx: Fix 64-bit division and Kconfig - samsung-dsim: Use clear-and-put imagination: - improve power-off sequence - support context-reset notification from firmware komeda: - support Arm China Linlon D6 plus DT bindings mediatek: - use drm_dev_dma_dev() for DMA mappings panel: - support Himax HX83121A plus DT bindings - support JuTouch JT070TM041 plus DT bindings - support Samsung S6E8FC0 plus DT bindings - himax-hx83102c: support Samsung S6E8FC0 plus DT bindings; support backlight - ili9806e: support Rocktech RK050HR345-CT106A plus DT bindings - simple: support Tianma TM050RDH03 plus DT bindings panthor: - support various sources for timestamp queries - fixes omapdrm: - use atomic_create_state for private_obj rcar-du: - fix suspend/resume wrt VSP interface - fix leak of device_link - clean up sun4i: - use drm_dev_dma_dev() for DMA mappings tegra: - use atomic_create_state for private_obj xe: - send 'none' recovery method for XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260326151812.GA76082@linux.fritz.box
2026-03-27Merge tag 'drm-xe-next-2026-03-25' of ↵Dave Airlie-288/+1201
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Hi Dave and Sima, Here goes our third, perhaps, final drm-xe-next PR towards 7.1. In the big things we have: - THP support in drm_pagemap - xe_vm_get_property_ioctl Thanks, Matt UAPI Changes: - Implement xe_vm_get_property_ioctl (Jonathan) Cross-subsystem Changes: - Enable THP support in drm_pagemap (Francois, Brost) Core Changes: - Improve VF FLR synchronization for Xe VFIO (Piotr) Driver Changes: - Fix confusion with locals on context creation (Tomasz, Fixes) - Add new SVM copy GT stats per size (Francois) - always keep track of remap prev/next (Auld, Fixes) - AuxCCS handling and render compression modifiers (Tvrtko) - Implement recent spec updates to Wa_16025250150 (Roper) - xe3p_lpg: L2 flush optimization (Tejas) - vf: Improve getting clean NULL context (Wajdeczko) - pf: Fix use-after-free in migration restore (Winiarski. Fixes) - Fix format specifier for printing pointer differences (Nathan Chancellor, Fixes) - Extend Wa_14026781792 for xe3lpg (Niton) - xe3p_lpg: Add Wa_16029437861 (Varun) - Fix spelling mistakes and comment style in ttm_resource.c (Varun) - Merge drm/drm-next into drm-xe-next (Thomas) - Fix missing runtime PM reference in ccs_mode_store (Sanjay, Fixes) - Fix uninitialized new_ts when capturing context timestamp (Umesh) - Allow reading after disabling OA stream (Ashutosh) - Page Reclamation Fixes (Brian Nguyen, Fixes) - Include running dword offset in default_lrc dumps (Roper) - Assert/Deassert I2C IRQ (Raag) - Fixup reset, wedge, unload corner cases (Zhanjun, Brost) - Fail immediately on GuC load error (Daniele) - Fix kernel-doc for DRM_XE_VM_BIND_FLAG_DECOMPRESS (Niton, Fixes) - Drop redundant entries for Wa_16021867713 & Wa_14019449301 (Roper, Fixes) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/acS5xmWC3ivPTmyV@gsse-cloud1.jf.intel.com
2026-03-27Merge tag 'amd-drm-next-7.1-2026-03-25' of ↵Dave Airlie-944/+4866
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.1-2026-03-25: amdgpu: - DSC fix - Module parameter parsing fix - PASID reuse fix - drm_edid leak fix - SMU 13.x fixes - SMU 14.x fix - Fence fix in amdgpu_amdkfd_submit_ib() - LVDS fixes - GPU page fault fix for non-4K pages - Misc cleanups - UserQ fixes - SMU 15.0.8 support - RAS updates - Devcoredump fixes - GFX queue priority fixes - DPIA fixes - DCN 4.2 updates - Add debugfs interface for pcie64 registers - SMU 15.x fixes - VCN reset fixes - Documentation fixes amdkfd: - Ordering fix in kfd_ioctl_create_process() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260325175012.4185721-1-alexander.deucher@amd.com
2026-03-26drm/xe: Fix mismatched include guards in header filesShuicheng Lin-16/+16
Fix include guard macros that don't match their respective file names: - xe_gt_idle_types.h: _XE_GT_IDLE_SYSFS_TYPES_H_ -> _XE_GT_IDLE_TYPES_H_ - xe_guc_exec_queue_types.h: _XE_GUC_ENGINE_TYPES_H_ -> _XE_GUC_EXEC_QUEUE_TYPES_H_ - xe_heci_gsc.h: __XE_HECI_GSC_DEV_H__ -> _XE_HECI_GSC_H_ - xe_hw_engine_class_sysfs.h: _XE_ENGINE_CLASS_SYSFS_H_ -> _XE_HW_ENGINE_CLASS_SYSFS_H_ - xe_late_bind_fw_types.h: _XE_LATE_BIND_TYPES_H_ -> _XE_LATE_BIND_FW_TYPES_H_ - xe_platform_types.h: _XE_PLATFORM_INFO_TYPES_H_ -> _XE_PLATFORM_TYPES_H_ - xe_tile_printk.h: _xe_tile_printk_H_ -> _XE_TILE_PRINTK_H_ These guards appear to be leftovers from file renames or copy-paste errors. Correcting them to follow the standard convention of matching the file name prevents potential include guard collisions. No functional change expected. Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20260316160451.1688247-2-shuicheng.lin@intel.com
2026-03-26drm/xe: Issue GGTT invalidation under lock in ggtt_node_removeMatthew Brost-7/+2
Async work (e.g., GuC queue teardowns) can call ggtt_node_remove, so the operation must be performed under the GGTT lock to ensure the GGTT online check remains stable. GGTT insertion and removal are heavyweight operations (e.g., queue create/destroy), so the additional serialization cost is negligible compared to ensuring correctness. Fixes: 4f3a998a173b ("drm/xe: Open-code GGTT MMIO access protection") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patch.msgid.link/20260326011207.62373-1-matthew.brost@intel.com
2026-03-26drm/xe: Remove useless comment.Maarten Lankhorst-3/+0
Commit 792d2b9a1259 ("drm: drop mtrr from i915"), added this comment, drop it since it was carried over from i915. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260326121818.122401-2-dev@lankhorst.se Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-03-26drm: rcar-du: Don't leak device_link to CMMLaurent Pinchart-21/+35
The DU driver creates device_link instances between the DU and CMMs, but never deletes them. Fix it by introducing a rcar_du_cmm structure to group the CMM device and device_link, and deleting the links at cleanup time. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260323164526.2292491-5-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-03-26drm: rcar-du: Use __free() to simplify device_node handlingLaurent Pinchart-18/+7
Replace manual of_node_put() calls with __free(). This simplifies error handling code and makes it less bug-prone. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260323164526.2292491-4-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-03-26drm: rcar-du: Store CMM device pointer instead of platform_deviceLaurent Pinchart-27/+27
The DU driver stores the CMM devices as pointers to struct platform_device, and passes them to the API exposed by the CMM driver. This is similar to how the VSP is handled, except that the VSP uses struct device pointers. Replace the CMM platform_device pointers with device pointers for consistency. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260323164526.2292491-3-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-03-26drm: rcar-du: Ensure correct suspend/resume ordering with VSPLaurent Pinchart-0/+18
The VSP serves as an interface to memory and a compositor to the DU. It therefore needs to be suspended after and resumed before the DU, to be properly stopped and restarted in a controlled fashion driven by the DU driver. This currently works by chance. Avoid relying on luck by enforcing the correct suspend/resume ordering with device links. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Reviewed-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260323164526.2292491-2-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-03-26Revert "drm: Fix use-after-free on framebuffers and property blobs when ↵Maarten Lankhorst-10/+4
calling drm_dev_unplug" This reverts commit 6bee098b91417654703e17eb5c1822c6dfd0c01d. Den 2026-03-25 kl. 22:11, skrev Simona Vetter: > On Wed, Mar 25, 2026 at 10:26:40AM -0700, Guenter Roeck wrote: >> Hi, >> >> On Fri, Mar 13, 2026 at 04:17:27PM +0100, Maarten Lankhorst wrote: >>> When trying to do a rather aggressive test of igt's "xe_module_load >>> --r reload" with a full desktop environment and game running I noticed >>> a few OOPSes when dereferencing freed pointers, related to >>> framebuffers and property blobs after the compositor exits. >>> >>> Solve this by guarding the freeing in drm_file with drm_dev_enter/exit, >>> and immediately put the references from struct drm_file objects during >>> drm_dev_unplug(). >>> >> >> With this patch in v6.18.20, I get the warning backtraces below. >> The backtraces are gone with the patch reverted. > > Yeah, this needs to be reverted, reasoning below. Maarten, can you please > take care of that and feed the revert through the usual channels? I don't > think it's critical enough that we need to fast-track this into drm.git > directly. > > Quoting the patch here again: > >> drivers/gpu/drm/drm_file.c | 5 ++++- >> drivers/gpu/drm/drm_mode_config.c | 9 ++++++--- >> 2 files changed, 10 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c >> index ec820686b3021..f52141f842a1f 100644 >> --- a/drivers/gpu/drm/drm_file.c >> +++ b/drivers/gpu/drm/drm_file.c >> @@ -233,6 +233,7 @@ static void drm_events_release(struct drm_file *file_priv) >> void drm_file_free(struct drm_file *file) >> { >> struct drm_device *dev; >> + int idx; >> >> if (!file) >> return; >> @@ -249,9 +250,11 @@ void drm_file_free(struct drm_file *file) >> >> drm_events_release(file); >> >> - if (drm_core_check_feature(dev, DRIVER_MODESET)) { >> + if (drm_core_check_feature(dev, DRIVER_MODESET) && >> + drm_dev_enter(dev, &idx)) { > > This is misplaced for two reasons: > > - Even if we'd want to guarantee that we hold a drm_dev_enter/exit > reference during framebuffer teardown, we'd need to do this > _consistently over all callsites. Not ad-hoc in just one place that a > testcase hits. This also means kerneldoc updates of the relevant hooks > and at least a bunch of acks from other driver people to document the > consensus. > > - More importantly, this is driver responsibilities in general unless we > have extremely good reasons to the contrary. Which means this must be > placed in xe. > >> drm_fb_release(file); >> drm_property_destroy_user_blobs(dev, file); >> + drm_dev_exit(idx); >> } >> >> if (drm_core_check_feature(dev, DRIVER_SYNCOBJ)) >> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c >> index 84ae8a23a3678..e349418978f79 100644 >> --- a/drivers/gpu/drm/drm_mode_config.c >> +++ b/drivers/gpu/drm/drm_mode_config.c >> @@ -583,10 +583,13 @@ void drm_mode_config_cleanup(struct drm_device *dev) >> */ >> WARN_ON(!list_empty(&dev->mode_config.fb_list)); >> list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list, head) { >> - struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]"); >> + if (list_empty(&fb->filp_head) || drm_framebuffer_read_refcount(fb) > 1) { >> + struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]"); > > This is also wrong: > > - Firstly, it's a completely independent bug, we do not smash two bugfixes > into one patch. > > - Secondly, it's again a driver bug: drm_mode_cleanup must be called when > the last drm_device reference disappears (hence the existence of > drmm_mode_config_init), not when the driver gets unbound. The fact that > this shows up in a callchain from a devres cleanup means the intel > driver gets this wrong (like almost everyone else because historically > we didn't know better). > > If we don't follow this rule, then we get races with this code here > running concurrently with drm_file fb cleanups, which just does not > work. Review pointed that out, but then shrugged it off with a confused > explanation: > > https://lore.kernel.org/all/e61e64c796ccfb17ae673331a3df4b877bf42d82.camel@linux.intel.com/ > > Yes this also means a lot of the other drm_device teardown that drivers > do happens way too early. There is a massive can of worms here of a > magnitude that most likely is much, much bigger than what you can > backport to stable kernels. Hotunplug is _hard_. Back to the drawing board, and fixing it in the intel display driver instead. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Fixes: 6bee098b9141 ("drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug") Reported-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20260326082217.39941-2-dev@lankhorst.se
2026-03-26drm/bridge: Fix refcount shown via debugfs for encoder_bridges_show()Liu Ying-5/+11
A typical bridge refcount value is 3 after a bridge chain is formed: - devm_drm_bridge_alloc() initializes the refcount value to be 1. - drm_bridge_add() gets an additional reference hence 2. - drm_bridge_attach() gets the third reference hence 3. This typical refcount value aligns with allbridges_show()'s behaviour. However, since encoder_bridges_show() uses drm_for_each_bridge_in_chain_scoped() to automatically get/put the bridge reference while iterating, a bogus reference is accidentally got when showing the wrong typical refcount value as 4 to users via debugfs. Fix this by caching the refcount value returned from kref_read() while iterating and explicitly decreasing the cached refcount value by 1 before showing it to users. Fixes: bd57048e4576 ("drm/bridge: use drm_for_each_bridge_in_chain_scoped()") Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260318-drm-misc-next-2026-03-05-fix-encoder-bridges-refcount-v3-1-147fea581279@nxp.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-03-26drm/panel: simple: Correct G190EAN01 prepare timingSebastian Reichel-1/+1
The prepare timing specified by the G190EAN01 datasheet should be between 30 and 50 ms. Considering it might take some time for the LVDS encoder to enable the signal, we should only wait the min. required time in the panel driver and not the max. allowed time. Fixes: 2f7b832fc992 ("drm/panel: simple: Add support for AUO G190EAN01 panel") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Ian Ray <ian.ray@gehealthcare.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260217142528.68613-1-ian.ray@gehealthcare.com
2026-03-26drm/panel: himax-hx83102: Add support for DSI DCS backlight controlVal Packett-0/+65
The HTF065H045 panel based on the HX83102 controller does use DCS commands for controlling backlight brightness. Make the driver fall back to DCS when no external backlight has been defined in the device tree, like many other drivers do. Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260217070121.190108-5-val@packett.cool
2026-03-26drm/panel: himax-hx83102: Add support for Holitech HTF065H045Val Packett-0/+86
This 720x1600 panel is found in several Motorola/Lenovo smartphones like the Moto G9 Play (guamp). The initialization sequence is based on the datasheet. Add it to the existing HX83102 panel driver. Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260217070121.190108-4-val@packett.cool
2026-03-26drm: panel: Add Samsung S6E8FC0 DSI controller for M1906F9 panelYedaya Katsman-0/+315
Add driver for Samsung S6E8FC0 DSI controller for M1906F9 video mode panel, found in Xiaomi Mi A3 mobile phone. Co-developed-by: Kamil Gołda <kamil.golda@protonmail.com> Signed-off-by: Kamil Gołda <kamil.golda@protonmail.com> Reviewed-by: David Heidelberg <david@ixit.cz> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yedaya Katsman <yedaya.ka@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260320-panel-patches-v7-2-3eaefc4b3878@gmail.com
2026-03-26drm/panel: sharp-ls043t1le01: make use of prepare_prev_firstDmitry Baryshkov-0/+1
The DSI link must be powered up to let panel driver to talk to the panel during prepare() callback execution. Set the prepare_prev_first flag to guarantee this. Fixes: 9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260323-panel-fix-v1-1-9f12b09161e8@oss.qualcomm.com
2026-03-26drm/panel: simple: Add Tianma TM050RDH03 panelLiu Ying-0/+3
Add the Tianma Micro-electronics TM050RDH03 5.0" WVGA TFT LCD panel. Reuse panel ontat,kd50g21-40nt-a1's panel description as they are identical. Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260227-tianma-tm050rdh03-v1-2-cab78a0d765d@nxp.com
2026-03-26drm/panel: ilitek-ili9806e: add Rocktech RK050HR345-CT106A SPI panelDario Binacchi-13/+354
Add support for the Rocktech RK050HR345-CT106A panel based on the Ilitek ILI9806E controller using the SPI bus. The driver is designed to be easily extensible to support other panels with different initialization sequences and display timings by providing a specific descriptor structure for each model. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260318073346.18041-5-dario.binacchi@amarulasolutions.com
2026-03-26drm/panel: ilitek-ili9806e: split core and DSI logicDario Binacchi-108/+192
Split the driver to support multiple transport buses. The core logic (power, GPIO, backlight) is moved to a dedicated core module, while DSI-specific code is restricted to the DSI module. Introduce DRM_PANEL_ILITEK_ILI9806E_CORE as a hidden Kconfig symbol selected by the bus-specific configuration. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260318073346.18041-3-dario.binacchi@amarulasolutions.com
2026-03-26drm/panel: ilitek-ili9806e: rename to specific DSI driverDario Binacchi-5/+5
The Ilitek ILI9806E controller can support different transport buses, such as MIPI-DSI and SPI. The current implementation is specific to the MIPI-DSI interface. In preparation for adding SPI support, rename the current Kconfig symbol and files to be DSI-specific, clarifying the current scope of the code. Since DRM_PANEL_ILITEK_ILI9806E is not used in any in-tree defconfig, the symbol is renamed directly to DRM_PANEL_ILITEK_ILI9806E_DSI without providing a legacy compatibility alias. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260318073346.18041-2-dario.binacchi@amarulasolutions.com
2026-03-26drm/panel: Add Himax HX83121A panel driverPengyu Luo-0/+761
Add a driver for panels using the Himax HX83121A Display Driver IC, including support for the BOE/CSOT PPC357DB1-4, found in HUAWEI Matebook E Go series (Gaokun2/3). Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260316084040.728106-3-mitltlatltl@gmail.com
2026-03-26drm/panel: simple: add JuTouch JT070TM041Steffen Trumtrar-0/+32
Add JuTouch Technology JT070TM041 7" 1024x600 LVDS panel support. Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-2-10255d236439@pengutronix.de
2026-03-26drm/gem-dma: set VM_DONTDUMP for mmapChen-Yu Tsai-1/+1
When the mmap function was converted from a file op to a GEM object function in commit f5ca8eb6f9bd ("drm/cma-helper: Implement mmap as GEM CMA object functions") some VM flags were not lifted from drm_gem_mmap(): - VM_IO - VM_DONTEXPAND - VM_DONTDUMP VM_DONTEXPAND was added back in commit 59f39bfa6553 ("drm/cma-helper: Set VM_DONTEXPAND for mmap"). VM_IO doesn't make sense since these are memory buffers, while "IO tells people not to look at these pages (accesses can have side effects)". Add back VM_DONTDUMP. This matches the behavior of most other GEM implementations. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260317040034.617585-1-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2026-03-26gpu: nova-core: remove `io::` qualifier to register macro invocationsAlexandre Courbot-15/+15
The kernel's `register` macro would clash with nova-core's own version if it was imported directly, so it was accessed through its `io` module during the conversion phase. Now that nova-core's `register` macro doesn't exist anymore, we can import and use it directly without risk of name collision. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260325-b4-nova-register-v4-9-bdf172f0f6ca@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-26gpu: nova-core: convert falcon registers to kernel register macroAlexandre Courbot-1291/+466
Convert all PFALCON, PFALCON2 and PRISCV registers to use the kernel's register macro and update the code accordingly. Because they rely on the same types to implement relative registers, they need to be updated in lockstep. nova-core's local register macro is now unused, so remove it. Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260325-b4-nova-register-v4-8-bdf172f0f6ca@nvidia.com [acourbot@nvidia.com: remove unused import.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-26gpu: nova-core: convert PDISP registers to kernel register macroAlexandre Courbot-5/+13
Convert all PDISP registers to use the kernel's register macro and update the code accordingly. Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260325-b4-nova-register-v4-7-bdf172f0f6ca@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
generated by cgit v1.2.3 (git 2.46.0) at 2026-04-25 23:49:41 +0000