aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-08-27drm/amdgpu: Allocate psp fw private buffer in vramHawking Zhang1-2/+1
It's not necessarily to allocate psp firmware private buffer in different memory domain in sriov and bare metal environment Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-27drm/amdgpu/gfx12: set MQD as appriopriate for queue typesAlex Deucher1-2/+6
Set the MQD as appropriate for the kernel vs user queues. Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-27drm/amdgpu/gfx11: set MQD as appriopriate for queue typesAlex Deucher1-2/+6
Set the MQD as appropriate for the kernel vs user queues. Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-08-27drm/xe: Ensure GT is in C0 during resumesXin Wang1-1/+7
This patch ensures the gt will be awake for the entire duration of the resume sequences until GuCRC takes over and GT-C6 gets re-enabled. Before suspending GT-C6 is kept enabled, but upon resume, GuCRC is not yet alive to properly control the exits and some cases of instability and corruption related to GT-C6 can be observed. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4037 Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Xin Wang <x.wang@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4037 Link: https://lore.kernel.org/r/20250827000633.1369890-3-x.wang@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-27drm/xe: make xe_gt_idle_disable_c6() handle the forcewake internallyXin Wang3-21/+15
Move forcewake_get() into xe_gt_idle_enable_c6() to streamline the code and make it easier to use. Suggested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Xin Wang <x.wang@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250827000633.1369890-2-x.wang@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-27drm/stm: ltdc: unify log systemRaphael Gallais-Pou1-69/+70
DRM_ERROR and similar are deprecated. Use drm_dev based logging. Link: https://lore.kernel.org/r/20250821130356.883553-1-raphael.gallais-pou@foss.st.com Acked-by: Yannick Fertre <yannick.fertre@foss.st.com> Link: https://lore.kernel.org/r/20250825132951.547899-1-raphael.gallais-pou@foss.st.com Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
2025-08-27drm/sysfb: Do not deref unexisting CRTC state in atomic_disableThomas Zimmermann1-4/+1
Do not access CRTC state in drm_sysfb_plane_helper_atomic_disable(). Use format from sysfb device for clearing scanout buffer. This is the behavior from before commit 061963cd9e5b ("drm/sysfb: Blit to CRTC destination format"). When being disabled, the plane has no associated CRTC. Trying to deref the format pointer results in a segmentation fault. An example stack track is shown below. [ 58.948915] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000023: 0000 [#1] SMP KASAN PTI [ 58.959971] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] [...] [ 58.979308] RIP: 0010:drm_sysfb_plane_helper_atomic_disable+0x1af/0x520 [...] [ 59.084227] Call Trace: [ 59.086682] <TASK> [ 59.088793] ? __pfx_drm_sysfb_plane_helper_atomic_disable+0x10/0x10 [ 59.095155] ? crtc_disable+0xf2/0x5a0 [ 59.098920] drm_atomic_helper_commit_planes+0x848/0x1030 [ 59.104336] drm_atomic_helper_commit_tail+0x41/0xb0 [ 59.109316] commit_tail+0x204/0x330 [ 59.112903] drm_atomic_helper_commit+0x242/0x2e0 [ 59.117618] ? __pfx_drm_atomic_helper_commit+0x10/0x10 [ 59.122851] drm_atomic_commit+0x1e1/0x290 [ 59.126957] ? drm_atomic_add_affected_connectors+0x266/0x330 [ 59.132714] ? __pfx_drm_atomic_commit+0x10/0x10 [ 59.137343] ? __pfx___drm_printfn_info+0x10/0x10 [ 59.142058] ? drm_atomic_set_crtc_for_connector+0x436/0x630 [ 59.147729] atomic_remove_fb+0x631/0x920 [ 59.151751] ? save_trace+0xcf/0x180 [ 59.155343] ? __pfx_atomic_remove_fb+0x10/0x10 [ 59.159890] ? __pfx___drm_dev_dbg+0x10/0x10 [ 59.164173] drm_framebuffer_remove+0x19a/0x710 Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 061963cd9e5b ("drm/sysfb: Blit to CRTC destination format") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14874 Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/20250826145044.954396-1-tzimmermann@suse.de
2025-08-27drm/i915/psr: Check PSR pause counter in __psr_wait_for_idle_lockedJouni Högander1-1/+1
PSR work is using __psr_wait_for_idle_locked to ensure PSR exit is completed before continuing to PSR activation. __psr_wait_for_idle_locked is unlocking PSR mutex which allows PSR disable/enable and PSR pause/resume while PSR idle is being wait. PSR enable status is already checked after locking again PSR mutex but PSR pause counter check is missing. Due to this PSR work may continue to PSR activation even PSR is paused. Fix this by checking PSR pause counter in __psr_wait_for_idle_locked after PSR mutex is locked again. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jeevan B <jeevan.b@intel.com> Link: https://lore.kernel.org/r/20250826074457.1992524-1-jouni.hogander@intel.com
2025-08-26kunit: Pass parameterized test context to generate_params()Marie Zhussupova2-11/+12
To enable more complex parameterized testing scenarios, the generate_params() function needs additional context beyond just the previously generated parameter. This patch modifies the generate_params() function signature to include an extra `struct kunit *test` argument, giving test users access to the parameterized test context when generating parameters. The `struct kunit *test` argument was added as the first parameter to the function signature as it aligns with the convention of other KUnit functions that accept `struct kunit *test` first. This also mirrors the "this" or "self" reference found in object-oriented programming languages. This patch also modifies xe_pci_live_device_gen_param() in xe_pci.c and nthreads_gen_params() in kcsan_test.c to reflect this signature change. Link: https://lore.kernel.org/r/20250826091341.1427123-4-davidgow@google.com Reviewed-by: David Gow <davidgow@google.com> Reviewed-by: Rae Moar <rmoar@google.com> Acked-by: Marco Elver <elver@google.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Marie Zhussupova <marievic@google.com> [Catch some additional gen_params signatures in drm/xe/tests --David] Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2025-08-26drm/xe/wcl: Extend L3bank mask workaroundChaitanya Kumar Borah1-1/+1
The commit 9ab440a9d042 ("drm/xe/ptl: L3bank mask is not available on the media GT") added a workaround to ignore the fuse register that L3 bank availability as it did not contain valid values. Same is true for WCL therefore extend the workaround to cover it. Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://lore.kernel.org/r/20250822002512.1129144-1-chaitanya.kumar.borah@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-08-26drm/xe: switch to local xbasename() helperCarlos Llamas1-1/+9
Commit b0a2ee5567ab ("drm/xe: prepare xe_gen_wa_oob to be multi-use") introduced a call to basename(). The GNU version of this function is not portable and fails to build with alternative libc implementations like musl or bionic. This causes the following build error: drivers/gpu/drm/xe/xe_gen_wa_oob.c:130:12: error: assignment to ‘const char *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 130 | fn = basename(fn); | ^ While a POSIX version of basename() could be used, it would require a separate header plus the behavior differs from GNU version in that it might modify its argument. Not great. Instead, implement a local xbasename() helper based on strrchr() that provides the same functionality and avoids portability issues. Fixes: b0a2ee5567ab ("drm/xe: prepare xe_gen_wa_oob to be multi-use") Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Tiffany Yang <ynaffit@google.com> Signed-off-by: Carlos Llamas <cmllamas@google.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250825155743.1132433-1-cmllamas@google.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 41be792f5baaf90d744a9a9e82994ce560ca9582) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe: Don't trigger rebind on initial dma-buf validationMatthew Brost1-1/+2
On the first validate of an imported dma-buf (initial bind), the device has no GPU mappings, so a rebind is unnecessary. Rebinding here is harmful in multi-GPU setups and for VMs using preempt-fence mode, as it would evict in-flight GPU work. v2: - Drop dma_buf_validated, check for XE_PL_SYSTEM (Thomas) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/20250825152841.3837378-1-matthew.brost@intel.com (cherry picked from commit ffdf968762e4fb3cdae54e811ec3525e67440a60) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe/vm: Clear the scratch_pt pointer on errorThomas Hellström1-2/+6
Avoid triggering a dereference of an error pointer on cleanup in xe_vm_free_scratch() by clearing any scratch_pt error pointer. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Fixes: 06951c2ee72d ("drm/xe: Use NULL PTEs as scratch PTEs") Cc: Brian Welty <brian.welty@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821143045.106005-4-thomas.hellstrom@linux.intel.com (cherry picked from commit 358ee50ab565f3c8ea32480e9d03127a81ba32f8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe/vm: Don't pin the vm_resv during validationThomas Hellström2-16/+4
The pinning has the odd side-effect that unlocking *any* resv during validation triggers an "unlocking pinned lock" warning. Cc: Matthew Brost <matthew.brost@intel.com> Fixes: 5cc3325584c4 ("drm/xe: Rework eviction rejection of bound external bos") Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821143045.106005-2-thomas.hellstrom@linux.intel.com (cherry picked from commit 0a51bf3e54dd8b77e6f1febbbb66def0660862d2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe/xe_sync: avoid race during ufence signalingZbigniew Kempczyński1-1/+1
Marking ufence as signalled after copy_to_user() is too late. Worker thread which signals ufence by memory write might be raced with another userspace vm-bind call. In map/unmap scenario unmap may still see ufence is not signalled causing -EBUSY. Change the order of marking / write to user-fence fixes this issue. Fixes: 977e5b82e090 ("drm/xe: Expose user fence from xe_sync_entry") Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5536 Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250820083903.2109891-2-zbigniew.kempczynski@intel.com (cherry picked from commit 8ae04fe9ffc93d6bc3bc63ac08375427d69cee06) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe/xe_hw_error: Add fault injection to trigger csc error handlerRiana Tauro2-1/+16
Add a debugfs fault handler to trigger csc error handler that wedges the device and enables runtime survivability mode. v2: add debugfs only for bmg (Umesh) v3: do not use csc_fault attribute if debugfs is not enabled v4: rebase Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250826063419.3022216-11-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe/xe_hw_error: Handle CSC Firmware reported Hardware errorsRiana Tauro5-3/+75
Add support to handle CSC firmware reported errors. When CSC firmware errors are encoutered, a error interrupt is received by the GFX device as a MSI interrupt. Device Source control registers indicates the source of the error as CSC The HEC error status register indicates that the error is firmware reported Depending on the type of error, the error cause is written to the HEC Firmware error register. On encountering such CSC firmware errors, the graphics device is non-recoverable from driver context. The only way to recover from these errors is firmware flash. System admin/userspace is notified of the necessity of firmware flash with a combination of vendor-specific drm device edged uevent, dmesg logs and runtime survivability sysfs. It is the responsiblity of the consumer to verify all the actions and then trigger a firmware flash using tools like fwupd. $ udevadm monitor --property --kernel monitor will print the received events for: KERNEL - the kernel uevent KERNEL[754.709341] change /devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/card0 (drm) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:01.0/0000:03:00.0/drm/card0 SUBSYSTEM=drm WEDGED=vendor-specific DEVNAME=/dev/dri/card0 DEVTYPE=drm_minor SEQNUM=5973 MAJOR=226 MINOR=0 Logs xe 0000:03:00.0: [drm] *ERROR* [Hardware Error]: Tile0 reported NONFATAL error 0x20000 xe 0000:03:00.0: [drm] *ERROR* [Hardware Error]: NONFATAL: HEC Uncorrected FW FD Corruption error reported, bit[2] is set xe 0000:03:00.0: Runtime Survivability mode enabled xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged. IOCTLs and executions are blocked. Only a rebind may clear the failure Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/xe/kernel/issues/new xe 0000:03:00.0: [drm] device wedged, needs recovery xe 0000:03:00.0: Firmware flash required, Please refer to the userspace documentation for more details! Runtime survivability Sysfs: /sys/bus/pci/devices/<device>/survivability_mode v2: use vendor recovery method with runtime survivability (Christian, Rodrigo, Raag) v3: move declare wedged to runtime survivability mode (Rodrigo) v4: update commit message Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250826063419.3022216-10-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe: Add support to handle hardware errorsRiana Tauro6-0/+145
Gfx device reports two classes of errors: uncorrectable and correctable. Depending on the severity uncorrectable errors are further classified Non-Fatal and Fatal. Correctable and Non-Fatal errors: These errors are reported as MSI. Bits in the Master Interrupt Register indicate the class of the error. The source of the error is then read from the Device Error Source Register. Fatal errors: These are reported as PCIe errors When a PCIe error is asserted, the OS will perform a SBR (Secondary Bus reset) which causes the driver to reload. The error registers are sticky and the values are maintained through SBR. Add basic support to handle these errors. Bspec: 50875, 53073, 53074, 53075, 53076 v2: Format commit message (Umesh) v3: fix documentation (Stuart) Cc: Stuart Summers <stuart.summers@intel.com> Co-developed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://lore.kernel.org/r/20250826063419.3022216-9-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe/doc: Document device wedged and runtime survivabilityRiana Tauro2-8/+54
Add documentation for vendor specific device wedged recovery method and runtime survivability. v2: fix documentation (Raag) v3: add userspace tool for firmware update (Raag) v4: use consistent documentation (Raag) v5: add more documentation Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250826063419.3022216-8-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe/xe_survivability: Add support for Runtime survivability modeRiana Tauro3-1/+44
Certain runtime firmware errors can cause the device to be in a unusable state requiring a firmware flash to restore normal operation. Runtime Survivability Mode indicates firmware flash is necessary by wedging the device and exposing survivability mode sysfs. The below sysfs is an indication that device is in survivability mode /sys/bus/pci/devices/<device>/survivability_mode v2: Fix kernel-doc (Umesh) v3: Add user friendly dmesg (Frank) Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250826063419.3022216-7-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe/xe_survivability: Refactor survivability modeRiana Tauro6-33/+81
Refactor survivability mode code to support both boot and runtime survivability. Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250826063419.3022216-6-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe: Add a helper function to set recovery methodRiana Tauro3-5/+24
Add a helper function to set recovery method. The recovery method can be set before declaring the device wedged and sending the drm wedged uevent. If no method is set, default unbind/re-bind method will be set. v2: fix documentation (Raag) Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250826063419.3022216-5-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe: Set GT as wedged before sending wedged ueventRiana Tauro1-4/+8
Userspace should be notified after setting the device as wedged. Re-order function calls to set gt wedged before sending uevent. Cc: Matthew Brost <matthew.brost@intel.com> Suggested-by: Raag Jadav <raag.jadav@intel.com> Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250826063419.3022216-4-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm: Add a vendor-specific recovery method to drm device wedged ueventRiana Tauro1-0/+2
Address the need for a recovery method (firmware flash on Firmware errors) introduced in the later patches of Xe KMD. Whenever XE KMD detects a firmware error, a firmware flash is required to recover the device to normal operation. The initial proposal to use 'firmware-flash' as a recovery method was not applicable to other drivers and could cause multiple recovery methods specific to vendors to be added. To address this a more generic 'vendor-specific' method is introduced, guiding users to refer to vendor specific documentation and system logs for detailed vendor specific recovery procedure. Add a recovery method 'WEDGED=vendor-specific' for such errors. Vendors must provide additional recovery documentation if this method is used. It is the responsibility of the consumer to refer to the correct vendor specific documentation and usecase before attempting a recovery. For example: If driver is XE KMD, the consumer must refer to the documentation of 'Device Wedging' under 'Documentation/gpu/xe/'. v2: fix documentation (Raag) v3: add more details to commit message (Sima, Rodrigo, Raag) add an example script to the documentation (Raag) v4: use consistent naming (Raag) v5: fix commit message v6: add more documentation Cc: André Almeida <andrealmeid@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona.vetter@ffwll.ch> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250826063419.3022216-3-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26drm/xe: Add documentation for Xe Device WedgingRiana Tauro1-0/+10
Add documentation for Xe Device Wedging so that file can be referenced in following patches. Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250826063419.3022216-2-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-26Revert "drm/tegra: Use dma_buf from GEM object instance"Thomas Zimmermann1-1/+1
This reverts commit 482c7e296edc0f594e8869a789a40be53c49bd6a. The dma_buf field in struct drm_gem_object is not stable over the object instance's lifetime. The field becomes NULL when user space releases the final GEM handle on the buffer object. This resulted in a NULL-pointer deref. Workarounds in commit 5307dce878d4 ("drm/gem: Acquire references on GEM handles for framebuffers") and commit f6bfc9afc751 ("drm/framebuffer: Acquire internal references on GEM handles") only solved the problem partially. They especially don't work for buffer objects without a DRM framebuffer associated. Hence, this revert to going back to using .import_attach->dmabuf. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20250715084549.41473-1-tzimmermann@suse.de
2025-08-26drm/vesadrm: Support DRM_FORMAT_C8Thomas Zimmermann1-1/+113
Add support for DRM_FORMAT_C8 to vesadrm. The new pixel-format description PIXEL_FORMAT_C8 describes the layout. Vesadrm's helpers vesadrm_fill_palette_lut() and vesadrm_load_palette_lut() set the hardware palette according to the CRTC's output format. The driver emulates XRGB8888 by converting the source buffer to RGB332 and using the resulting 256 colors as index into the hardware palette. The hardware palette converts back to RGB during scanout. This has no overhead compared to other format conversion, but allows common userspace, such as Wayland compositors, to operate on the display. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-10-tzimmermann@suse.de
2025-08-26drm/vesadrm: Prepare color management for palette-based framebuffersThomas Zimmermann1-8/+15
Distiguish between component-based formats and 'the rest' in vesadrm's color management. Scanout buffers with component-based format allow for gamma correction. Palette-based formats (i.e., 'the rest') require palette setup. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-9-tzimmermann@suse.de
2025-08-26drm/vesadrm: Rename vesadrm_set_gamma_lut() to vesadrm_set_color_lut()Thomas Zimmermann1-8/+8
Rename vesadrm's gamma helpers in preparation of the upcoming support for color palettes. Gamma correction and color palettes share the same hardware features, but the driver's old naming only indicated support for gamma LUTs. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-8-tzimmermann@suse.de
2025-08-26drm/format-helper: Add XRGB8888-to-RGB332 to drm_fb_blit()Thomas Zimmermann1-0/+3
List the conversion from XRGB8888-to-RGB332 in drm_fb_blit(), so that drivers based on sysfb-helpers can use it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-7-tzimmermann@suse.de
2025-08-26drm/color-mgmt: Prepare for RGB332 palettesThomas Zimmermann1-0/+34
Add helper drm_crtc_fill_palette_332(), which fills palettes with RGB332 color data. Each color in RGB332 format serves as an index into an 8-bit palette that stores the corresponding component-based colors. Vesadrm will use the new helper to emulate RGB formats on top of framebuffers in C8 format. v2: - add comments on bit operations (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-6-tzimmermann@suse.de
2025-08-26drm/sysfb: Blit to CRTC destination formatThomas Zimmermann2-11/+20
Use the color format stored in struct drm_sysfb_crtc_state for color-format conversion instead of the scanout-buffer format announced by firmware. Currently, both values are identical. This will allow drivers to modify the CRTC's input format to a certain extend. Specifically, vesadrm will be able to display RGB framebuffers when the scanout buffer is of C8 format. With color- format conversion to RGB332 and correct setup of the C8 palette, displaying XRGB8888-based buffers under C8 can be achieved. v2: - refer to RGB332 as CRTC input format Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-5-tzimmermann@suse.de
2025-08-26drm/sysfb: Find screen_info format with helpersThomas Zimmermann1-12/+9
Convert drm_sysfb_get_format_si() to lookup the screen_info color format as struct pixel_format with screen_info_pixel_format(). Then search the list of given formats for the screen_info format with pixel_format_equal(). Replaces custom code with helpers. The pixel-compare helper pixel_format_equal() also handles indexed color formats. Prepares for sysfb drivers to support color palettes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250714151513.309475-4-tzimmermann@suse.de
2025-08-26drm/i915/psr: Do not unnecessarily remove underrun on idle PSR WAJouni Högander1-2/+3
We are currently removing underrun on idle PSR WA even if it's not applied. Fix this by checking pkg_c_latency_used on PSR exit as well. Fixes: 9b1795e9b0ae ("drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed vblank") Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://lore.kernel.org/r/20250822105846.1023631-1-jouni.hogander@intel.com
2025-08-26drm/xe/uapi: Add UAPI for querying VMA count and memory attributesHimal Prasad Ghimiray3-1/+105
Introduce the DRM_IOCTL_XE_VM_QUERY_MEMORY_RANGE_ATTRS ioctl to allow userspace to query memory attributes of VMAs within a user specified virtual address range. Userspace first calls the ioctl with num_mem_ranges = 0, sizeof_mem_ranges_attr = 0 and vector_of_vma_mem_attr = NULL to retrieve the number of memory ranges (vmas) and size of each memory range attribute. Then, it allocates a buffer of that size and calls the ioctl again to fill the buffer with memory range attributes. This two-step interface allows userspace to first query the required buffer size, then retrieve detailed attributes efficiently. v2 (Matthew Brost) - Use same ioctl to overload functionality v3 - Add kernel-doc v4 - Make uapi future proof by passing struct size (Matthew Brost) - make lock interruptible (Matthew Brost) - set reserved bits to zero (Matthew Brost) - s/__copy_to_user/copy_to_user (Matthew Brost) - Avod using VMA term in uapi (Thomas) - xe_vm_put(vm) is missing (Shuicheng) v5 - Nits - Fix kernel-doc Cc: Matthew Brost <matthew.brost@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-21-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe: Enable madvise ioctl for xeHimal Prasad Ghimiray1-0/+2
Ioctl enables setting up of memory attributes in user provided range. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-20-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe: Reset VMA attributes to default in SVM garbage collectorHimal Prasad Ghimiray3-48/+190
Restore default memory attributes for VMAs during garbage collection if they were modified by madvise. Reuse existing VMA if fully overlapping; otherwise, allocate a new mirror VMA. v2 (Matthew Brost) - Add helper for vma split - Add retry to get updated vma v3 - Rebase on gpuvm layer Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-19-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/vm: Add helper to check for default VMA memory attributesHimal Prasad Ghimiray3-0/+32
Introduce a new helper function `xe_vma_has_default_mem_attrs()` to determine whether a VMA's memory attributes are set to their default values. This includes checks for atomic access, PAT index, and preferred location. Also, add a new field `default_pat_index` to `struct xe_vma_mem_attr` to track the initial PAT index set during the first bind. This helps distinguish between default and user-modified pat index, such as those changed via madvise. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-18-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/madvise: Skip vma invalidation if mem attr are unchangedHimal Prasad Ghimiray2-22/+52
If a VMA within the madvise input range already has the same memory attribute as the one requested by the user, skip PTE zapping for that VMA to avoid unnecessary invalidation. v2 (Matthew Brost) - fix skip_invalidation for new attributes - s/u32/bool - Remove unnecessary assignment for kzalloc'ed Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-17-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/bo: Update atomic_access attribute on madviseHimal Prasad Ghimiray4-28/+102
Update the bo_atomic_access based on user-provided input and determine the migration to smem during a CPU fault v2 (Matthew Brost) - Avoid cpu unmapping if bo is already in smem - check atomics on smem too for ioctl - Add comments v3 - Avoid migration in prefetch v4 (Matthew Brost) - make sanity check function bool - add assert for smem placement - fix doc v5 (Matthew Brost) - NACK atomic fault with DRM_XE_ATOMIC_CPU Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-16-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/bo: Add attributes field to xe_boHimal Prasad Ghimiray1-0/+8
A single BO can be linked to multiple VMAs, making VMA attributes insufficient for determining the placement and PTE update attributes of the BO. To address this, an attributes field has been added to the BO. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-15-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Consult madvise preferred location in prefetchHimal Prasad Ghimiray2-19/+35
When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC, prefetch svm ranges to preferred location provided by madvise. v2 (Matthew Brost) - Fix region, devmem_fd usages - consult madvise is applicable for other vma's too. v3 - Fix atomic handling v4 - Fix xe_svm_range_validate to check for DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC too. Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-14-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Support DRM_XE_SVM_MEM_RANGE_ATTR_PAT memory attributeHimal Prasad Ghimiray1-2/+22
This attributes sets the pat_index for the svm used vma range, which is utilized to ascertain the coherence. v2 (Matthew Brost) - Pat index sanity check Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-12-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/madvise: Update migration policy based on preferred locationHimal Prasad Ghimiray3-2/+76
When the user sets the valid devmem_fd as a preferred location, GPU fault will trigger migration to tile of device associated with devmem_fd. If the user sets an invalid devmem_fd the preferred location is current placement(smem) only. v2(Matthew Brost) - Default should be faulting tile - remove devmem_fd used as region v3 (Matthew Brost) - Add migration_policy - Fix return condition - fix migrate condition v4 -Rebase v5 - Add check for userptr and bo based vmas Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-11-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Add svm ranges migration policy on atomic accessHimal Prasad Ghimiray5-30/+99
If the platform does not support atomic access on system memory, and the ranges are in system memory, but the user requires atomic accesses on the VMA, then migrate the ranges to VRAM. Apply this policy for prefetch operations as well. v2 - Drop unnecessary vm_dbg v3 (Matthew Brost) - fix atomic policy - prefetch shouldn't have any impact of atomic - bo can be accessed from vma, avoid duplicate parameter v4 (Matthew Brost) - Remove TODO comment - Fix comment - Dont allow gpu atomic ops when user is setting atomic attr as CPU v5 (Matthew Brost) - Fix atomic checks - Add userptr checks Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-10-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe: Implement madvise ioctl for xeHimal Prasad Ghimiray3-0/+324
This driver-specific ioctl enables UMDs to control the memory attributes for GPU VMAs within a specified input range. If the start or end addresses fall within an existing VMA, the VMA is split accordingly. The attributes of the VMA are modified as provided by the users. The old mappings of the VMAs are invalidated, and TLB invalidation is performed if necessary. v2(Matthew brost) - xe_vm_in_fault_mode can't be enabled by Mesa, hence allow ioctl in non fault mode too - fix tlb invalidation skip for same ranges in multiple op - use helper for tlb invalidation - use xe_svm_notifier_lock/unlock helper - s/lockdep_assert_held/lockdep_assert_held_write - Add kernel-doc v3(Matthew Brost) - make vfunc fail safe - Add sanitizing input args before vfunc v4(Matthew Brost/Shuicheng) - Make locks interruptable - Error handling fixes - vm_put fixes v5(Matthew Brost) - Flush garbage collector before any locking. - Add check for null vma Cc: Matthew Brost <matthew.brost@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-9-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Add xe_svm_ranges_zap_ptes_in_range() for PTE zappingHimal Prasad Ghimiray3-1/+71
Introduce xe_svm_ranges_zap_ptes_in_range(), a function to zap page table entries (PTEs) for all SVM ranges within a user-specified address range. -v2 (Matthew Brost) Lock should be called even for tlb_invalidation v3(Matthew Brost) - Update comment - s/notifier->itree.start/drm_gpusvm_notifier_start - s/notifier->itree.last + 1/drm_gpusvm_notifier_end - use WRITE_ONCE Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-8-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe: Allow CPU address mirror VMA unbind with gpu bindings for madviseHimal Prasad Ghimiray3-2/+48
In the case of the MADVISE ioctl, if the start or end addresses fall within a VMA and existing SVM ranges are present, remove the existing SVM mappings. Then, continue with ops_parse to create new VMAs by REMAP unmapping of old one. v2 (Matthew Brost) - Use vops flag to call unmapping of ranges in vm_bind_ioctl_ops_parse - Rename the function v3 - Fix doc v4 - check if range is already in garbage collector (Matthew Brost) Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-7-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/svm: Split system allocator vma incase of madvise callHimal Prasad Ghimiray3-0/+111
If the start or end of input address range lies within system allocator vma split the vma to create new vma's as per input range. v2 (Matthew Brost) - Add lockdep_assert_write for vm->lock - Remove unnecessary page aligned checks - Add kerrnel-doc and comments - Remove unnecessary unwind_ops and return v3 - Fix copying of attributes v4 - Nit fixes v5 - Squash identifier for madvise in xe_vma_ops to this patch v6/v7/v8 - Rebase on drm_gpuvm changes Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-6-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
2025-08-26drm/xe/vma: Modify new_vma to accept struct xe_vma_mem_attr as parameterHimal Prasad Ghimiray1-7/+17
This change simplifies the logic by ensuring that remapped previous or next VMAs are created with the same memory attributes as the original VMA. By passing struct xe_vma_mem_attr as a parameter, we maintain consistency in memory attributes. -v2 *dst = *src (Matthew Brost) -v3 (Matthew Brost) Drop unnecessary helper pass attr ptr as input to new_vma and vma_create Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250821173104.3030148-5-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-01-04 09:14:07 +0000