summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
17 hoursMerge branch 'for-linux-next' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/rust/kernel.git
17 hoursMerge branch 'drm-xe-next' of https://gitlab.freedesktop.org/drm/xe/kernel.gitMark Brown
# Conflicts: # drivers/gpu/drm/xe/tests/xe_rtp_test.c # drivers/gpu/drm/xe/xe_hw_engine.c # drivers/gpu/drm/xe/xe_reg_whitelist.c # drivers/gpu/drm/xe/xe_tuning.c # drivers/gpu/drm/xe/xe_wa.c
17 hoursMerge branch 'for-linux-next' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/i915/kernel.git
17 hoursMerge branch 'drm-next' of https://gitlab.freedesktop.org/agd5f/linux.gitMark Brown
# Conflicts: # drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c # drivers/gpu/drm/amd/amdgpu/amdgpu_device.c # drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c # drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
17 hoursMerge branch 'for-linux-next' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/misc/kernel.git
17 hoursMerge branch 'master' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
17 hoursMerge branch 'for-next' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git
18 hoursMerge branch 'for-linux-next-fixes' of ↵pending-fixesMark Brown
https://gitlab.freedesktop.org/drm/misc/kernel.git
20 hoursdrm/ssd130x: fix column and row end address in partial updates in ssd133xAmit Barzilai
On partial screen updates, SSD133X controllers expect to get the rectangle addresses as arguments of the "Set Column Address" and "Set Row Address" commands. Each command expects the start address and end address of the row/column in absolute format, however the end addresses were being sent in a relative format (relative to the start address). The relative end addresses work only when the start address is 0. In those situations, there is no value difference between relative and absolute addresses. Fixes: b4299c936d8fd ("drm/ssd130x: Add support for the SSD133x OLED controller family") Cc: stable@vger.kernel.org Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260622122604.32500-4-amit.barzilai22@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
20 hoursdrm/ssd130x: hoist column and row addresses out of repeated divisionAmit Barzilai
The ssd132x_update_rect had to calculate the column address twice in the same function by dividing the byte address and the segment_width. Optimize this by hoisting the result into a col variable. Renamed the "y" variable to "row" to match the change made in the x axis. Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260622122604.32500-3-amit.barzilai22@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
20 hoursdrm/ssd130x: fix column and row end address in partial updates for ssd132xAmit Barzilai
On partial screen updates, SSD132X controllers expect to get the rectangle addresses as arguments of the "Set Column Address" and "Set Row Address" commands. Each command expects the start address and end address of the row/column in absolute format, however the end addresses were being sent in a relative format (relative to the start address). The relative end addresses work only when the start address is 0. In those situations, there is no value difference between relative and absolute addresses. Fixes: fdd591e00a9c9 ("drm/ssd130x: Add support for the SSD132x OLED controller family") Cc: stable@vger.kernel.org Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260622122604.32500-2-amit.barzilai22@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
25 hoursdrm/i915/psr: Block DC3CO entry during active frameDibin Moolakadan Subrahmanian
On Xe3P, when PSR2 is enabled on a panel that does not support Early Transport, DC3CO can be entered in the middle of an active frame. This prevents the pipe from completing the frame and leaves it in a bad state that does not recover well, causing visible corruption on screen. Set CHICKEN_DCPR_4 bit 24 in the PSR2 enable path when Early Transport is not in use, to notify DMC to prevent DC3CO entry. v2: - Remove display from commit header (Suraj Kandpal). - Add HSD number to intel_display_wa framework (Suraj Kandpal). - Change register prefix from XE3LPD_ to XE3P_ (Suraj Kandpal). BSpec: 71483, 75253 Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260701100650.1689665-2-dibin.moolakadan.subrahmanian@intel.com
2 dayshwrng: qcom - Move qcom-rng.c into drivers/char/hw_random/Eric Biggers
Since this file just implements a hwrng driver, move it into drivers/char/hw_random/. Rename the kconfig option accordingly as well. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3 daysMerge tag 'drm-fixes-2026-07-04' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Weekly fixes for drm. This is large for rc2 but it's just a lot of small fixes across a bunch of drivers, xe, amdgpu as usual, plus some sashiko-inspired fixes for panthor, and some dma-fence updates. core: - kernel doc fix - include types.h in drm_ras.h dma-fence: - fix NULL ptr dereference - use correct callback - make dma_fence_dedup_array more robust dp: - handle torn down topology gracefully - fix kernel doc i915: - Input validation fixes for BIOS and EDID - Fix HDCP code buffer overflow and seq_num_v monotonic increase check - Fix near-NULL deref in i915_active during GFP_ATOMIC exhaustion xe: - Wedge from the timeout handler only after releasing the queue - Fix a NULL pointer dereference - Remove redundant exec_queue_suspended - RTP / OA whitelist fixes - Return error on non-migratable faults requiring devmem - Skip FORCE_WC and vm_bound check for external dma-bufs - Hold notifier lock for write on inject test path - Drop bogus static from finish in force_invalidate - Fix double-free of managed BO in error path - Don't attempt to process FAST_REQ or EVENT relays - Fix NPD in bo_meminfo - Prevent invalid cursor access for purged BOs - Fix offset alignment for MERT WHITELST_OA_MERT_MMIO_TRG amdgpu: - Soc24 aborted suspend fix - Drop unecessary BUG() and BUG_ON() from error paths - SCPM fix - Power reporting fix - DCE HDR fix - UVD boundary checks - VCN boundary checks - VCE boundary checks - DCN 4.2 fixes - Large stack allocation fixes - Fix aperture mapping leak - UserQ fixes - Ignore_damage_clips fix - ACP fixes - DC boundary checks - GPUVM fixes - JPEG idle check fixes - Userptr fix - GC 11.7 updates - Non-4K page fix - SMU 13 fixes - DP alt mode fix amdkfd: - Boundary checks - CRIU fixes amdxdna: - fix device removal issues - fix use after free in debug BO imagination: - fix double call to scheduler fini - fix ioctl return values - fix user array stride virtio: - handle EDIDs better panthor: - irq safe fence lock fix - reset work fix - fix invalid pointer - fix iomem access in suspended state - sched resume fix - unplug suspend fix - drop needless check - eviction leak fix - bail on group start/resume fix - keep irqs masked malidp: - use clock bulk API komeda: - clock prepare fixes" * tag 'drm-fixes-2026-07-04' of https://gitlab.freedesktop.org/drm/kernel: (105 commits) drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG drm/xe/pt: prevent invalid cursor access for purged BOs drm/xe: fix NPD in bo_meminfo() drm/xe/pf: Don't attempt to process FAST_REQ or EVENT relays drm/xe/hw_engine: Fix double-free of managed BO in error path drm/xe/userptr: Drop bogus static from finish in force_invalidate drm/xe/userptr: Hold notifier_lock for write on inject test path drm/xe/display: skip FORCE_WC and vm_bound check for external dma-bufs drm/xe: Return error on non-migratable faults requiring devmem drm/xe/rtp: Ensure locking/ref counting for OA whitelists drm/xe/oa: (De-)whitelist OA registers on OA stream open/release drm/xe/rtp: (De-)whitelist OA registers for all hwe's for a gt drm/xe/rtp: Toggle 'deny' bit to (de-)whitelist OA regs drm/xe/rtp: Save OA nonpriv registers to register save/restore lists drm/xe/rtp: Generalize whitelist_apply_to_hwe drm/xe/rtp: Keep track of non-OA nonpriv slots drm/xe/rtp: Maintain OA whitelists separately drm/xe/rtp: Fix build error with clang < 21 and non-const initializers drm/imagination: Fix user array stride in pvr_set_uobj_array() drm/imagination: Fix returned size for DRM_IOCTL_PVR_DEV_QUERY ...
3 daysdrm/gpuvm: Remove dead codeAdrián Larumbe
drm_gpuva_find_{prev|next}() have no consumers. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://patch.msgid.link/20260608-gpuvm-minor-fixes-v2-1-af07ef9ca969@collabora.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
3 daysgpu: nova: fix rust-analyzer generationAlexandre Courbot
The rust-analyzer generator script recognizes a crate when its corresponding `.o` appears in the Rust source file's immediate `Makefile` or `Kbuild` file. Commit ca524e273c43 ("gpu: build nova-core and nova-drm from drivers/gpu/Makefile") moves the build rules for `nova-core` and `nova-drm` into `drivers/gpu/Makefile`, which results in the generator script ignoring these crates. Fix this by naming the crates' module as a comment in their respective `Makefile`; this is enough for the script to pick them up and restore `rust-analyzer` functionality on them. Fixes: ca524e273c43 ("gpu: build nova-core and nova-drm from drivers/gpu/Makefile") Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Onur Özkan <work@onurozkan.dev> Link: https://patch.msgid.link/20260701-nova-rust-analyzer-v1-1-5209f486f10d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
4 daysdrm/xe: remove duplicate <kunit/test-bug.h> includeAnas Khan
xe_pci.c includes <kunit/test-bug.h> twice, separated only by the <kunit/test.h> include. Drop the redundant second include; this is a non-functional cleanup flagged by scripts/checkincludes.pl. Fixes: 6cad22853cb8 ("drm/xe/kunit: Add stub to read_gmdid") Signed-off-by: Anas Khan <anxkhn28@gmail.com> Link: https://patch.msgid.link/20260702112820.34675-1-anxkhn28@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
4 daysdrm/xe: Wait on external BO kernel fences in exec IOCTLMatthew Brost
Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260702215805.4011228-1-matthew.brost@intel.com
4 daysdrm/bridge: analogix_dp: Apply standard DP training delay helpersDamon Ding
Replace hardcoded fixed usleep_range() delays during clock recovery and channel equalization with drm_dp_link_train_clock_recovery_delay() and drm_dp_link_train_channel_eq_delay() helpers. The original fixed delays are only valid for the case where bit[6:0] of DPCD TRAINING_AUX_RD_INTERVAL(0000Eh) is 0x00, while core helpers apply spec-compliant timings matching actual receiver capability values. Additionally, add dpcd buffer to struct analogix_dp_device to cache receiver capabilities. Call drm_dp_read_dpcd_caps() at commit entry to populate cached DPCD data for subsequent link training steps, and prepare for further usage of other DP helper APIs. Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Tested-by: Vicente Bergas <vicencb@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260623075207.320603-1-damon.ding@rock-chips.com
4 daysdrm/bridge: analogix_dp: Fix PE/VS value shift mismatch during link trainingDamon Ding
VS/PE values returned by drm_dp_get_adjust_request_voltage() and drm_dp_get_adjust_request_pre_emphasis() are already encoded to their native DPCD register bit positions. However, DPCD_VOLTAGE_SWING_SET / DPCD_PRE_EMPHASIS_SET macros perform an extra internal shift. Feeding the raw offset-bearing values directly leads to overlapping bitfields and invalid lane training configuration, causing link training failures and black screen. Add right shift using DP_TRAIN_*_SHIFT constants to strip the DPCD bit offsets before passing values to the SET macros and subsequent checks. Apply this fix for both clock recovery and adjust training code paths. Reported-by: Vicente Bergas <vicencb@gmail.com> Closes: https://lore.kernel.org/all/CAAMcf8D-d+5n=H44KeKBSqWY42m+o32W+mO-r15VqWNyYhJL7Q@mail.gmail.com/ Fixes: d84b087c7662 ("drm/bridge: analogix_dp: Apply DP helper APIs to get adjusted voltages and pre-emphasises") Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Link: https://lore.kernel.org/all/CAAMcf8D-d+5n=H44KeKBSqWY42m+o32W+mO-r15VqWNyYhJL7Q@mail.gmail.com/ Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260623023506.309858-1-damon.ding@rock-chips.com
4 daysdrm/i915/mst: limit DP MST ESI service loopJani Nikula
The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: 3c0ec2c2d594 ("drm/i915: Flatten intel_dp_check_mst_status() a bit") Cc: stable@vger.kernel.org # v5.8+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260625142204.1078287-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 daysdrm/xe/display: unify runtime suspend/resume with i915 for non-d3coldJani Nikula
With the special d3cold handling in xe runtime suspend/resume separated, unify the non-d3cold paths with i915. There are multiple changes here at once that probably wouldn't make much sense to split out further. Add the call to intel_display_driver_pm_runtime_suspend(), which, for the time being, is a no-op. The intel_hpd_poll_enable() is called later. Add the call to intel_display_driver_pm_runtime_suspend_late(), which starts calling intel_display_power_runtime_suspend() and intel_opregion_notify_adapter(). Deep down, the former should take care of intel_dmc_wl_flush_release_work(), allowing us to drop the extra call in xe_display_pm_runtime_suspend_late(). The intel_hpd_poll_enable() call is also done here, postponed from the previous location in xe_display_pm_runtime_suspend(). Add the call to intel_display_driver_pm_runtime_resume_early(), which contains the intel_display_power_runtime_resume() and intel_opregion_notify_adapter() counterparts to the calls in intel_display_power_runtime_suspend_late(). Finally, intel_display_driver_pm_runtime_resume() replaces the direct calls to intel_hpd_init(), intel_hpd_poll_disable(), and skl_watermark_ipc_update(). (The hotplug poll enable/disable calls are asymmetric.) v2: - Rebase, move placement of the calls Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/16205a1ee08e83f6e2f4dd30ed98fc043684a73e.1782913901.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 daysdrm/xe/display: add xe_display_pm_runtime_resume_early()Jani Nikula
Add new display runtime PM hook xe_display_pm_runtime_resume_early(), to be called before IRQ resume. This is initially a no-op placeholder. Add comments on the timing relative to irq suspend/resume to all the runtime PM hooks. v2: Add stub for CONFIG_DRM_XE_DISPLAY=n Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260702071457.2985893-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 daysdrm/xe/display: separate d3cold handling from ↵Jani Nikula
xe_display_pm_runtime_suspend_late() Make the special d3cold paths completely separate from the rest of the runtime pm calls. The intel_dmc_wl_flush_release_work() call right after xe_display_pm_suspend_late() might be completely redundant, but this avoids any functional changes. Wiggle the comment while at it. It gets duplicated for now, but this will be addressed in the follow-up. v2: Update comments Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/73693f137e9601e027ab7e7add2a7b08d5a2f675.1782913901.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 daysdrm/{i915, xe}: add new intel_display_driver_runtime_pm_{enable, disable}()Jani Nikula
Add new high-level functions intel_display_driver_runtime_pm_enable() and intel_display_driver_runtime_pm_disable() to abstract the low-level functions intel_display_power_enable() and intel_display_power_disable(), respectively. The asymmetry in the "runtime pm enable/disable" and "pm runtime suspend/etc" naming is intentional, with the latter intended to be called from the PM hooks. Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/c95cb644a35ede7d4d456fd1654ce0b42b6eea33.1782913901.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 daysdrm/i915: add intel_display_driver_pm_runtime*() functionsJani Nikula
Add new functions intel_display_driver_pm_runtime_suspend(), intel_display_driver_pm_runtime_suspend_late(), intel_display_driver_pm_runtime_resume_early(), and intel_display_driver_pm_runtime_resume(). The IRQ suspend/resume is meant to happen between the corresponding calls. For now, intel_display_driver_pm_runtime_suspend() is empty, but is included for completeness as a placeholder. Initially, only migrate i915, as there are some differences with xe that will be addressed later. There's a functional change, which should be benign: i915_pm_runtime_resume() moves intel_opregion_notify_adapter() call slightly later. In the interest of not introducing more severe functional changes, the calls become slightly asymmetric. We might want to address this later. v2: - Rebase, move placement of suspend calls Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/81e29bd9bee6c023d079ab076af7dc4b7e8985ca.1782913901.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 daysdrm/i915: move some display runtime suspend operations earlierJani Nikula
In preparation for abstracting display runtime suspend/resume calls, relocate opregion adapter notification and hotplug poll enable slightly earlier. Even though this is intended to be a non-functional change, do it as a separate step to pinpoint any issues here. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/00d016457a78589b97972203a52a390f5f1a3541.1782913901.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 daysdrm/i915: call intel_display_power_runtime_resume() on suspend error pathJani Nikula
The vlv_suspend_complete() error path fails to call intel_display_power_runtime_resume(). Fix it. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/b0c131ed970d16d0147c87ba583abe3a4ea36ed5.1782913901.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 daysdrm/i915: call intel_uncore_runtime_resume() for each gtJani Nikula
All uncore suspend/resume calls are done on each gt. Follow suit in vlv_suspend_complete() error path purely for completeness, even if VLV/CHV only have one. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/e9dde426a8f84c75a5d61857c4259e562fa8ee41.1782913901.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
4 daysdrm/panel: visionox-vtdr6130: switch to devm panel calls and drop removeNeil Armstrong
Switch to devm_drm_panel_add() and devm_mipi_dsi_attach() and drop the remove() callback. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260703-topic-sm8x50-vtdr6130-dsc-v4-2-9eff51ec717a@linaro.org
4 daysdrm/panel: Enable DSC for Visionox VTDR6130 panelJun Nie
Enable display compression (DSC v1.2) for 1080x2400 Visionox VTDR6130 AMOLED DSI panel. This panel is the default panel for the following devices: - SM8550-QRD - SM8550-HDK - SM8650-QRD - SM8650-HDK Enable DSC since now functional in the MSM/DPU/DSI driver. Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260703-topic-sm8x50-vtdr6130-dsc-v4-1-9eff51ec717a@linaro.org
4 daysdrm: panel: add support for the Renesas R63419 based dual-DSI video mode ↵KancyJoe
Display Panels Implement support for the Renesas 63419 based dual-DSI video mode Display Panels found in the Ayaneo gaming handled devices. Signed-off-by: KancyJoe <kancy2333@outlook.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-2-8570e692143e@linaro.org
4 daysdrm/panel: add Ilitek ILI7807S panel driverArpit Saini
Add a DRM panel driver for the DLC DLC0697 1080x1920@60Hz MIPI DSI panel based on the Ilitek ILI7807S display controller. The panel operates in video burst mode with four data lanes using RGB888 pixel format. Signed-off-by: Arpit Saini <arpit.saini@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260701-ili7807s-v4-2-c7d76d4780a5@oss.qualcomm.com
4 daysReplace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c ↵Uwe Kleine-König (The Capable Hub)
files) Replace the #include of <linux/mod_devicetable.h> by the more specific <linux/device-id/*.h> where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
4 daysMerge tag 'drm-misc-fixes-2026-07-02' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2-rc2: - Fix potential null pointer dereference in dma-buf. - Handle 0 in dma_fence_dedup_array. - Use the correct callback in dma_fence_timeline_name. - Fix device removal handling in amdxdna. - kernel-doc fixes. - Include header fix for drm_ras.h - Handle edids better in virtio. - Use the clk_bulk api for error handling in malidp. - More clk handling fixes for komeda. - panthor scheduler block fallout fixes. - panthor unplug fixes. - other panthor fixes. - Fix unnecessary WARN_ON in topology probe after teardown. - Add refcount to amdxdna job to fix use-after free. - Fix increasing args->size in ioctl's of drm/imagination. - Handle stride correctly in pvr_set_uobj_array. - Only call imagination's drm_sched_entity_fini once. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/786bdc92-0ce3-4c0f-9668-b0fa8a0047ea@linux.intel.com
4 daysMerge tag 'drm-xe-fixes-2026-07-02' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Driver Changes: - Wedge from the timeout handler only after releasing the queue (Rodrigo) - Fix a NULL pointer dereference (Francois) - Remove redundant exec_queue_suspended (Lu) - RTP / OA whitelist fixes (Ashutosh, Gustavo, Thomas) - Return error on non-migratable faults requiring devmem (Matt Brost) - Skip FORCE_WC and vm_bound check for external dma-bufs (Matt Auld) - Hold notifier lock for write on inject test path (Shuicheng) - Drop bogus static from finish in force_invalidate (Shuicheng) - Fix double-free of managed BO in error path (Shuicheng) - Don't attempt to process FAST_REQ or EVENT relays (Michal) - Fix NPD in bo_meminfo (Matthew Auld) - Prevent invalid cursor access for purged BOs (Matthew Auld) - Fix offset alignment for MERT WHITELST_OA_MERT_MMIO_TRG (Ashutosh) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/akZ_UbrL94G4F2iA@fedora
4 daysMerge tag 'amd-drm-fixes-7.2-2026-07-02' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-7.2-2026-07-02: amdgpu: - Soc24 aborted suspend fix - Drop unecessary BUG() and BUG_ON() from error paths - SCPM fix - Power reporting fix - DCE HDR fix - UVD boundary checks - VCN boundary checks - VCE boundary checks - DCN 4.2 fixes - Large stack allocation fixes - Fix aperture mapping leak - UserQ fixes - Ignore_damage_clips fix - ACP fixes - DC boundary checks - GPUVM fixes - JPEG idle check fixes - Userptr fix - GC 11.7 updates - Non-4K page fix - SMU 13 fixes - DP alt mode fix amdkfd: - Boundary checks - CRIU fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260702143138.68463-1-alexander.deucher@amd.com
4 daysdrm/xe: Add tile_count to xe_probed_infoGustavo Sousa
On multi-tile platforms, we need to probe the hardware for the number of tiles that are present in the platform. That means that we should do that as part of xe_probe_info() instead of xe_info_init(). Do that. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260609-xe-probe-info-v1-9-21e83e188e60@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
4 daysdrm/xe: Don't initialize tile_count in xe_info_init_early()Gustavo Sousa
The value of xe->info.tile_count is only really valid after xe_info_probe_tile_count(). Any use of tile_count before that point is invalid and, consequently, initializing it in xe_info_init_early() is pointless. Move the initialization to xe_info_probe_tile_count(). Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260609-xe-probe-info-v1-8-21e83e188e60@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
4 daysdrm/xe: Add graphics/media IPs and their step info to xe_probed_infoGustavo Sousa
On GMDID-based platforms, the driver needs to probe the hardware by reading GMDID registers in order to identify the graphics/media/display IPs that are present in the platform as well as their stepping values. Currently, xe_info_init() has such a probing logic, but that task should be rather responsibility of xe_probe_info(). As such, move it to the latter. For pre-GMDID platforms, the IPs are identified via PCI devid and revid fields, which is arguably also hardware dependent. So do the same for those platforms. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260609-xe-probe-info-v1-7-21e83e188e60@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
4 daysdrm/xe/tests: Set non-GMDID graphics step in xe_pci_fake_device_init()Gustavo Sousa
Currently the logic to set the graphics step for non-GMDID-based platforms in kunit testing is defined in xe_wa_test_init(). That logic should rather belong to the helper xe_pci_fake_device_init(), so move it there. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260609-xe-probe-info-v1-6-21e83e188e60@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
4 daysdrm/xe: Add platform-level step info to xe_probed_infoGustavo Sousa
The platform-level step information depends on the PCI revid and, as such, should be probed in xe_probe_info_early() instead of xe_info_init_early(). Move the code accordingly. Note that we currently only update probed_info->step.platform as part of this change. We will deal with the other fields of probed_info->step as a follow-up change, which will be tied to the probing of graphics and media IPs. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260609-xe-probe-info-v1-5-21e83e188e60@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
4 daysdrm/xe/step: Make xe_step_platform_get() independent from xe->infoGustavo Sousa
Currently xe_step_platform_get() uses info fields from xe->info to define the platform-level stepping value. Because the platform-level stepping info depends on the PCI revid, it should be defined as part of xe_probe_info_early() instead of being directly probed inside xe_info_init_early(). Let's make sure that xe_step_platform_get() receives the necessary data as parameters and does not depend on xe->info. That will allow us to move the call up to xe_probe_info_early() in an upcoming change. Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260609-xe-probe-info-v1-4-21e83e188e60@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
4 daysdrm/xe: Add devid and revid to xe_probed_infoGustavo Sousa
The PCI devid and revid fields are info that we probe from the hardware (indirectly via the PCI subsystem). Add them to xe_probed_info and set them via xe_probe_info_early(), since the respective fields in xe->info are updated in xe_info_init_early(). Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260609-xe-probe-info-v1-3-21e83e188e60@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
4 daysdrm/xe/step: Pass xe_step_info to xe_step_*_get() functionsGustavo Sousa
The xe_step_*_get() functions update the step directly in xe->info.step and are called by functions xe_info_init_early() and xe_info_init(). As the stepping info is something probed from the hardware (via PCI revid and/or GMDID) and we want to move away from probing inside xe_info_init*() functions, let's make xe_step_*_get() functions modify a pointer to the step structure instead of modifying xe->info.step directly: this will allow an upcoming change that will move those function calls out of the info init functions and will pass a member of struct xe_probed_info instead of xe->info.step. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260609-xe-probe-info-v1-2-21e83e188e60@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
4 daysdrm/xe: Add framework for info probingGustavo Sousa
Functions xe_info_init_early() and xe_info_init() currently probe some information from the hardware while doing initialization of info fields. Besides mixing responsibilities, another issue from this approach is that kunit tests need to implement static stubs for the probing part. Let's prepare the ground to ensuring that those functions stop probing the information from the hardware by creating the necessary framework for extracting the probing bits out of them. Do that by creating a new struct type called xe_probed_info and the functions responsible for populating it. In upcoming changes, we will gradually refactor the code so that all info needed by xe_info_init_early() and xe_info_init() that is probed from the hardware is passed to them via struct xe_probed_info. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Reviewed-by: Violet Monti <violet.monti@intel.com> Link: https://patch.msgid.link/20260609-xe-probe-info-v1-1-21e83e188e60@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
5 daysdrm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked bindsMatthew Brost
xe_vm_populate_pgtable() indexed the source PTE array (update->pt_entries) by the per-call loop counter, assuming each call starts at the first entry of the update. That holds for the CPU bind path (xe_migrate_update_pgtables_cpu), which populates a whole update in a single call, but not for the GPU bind path: write_pgtable() splits an update into MAX_PTE_PER_SDI (510) sized MI_STORE_DATA_IMM chunks, invoking the populate callback once per chunk with an advancing qword_ofs but a fresh command- buffer destination pointer. As a result, every chunk after the first re-read pt_entries from index 0 instead of from its true offset, so PTEs beyond the first 510 entries of a single update were programmed with the wrong physical pages, shifting the mapping by exactly MAX_PTE_PER_SDI pages. This stayed latent because a single update only exceeds 510 qwords when a large (e.g. 2M) region is bound as individual 4K PTEs rather than a single huge-page entry, which happens when the backing store is sufficiently fragmented. It was surfaced by the BO defrag path, which deliberately rebinds such fragmented ranges via the GPU bind path, producing deterministic data corruption offset by 510 pages. Index pt_entries by the chunk's absolute offset relative to update->ofs so both the CPU and GPU paths pick the correct entries. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260702012434.3861171-1-matthew.brost@intel.com
5 daysdrm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRGAshutosh Dixit
'head' argument for WHITELIST_OA_MERT_MMIO_TRG was previously wrong (not multiple of 16). Fix this. Fixes: ec02e49f21bc ("drm/xe/rtp: Whitelist OAMERT MMIO trigger registers") Cc: stable@vger.kernel.org Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260629172634.1100983-1-ashutosh.dixit@intel.com (cherry picked from commit f6c23e4589bdc69a5d2f79aed5c5bddd5d406cbe) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
5 daysdrm/xe/pt: prevent invalid cursor access for purged BOsMatthew Auld
During a page table walk for binding, xe_pt_stage_bind() explicitly skips initializing the xe_res_cursor for purged BOs, treating them similarly to NULL VMAs by only setting the cursor size. However, xe_pt_hugepte_possible() and xe_pt_scan_64K() did not check if the BO was purged before attempting to walk the cursor using xe_res_dma() and xe_res_next(). Because the cursor was left uninitialized for purged BOs, this falls through and triggers warnings like: WARNING: drivers/gpu/drm/xe/xe_res_cursor.h:274 at xe_res_next Fix this by explicitly checking if the BO is purged in both xe_pt_hugepte_possible() and xe_pt_scan_64K(), returning early just as we do for NULL VMAs, avoiding the invalid cursor accesses entirely. As a precaution, also zero-initialize the cursor in xe_pt_stage_bind() to ensure we don't pass garbage data into the page table walkers if we ever hit a similar edge case in the future. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8418 Fixes: ad9843aac91a ("drm/xe/madvise: Implement purgeable buffer object support") Assisted-by: Copilot:gemini-3.1-pro-preview Reported-by: Matthew Schwartz <matthew.schwartz@linux.dev> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Matthew Schwartz <matthew.schwartz@linux.dev> Link: https://patch.msgid.link/20260625152054.450125-8-matthew.auld@intel.com (cherry picked from commit 4c7b9c6ece32440e5a435a92076d049450cd2d2e) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
5 daysdrm/xe: fix NPD in bo_meminfo()Matthew Auld
When a buffer object is purged, its ttm.resource is set to NULL via the TTM pipeline gutting flow. However, the BO remains in the client's object list until userspace explicitly closes the GEM handle. If memory stats are queried during this time, accessing bo->ttm.resource->mem_type will result in a NULL pointer dereference. Fix this by safely skipping purged BOs in bo_meminfo, as they no longer consume any memory. User is getting NPD on device resume, and possible theory is that in bo_move(), if we need to evict something to SYSTEM to save the CCS state, but the BO is marked as dontneed, this won't trigger a move but will nuke the pages, leaving us with a NULL bo resource. And the meminfo() doesn't look ready to handle a NULL resource. v2 (Sashiko): - There could potentially be other cases where we might end up with a NULL resource, so make this a general NULL check for now. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8419 Fixes: ad9843aac91a ("drm/xe/madvise: Implement purgeable buffer object support") Assisted-by: Copilot:gemini-3.1-pro-preview Reported-by: Matthew Schwartz <matthew.schwartz@linux.dev> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Matthew Schwartz <matthew.schwartz@linux.dev> Link: https://patch.msgid.link/20260625152054.450125-6-matthew.auld@intel.com (cherry picked from commit c9a8e7daa0afe3161111e27fd92176e608c7f186) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-07 06:42:59 +0000