summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-04-01drm/i915/mchbar: Use intel_mchbar_read() instead of intel_de_read()Ville Syrjälä
We are doing a few accesses to MCHBAR registers with intel_de_read(). Use the dedicated intel_mchbar_read() instead. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-6-ville.syrjala@linux.intel.com
2026-04-01drm/i915/mchbar: WARN when accessing non-MCHBAR registers via ↵Ville Syrjälä
intel_mchbar_read*() The intel_mchbar_read*() functions should only be used for accessing MCHBAR registers. Warn if someone tries to use them for other registers. I suppose we could even have a dedicated type for MCHBAR registers. But that is true for many other special register types as well, and so far we haven't bothered adding any special types apart from i915_mcr_reg_t. v2: Print the register offset (Jani) Mention i915_mcr_reg_t (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-5-ville.syrjala@linux.intel.com
2026-04-01drm/i915/mchbar: Define the end of the MCHBAR mirrorVille Syrjälä
Add defines for the end of the MCHBAR mirror. I'm planning to use this for some range sanity checks. BSpec: 51771 Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-4-ville.syrjala@linux.intel.com
2026-04-01drm/i915/mchbar: Provide intel_mchbar_read*() abstractionVille Syrjälä
MCHBAR registers are a bit special in that: - we access them through the mirror - the mirror is read only on HSW+ - the mirror requires the actual MCHBAR to be enabled in device 0:0.0 - the mirror is gone on MTL+ So I'd prefer to treat MCHBAR registers as a bit special in the code as well, and do all accesses to them via dedicated functions. Prodive such functions in the form of intel_mchbar_read*(). v2: Put the function arguments on one line No intel_uncore_read64() on xe, use intel_uncore_read64_2x32() Name the new function intel_mchbar_read64_2x32() as well Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-3-ville.syrjala@linux.intel.com
2026-04-01drm/i915/qgv: Use intel_de_read() for MTL_MEM_SS_INFO* readsVille Syrjälä
The MTL_MEM_SS_INFO* are just regular display registers. Use intel_de_read() to access them. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260331154259.24600-2-ville.syrjala@linux.intel.com
2026-04-01drm/{i915, xe}: add shared header for VLV IOSF sideband units and registersJani Nikula
Move vlv_iosf_sb_reg.h to include/drm/intel/vlv_iosf_sb_regs.h. Use _regs.h suffix to align better with other register headers. Move enum vlv_iosf_sb_unit there as well, breaking the final include tie related to IOSF sideband between display and i915 core. With this, we can completely remove the xe compat vls_iosf_sb*.h headers. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/41b060b0d6453de39ca775eab10ee12b25c45b7d.1774957233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-01drm/i915: move VLV IOSF sideband to display parent interfaceJani Nikula
Remove another direct dependency from display to i915 core by moving the VLV IOSF sideband calls to the display parent interface. Xe doesn't need this, so it'll remain optional and NULL. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/15dfc67b58f5b5b381be0f9bc66d60b43bebfecf.1774957233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-01drm/i915/dram: prefer display abstractions for VLV sidebandJani Nikula
Use the display wrappers for VLV sideband in dram code. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/c971f1a1eccceeb5599ccea5909443afe24b20d3.1774957233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-01drm/i915: pass struct intel_display * to VLV sideband wrappersJani Nikula
In display code, the display pointer will be all around more convenient. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/a355fe0642f7e6566a22e85bda455092e49e3b68.1774957233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-01drm/{i915, xe}: convert VLV sideband display wrappers into real functionsJani Nikula
Convert the VLV sideband static inline wrappers into real functions. This will help the follow-up work of moving the VLV sideband to the display parent interface. The downside is that we'll have to build vlv_sideband.c as part of xe build, to avoid a plethora of stubs. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/57740dc3a820cb5fc1cfcd28e4be58b2cb48020d.1774957233.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-04-01drm/tilcdc: replace use of system_wq with system_percpu_wqMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") system_wq should be the per-cpu workqueue, yet in this name nothing makes that clear, so replace system_wq with system_percpu_wq. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251104165731.315074-1-marco.crivellari@suse.com
2026-03-31drm/msm: Remove abuse of drm_exec internalsThomas Hellström
The code was reading drm_exec internal state to determine whether the drm_exec structure had been initialized or not, and therefore needed cleaning up, relying on undocumented behaviour. Instead add a bool to struct msm_gem_submit to indicate whether drm_exec cleaning up is needed. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Rob Clark <rob.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/715502/ Message-ID: <20260331092023.81616-3-thomas.hellstrom@linux.intel.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/xe/pat: Print PAT_ATS during register dumpZbigniew Kempczyński
For Xe2 and beyond we miss printing PAT_ATS register. Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260331134330.2535519-2-zbigniew.kempczynski@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-04-01Merge tag 'drm-rust-next-2026-03-30' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/rust/kernel into drm-next DRM Rust changes for v7.1-rc1 - DMA: - Rework the DMA coherent API: introduce Coherent<T> as a generalized container for arbitrary types, replacing the slice-only CoherentAllocation<T>. Add CoherentBox for memory initialization before exposing a buffer to hardware (converting to Coherent when ready), and CoherentHandle for allocations without kernel mapping. - Add Coherent::init() / init_with_attrs() for one-shot initialization via pin-init, and from-slice constructors for both Coherent and CoherentBox - Add uaccess write_dma() for copying from DMA buffers to userspace and BinaryWriter support for Coherent<T> - DRM: - Add GPU buddy allocator abstraction - Add DRM shmem GEM helper abstraction - Allow drm::Device to dispatch work and delayed work items to driver private data - Add impl_aref_for_gem_obj!() macro to reduce GEM refcount boilerplate, and introduce DriverObject::Args for constructor context - Add dma_resv_lock helper and raw_dma_resv() accessor on GEM objects - Clean up imports across the DRM module - I/O: - Merged via a signed tag from the driver-core tree: register!() macro and I/O infrastructure improvements (IoCapable refactor, RelaxedMmio wrapper, IoLoc trait, generic accessors, write_reg / LocatedRegister) - Nova (Core): - Fix and harden the GSP command queue: correct write pointer advancing, empty slot handling, and ring buffer indexing; add mutex locking and make Cmdq a pinned type; distinguish wait vs no-wait commands - Add support for large RPCs via continuation records, splitting oversized commands across multiple queue slots - Simplify GSP sequencer and message handling code: remove unused trait and Display impls, derive Debug and Zeroable where applicable, warn on unconsumed message data - Refactor Falcon firmware handling: create DMA objects lazily, add PIO upload support, and use the Generic Bootloader to boot FWSEC on Turing - Convert all register definitions (PMC, PBUS, PFB, GC6, FUSE, PDISP, Falcon) to the kernel register!() macro; add bounded_enum macro to define enums usable as register fields - Migrate all DMA usage to the new Coherent, CoherentBox, and CoherentHandle APIs - Harden firmware parsing with checked arithmetic throughout FWSEC, Booter, RISC-V parsing paths - Add debugfs support for reading GSP-RM log buffers; replace module_pci_driver!() with explicit module init to support module-level debugfs setup - Fix auxiliary device registration for multi-GPU systems - Various cleanups: import style, firmware parsing refactoring, framebuffer size logging - Rust: - Add interop::list module providing a C linked list interface - Extend num::Bounded with shift operations, into_bool(), and const get() to support register bitfield manipulation - Enable the generic_arg_infer Rust feature and add EMSGSIZE error code - Tyr: - Adopt vertical import style per kernel Rust guidelines - Clarify driver/device type names and use DRM device type alias consistently across the driver - Fix GPU model/version decoding in GpuInfo - Workqueue: - Add ARef<T> support for work and delayed work Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Danilo Krummrich" <dakr@kernel.org> Link: https://patch.msgid.link/DHGH4BLT03BU.ZJH5U52WE8BY@kernel.org
2026-03-31drm/xe: Apply WA_14026999295 to engineMallesh Koujalagi
Apply WA_14026999295 to following IPs: Xe3p_XPC v2: - Move WA to "Xe3p_XPC" section at bottom of table. (Matt) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Link: https://patch.msgid.link/20260327102414.780515-2-mallesh.koujalagi@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-03-31drm/xe: Set GT rp min frequency as 1.2GHz default for BMG/CRINareshkumar Gollakoti
While previously applied only to both tiles GT0(Graphics) and Media(GT1) the BMG G21(Battle image) platform via workaround Wa_14022085890, this 1.2 GHz minimum is now the default for GT0(Graphics) tile of BMG and CRI platforms. Setting this frequency floor(1.2GHz) default is critical in multi GPU environment for supporting effective Peer-to-Peer(P2P) transactions. v2: - Fix Indentation(Thomas) - Add comment about power impact(Stuart) v3:(Thomas/Ankur/Matt Roper) - Add setting frequency to only GT0(Graphics) Tile of BMG/CRI v4:(Stuart) - Move WA check to pc_needs_min_freq_change function Signed-off-by: Nareshkumar Gollakoti <naresh.kumar.g@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patch.msgid.link/20260326063407.985568-4-naresh.kumar.g@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-03-31drm/msm/adreno: Expose a PARAM to check AQE supportAkhil P Oommen
AQE (Applicaton Qrisc Engine) is required to support VK ray-pipeline. Two conditions should be met to use this HW: 1. AQE firmware should be loaded and programmed 2. Preemption support Expose a new MSM_PARAM to allow userspace to query its support. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714685/ Message-ID: <20260327-a8xx-gpu-batch2-v2-17-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Enable Preemption on X2-85Akhil P Oommen
Add the save-restore register lists and set the necessary quirk flags in the catalog to enable the Preemption feature on Adreno X2-85 GPU. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714684/ Message-ID: <20260327-a8xx-gpu-batch2-v2-16-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a8xx: Preemption support for A840Akhil P Oommen
The programing sequence related to preemption is unchanged from A7x. But there is some code churn due to register shuffling in A8x. So, split out the common code into a header file for code sharing and add/update additional changes required to support preemption feature on A8x GPUs. Finally, enable the preemption quirk in A840's catalog to enable this feature. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714682/ Message-ID: <20260327-a8xx-gpu-batch2-v2-15-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a8xx: Implement IFPC support for A840Akhil P Oommen
Implement pwrup reglist support and add the necessary register configurations to enable IFPC support on A840 Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714679/ Message-ID: <20260327-a8xx-gpu-batch2-v2-14-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Add SKU detection support for X2-85Akhil P Oommen
Add the Speedbin table to the catalog to enable SKU detection support for X2-85 GPU found in Glymur chipset. As this chipset support the SOFT FUSE mechanism, enable the ADRENO_QUIRK_SOFTFUSE quirk too. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714677/ Message-ID: <20260327-a8xx-gpu-batch2-v2-13-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Add soft fuse detection supportAkhil P Oommen
Recent chipsets like Glymur supports a new mechanism for SKU detection. A new CX_MISC register exposes the combined (or final) speedbin value from both HW fuse register and the Soft Fuse register. Implement this new SKU detection along with a new quirk to identify the GPUs that has soft fuse support. There is a side effect of this patch on A4x and older series. The speedbin field in the MSM_PARAM_CHIPID will be 0 instead of 0xffff. This should be okay as Mesa correctly handles it. Speedbin was not even a thing when those GPUs' support were added. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714676/ Message-ID: <20260327-a8xx-gpu-batch2-v2-12-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a8xx: Add SKU table for A840Akhil P Oommen
Add the SKU table in the catalog for A840 GPU. This data helps to pick the correct bin from the OPP table based on the speed_bin fuse value. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714673/ Message-ID: <20260327-a8xx-gpu-batch2-v2-11-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Update HFI definitionsAkhil P Oommen
Update the HFI definitions to support additional GMU based power features. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714671/ Message-ID: <20260327-a8xx-gpu-batch2-v2-10-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Use packed structs for HFIAkhil P Oommen
HFI related structs define the ABI between the KMD and the GMU firmware. So, use packed structures to avoid unintended compiler inserted padding. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714669/ Message-ID: <20260327-a8xx-gpu-batch2-v2-9-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Add support for Debug HFI QAkhil P Oommen
Add the Debug HFI Queue which contains the F2H messages posted from the GMU firmware. Having this data in coredump is useful to debug firmware issues. Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714666/ Message-ID: <20260327-a8xx-gpu-batch2-v2-7-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Fix gpu init from secure worldAkhil P Oommen
A7XX_GEN2 and newer GPUs requires initialization of few configurations related to features/power from secure world. The SCM call to do this should be triggered after GDSC and clocks are enabled. So, keep this sequence to a6xx_gmu_resume instead of the probe. Also, simplify the error handling in a6xx_gmu_resume() using 'goto' labels. Fixes: 14b27d5df3ea ("drm/msm/a7xx: Initialize a750 "software fuse"") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714664/ Message-ID: <20260327-a8xx-gpu-batch2-v2-6-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/adreno: Implement gx_is_on() for A8xAkhil P Oommen
A8x has a diverged enough for a separate implementation of gx_is_on() check. Add that and move them to the adreno func table. Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714661/ Message-ID: <20260327-a8xx-gpu-batch2-v2-5-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Correct OOB usageAkhil P Oommen
During the GMU resume sequence, using another OOB other than OOB_GPU may confuse the internal state of GMU firmware. To align more strictly with the downstream sequence, move the sysprof related OOB setup after the OOB_GPU is cleared. Fixes: 62cd0fa6990b ("drm/msm/adreno: Disable IFPC when sysprof is active") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714659/ Message-ID: <20260327-a8xx-gpu-batch2-v2-4-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Switch to preemption safe AO counterAkhil P Oommen
CP_ALWAYS_ON_COUNTER is not save-restored during preemption, so it won't provide accurate data about the 'submit' when preemption is enabled. Switch to CP_ALWAYS_ON_CONTEXT which is preemption safe. Fixes: e7ae83da4a28 ("drm/msm/a6xx: Implement preemption for a7xx targets") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714657/ Message-ID: <20260327-a8xx-gpu-batch2-v2-3-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a8xx: Fix the ticks used in submit tracesAkhil P Oommen
GMU_ALWAYS_ON_COUNTER_* registers got moved in A8x, but currently, A6x register offsets are used in the submit traces instead of A8x offsets. To fix this, refactor a bit and use adreno_gpu->funcs->get_timestamp() everywhere. While we are at it, update a8xx_gmu_get_timestamp() to use the GMU AO counter. Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714655/ Message-ID: <20260327-a8xx-gpu-batch2-v2-2-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Use barriers while updating HFI Q headersAkhil P Oommen
To avoid harmful compiler optimizations and IO reordering in the HW, use barriers and READ/WRITE_ONCE helpers as necessary while accessing the HFI queue index variables. Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714653/ Message-ID: <20260327-a8xx-gpu-batch2-v2-1-2b53c38d2101@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata()Yasuaki Torimaru
msm_ioctl_gem_info_get_metadata() always returns 0 regardless of errors. When copy_to_user() fails or the user buffer is too small, the error code stored in ret is ignored because the function unconditionally returns 0. This causes userspace to believe the ioctl succeeded when it did not. Additionally, kmemdup() can return NULL on allocation failure, but the return value is not checked. This leads to a NULL pointer dereference in the subsequent copy_to_user() call. Add the missing NULL check for kmemdup() and return ret instead of 0. Note that the SET counterpart (msm_ioctl_gem_info_set_metadata) correctly returns ret. Fixes: 9902cb999e4e ("drm/msm/gem: Add metadata") Cc: stable@vger.kernel.org Signed-off-by: Yasuaki Torimaru <yasuakitorimaru@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/714478/ Message-ID: <20260325114635.383241-1-yasuakitorimaru@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Fix dumping A650+ debugbus blocksConnor Abbott
These should be appended after the existing debugbus blocks, instead of replacing them. Fixes: 1e05bba5e2b8 ("drm/msm/a6xx: Update a6xx gpu coredump") Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/714270/ Message-ID: <20260325-drm-msm-a650-debugbus-v1-1-dfbf358890a7@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/shrinker: Fix can_block() logicRob Clark
The intention here was to allow blocking if DIRECT_RECLAIM or if called from kswapd and KSWAPD_RECLAIM is set. Reported by Claude code review: https://lore.gitlab.freedesktop.org/drm-ai-reviews/review-patch9-20260309151119.290217-10-boris.brezillon@collabora.com/ on a panthor patch which had copied similar logic. Reported-by: Boris Brezillon <boris.brezillon@collabora.com> Fixes: 7860d720a84c ("drm/msm: Fix build break with recent mm tree") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Patchwork: https://patchwork.freedesktop.org/patch/714238/ Message-ID: <20260325184106.1259528-1-robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Fix HLSQ register dumpingRob Clark
Fix the bitfield offset of HLSQ_READ_SEL state-type bitfield. Otherwise we are always reading TP state when we wanted SP or HLSQ state. Reported-by: Connor Abbott <cwabbott0@gmail.com> Suggested-by: Connor Abbott <cwabbott0@gmail.com> Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714236/ Message-ID: <20260325184043.1259312-1-robin.clark@oss.qualcomm.com>
2026-03-31drm/msm: Fix VM_BIND UNMAP lockingRob Clark
Wrong argument meant that the objs involved in UNMAP ops were not always getting locked. Since _NO_SHARE objs share a common resv with the VM (which is always locked) this would only show up with non-_NO_SHARE BOs. Reported-by: Victoria Brekenfeld <victoria@system76.com> Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/94 Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/713898/ Message-ID: <20260324220519.1221471-2-robin.clark@oss.qualcomm.com>
2026-03-31drm/msm: Disallow foreign mapping of _NO_SHARERob Clark
This restriction applies to mapping of _NO_SHARE objs in the kms vm as well as importing/exporting BOs. Since the DPU has it's own VM, scanout counts as "exporting" a BO from outside of it's host VM. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/713897/ Message-ID: <20260324220519.1221471-1-robin.clark@oss.qualcomm.com>
2026-03-31drm/msm: Reject fb creation from _NO_SHARE objsRob Clark
It would be an error to map these into kms->vm. So reject this as early as possible, when creating an fb. Fixes: b58e12a66e47 ("drm/msm: Add _NO_SHARE flag") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/714264/ Message-ID: <20260325185926.1265661-1-robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a6xx: Add missing aperture_lock initRob Clark
Looks like this was somehow missed when introducing gen8 support. Fixes: 288a93200892 ("drm/msm/adreno: Introduce A8x GPU Support") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/713545/ Message-ID: <20260323161603.1165108-1-robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/vma: Avoid lock in VM_BIND fence signaling pathRob Clark
Use msm_gem_unpin_active(), similar to what is used in the GEM_SUBMIT path. This avoids needing to hold the obj lock, and the end result is the same. (As with GEM_SUBMIT, we know the fence isn't signaled yet.) Reported-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/712230/ Message-ID: <20260316184442.673558-1-robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/a8xx: Update GPU name with slice_maskRob Clark
Once we've updated the chip_id after reading the slice_mask, also update the GPU name so it matches. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/712225/ Message-ID: <20260316183436.671482-3-robin.clark@oss.qualcomm.com>
2026-03-31drm/msm/adreno: Change chip_id formatRob Clark
The "ipv4-style" %u.%u.%u.%u used to make sense when the chip_id was simply encoding gen.major.minor.patch. But this hasn't been true for at least a couple years. Switch to %08x, which is still easy enough to read for older devices, and much easier to read with the new scheme. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/712222/ Message-ID: <20260316183436.671482-2-robin.clark@oss.qualcomm.com>
2026-03-31drm/msm: always recover the gpuAnna Maniscalco
Previously, in case there was no more work to do, recover worker wouldn't trigger recovery and would instead rely on the gpu going to sleep and then resuming when more work is submitted. Recover_worker will first increment the fence of the hung ring so, if there's only one job submitted to a ring and that causes an hang, it will early out. There's no guarantee that the gpu will suspend and resume before more work is submitted and if the gpu is in a hung state it will stay in that state and probably trigger a timeout again. Just stop checking and always recover the gpu. Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Cc: stable@vger.kernel.org Patchwork: https://patchwork.freedesktop.org/patch/704066/ Message-ID: <20260210-recovery_suspend_fix-v1-1-00ed9013da04@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm: gpu: msm: forbid mem reclaim from resetSergey Senozhatsky
We sometimes get into a situtation where GPU hangcheck fails to recover GPU: [..] msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): hangcheck detected gpu lockup rb 0! msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): completed fence: 7840161 msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): submitted fence: 7840162 msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): hangcheck detected gpu lockup rb 0! msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): completed fence: 7840162 msm_dpu ae01000.display-controller: [drm:hangcheck_handler] *ERROR* (IPv4: 1): submitted fence: 7840163 [..] The problem is that msm_job worker is blocked on gpu->lock INFO: task ring0:155 blocked for more than 122 seconds. Not tainted 6.6.99-08727-gaac38b365d2c #1 task:ring0 state:D stack:0 pid:155 ppid:2 flags:0x00000008 Call trace: __switch_to+0x108/0x208 schedule+0x544/0x11f0 schedule_preempt_disabled+0x30/0x50 __mutex_lock_common+0x410/0x850 __mutex_lock_slowpath+0x28/0x40 mutex_lock+0x5c/0x90 msm_job_run+0x9c/0x140 drm_sched_main+0x514/0x938 kthread+0x114/0x138 ret_from_fork+0x10/0x20 which is owned by recover worker, which is waiting for DMA fences from a memory reclaim path, under the very same gpu->lock INFO: task ring0:155 is blocked on a mutex likely owned by task gpu-worker:154. task:gpu-worker state:D stack:0 pid:154 ppid:2 flags:0x00000008 Call trace: __switch_to+0x108/0x208 schedule+0x544/0x11f0 schedule_timeout+0x1f8/0x770 dma_fence_default_wait+0x108/0x218 dma_fence_wait_timeout+0x6c/0x1c0 dma_resv_wait_timeout+0xe4/0x118 active_purge+0x34/0x98 drm_gem_lru_scan+0x1d0/0x388 msm_gem_shrinker_scan+0x1cc/0x2e8 shrink_slab+0x228/0x478 shrink_node+0x380/0x730 try_to_free_pages+0x204/0x510 __alloc_pages_direct_reclaim+0x90/0x158 __alloc_pages_slowpath+0x1d4/0x4a0 __alloc_pages+0x9f0/0xc88 vm_area_alloc_pages+0x17c/0x260 __vmalloc_node_range+0x1c0/0x420 kvmalloc_node+0xe8/0x108 msm_gpu_crashstate_capture+0x1e4/0x280 recover_worker+0x1c0/0x638 kthread_worker_fn+0x150/0x2d8 kthread+0x114/0x138 So no one can make any further progress. Forbid recover/fault worker to enter memory reclaim (under gpu->lock) to address this deadlock scenario. Cc: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Rob Clark <rob.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/700978/ Message-ID: <20260127073341.2862078-1-senozhatsky@chromium.org> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-03-31drm/xe/uc: Track uc firmware state changesMichal Wajdeczko
Under CONFIG_DRM_XE_DEBUG_GUC print debug messages with each uc firmware state transition to better visualize the changes. [drm:xe_uc_fw_change_status [xe]] Tile0: GT0: GuC UNINITIALIZED->SELECTED [drm:xe_uc_fw_change_status [xe]] Tile0: GT0: GuC SELECTED->AVAILABLE [drm:xe_uc_fw_change_status [xe]] Tile0: GT0: GuC AVAILABLE->LOADABLE [drm:xe_uc_fw_change_status [xe]] Tile0: GT0: GuC LOADABLE->TRANSFERRED [drm:xe_uc_fw_change_status [xe]] Tile0: GT0: GuC TRANSFERRED->RUNNING Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260327202407.563-1-michal.wajdeczko@intel.com
2026-03-31drm/i915/dp: Implement the POST_LT_ADJ_REQ sequenceVille Syrjälä
Implement the POST_LT_ADJ_REQ sequence, which should be used to further fine tune the link if TPS4 is not supported. The POST_LT_ADJ_REQ sequence will be performed after the normal link training has succeeded. Only the final hop between the last LTTPR and DPRX will perform the POST_LT_ADJ_REQ adjustment. The earlier hops will use TPS4 instead since it's mandatory for LTTPRs. The sequence will terminate when the sink clears the "in progress" flag, the vswing/pre-emphasis values have changed six times, or the vswing/pre-emphasis values have remained unchanged for 200 ms. Tested-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260330202629.28616-2-ville.syrjala@linux.intel.com
2026-03-31drm/xe/vm: Convert comma to semicolonChen Ni
Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260327032923.649869-1-nichen@iscas.ac.cn
2026-03-31drm/amd/display: Use drm_display_info for AMD VSDB dataChenyu Chen
Replace the raw EDID byte-walking in parse_amd_vsdb() with a read from connector->display_info.amd_vsdb, now populated by drm_edid. Factor out panel type determination into dm_set_panel_type(), which checks VSDB panel_type, DPCD ext caps, and a luminance heuristic as fallbacks. Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260327082342.1286878-3-chen-yu.chen@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-03-31drm/edid: Parse AMD Vendor-Specific Data BlockChenyu Chen
Parse the AMD VSDB v3 from CTA extension blocks and store the result in struct drm_amd_vsdb_info, a new field of drm_display_info. This includes replay mode, panel type, and luminance ranges. Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260327082342.1286878-2-chen-yu.chen@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-21 15:05:07 +0000