aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-08-22drm/xe/configfs: Dump custom settings when bindingLucas De Marchi3-0/+44
Device configuration using configfs could be prepared long time prior the driver load. Currently all the xe configfs entries are for things that are important to have in the log if a non-default value is being used. Add a info-level message about that with the individual entries that are different than the default. Based on previous patch by Michal Wajdeczko. Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-12-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/configfs: Minor fixes to documentationLucas De Marchi1-4/+5
Add a few missing punctuation and line breaks and make the syntax for code snippets common to all of them. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-11-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/configfs: Improve documentation stepsLucas De Marchi1-4/+16
The steps are roughly: 1. Load the module without binding to the device 2. Configure the desired device 3. Bind the device Move the binding part to the "Create devices" since it's not exclusive to the survivability_mode attribute and better document the steps. Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-10-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/configfs: Use tree-like output in documentationLucas De Marchi1-2/+10
When documenting the directories, use an output similar to the `tree` command and add VFs and missing attributes. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-9-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/configfs: Use guard() for dev->lockLucas De Marchi1-8/+5
Instead of the manual lock()/unlock() pattern, use guard() which will make things easier for handling errors or early returns. Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-8-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/configfs: Allow to enable PSMILucas De Marchi2-5/+63
Now that additional WAs are in place and it's possible to allocate buffers through debugfs, add the configfs attribute to turn PSMI on. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-7-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/configfs: Simplify kernel docLucas De Marchi1-12/+3
From the caller perspective reading the documentation, there's no need to be so specific about everything the function is doing/checking. Just document the functionality a caller cares about. Reviewed-by: Riana Tauro <riana.tauro@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-6-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/psmi: Add Wa_16023683509Vinay Belgaumkar3-0/+6
This WA ensures GuC will restore the media MCFG registers at C6 exit. Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-5-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/psmi: Add Wa_14020001231Badal Nilawar3-0/+9
Enable Wa 14020001231 to block psmi interrupts during C6 entry exit flow. It's only enabled if PSMI is enabled in runtime. Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-4-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/rtp: Add match for psmiLucas De Marchi2-0/+10
Add match to be used on WAs for only enabling workarounds if psmi is intended to be used. Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-3-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/psmi: Add debugfs interface for PSMILucas De Marchi6-0/+337
Requirement for PSMI capture is to have a physically contiguous buffer. All the needed configuration is done by the userspace tool directly to the GPU via mmio access. This interface only support allocating from VRAM regions. For integrated devices, the PSMI buffer is in SYSTEM memory and should be allocated by userspace using hugetlbfs. Here we add the ability to allocate a region of physically contiguous memory by writing to debugfs file (listed below). For multi-tile devices, the capture tool requires ability to allocate a capture buffer per tile (VRAM region) and so user can specify a region_mask. The tool then can mmap the buffers via direct mmap of the PCIBAR via sysfs. To support the capture tool, 3 new debugfs entries are added: psmi_capture_addr - physical address per VRAM region's capture buffer psmi_capture_region_mask - select which region(s) to allocate a buffer psmi_capture_size - size of current capture buffer Writing psmi_capture_size will allocate new buffer of requested size per region after freeing any current buffers. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Original-author: Brian Welty <brian.welty@intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> # v2 Link: https://lore.kernel.org/r/20250821-psmi-v5-2-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/xe/psmi: Add GuC flag to enable PSMILucas De Marchi3-1/+9
PSMI allows to capture data from the GPU useful for early validation. From the kernel side there isn't much to be done, just a few things: 1) Toggle the feature support in GuC 2) Enable some additional WAs 3) Allocate buffers Here is the first step, with the next ones to follow. For now everything is disabled through a check in configfs that is currently hardcoded to disabled. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://lore.kernel.org/r/20250821-psmi-v5-1-34ab7550d3d8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-22drm/bridge: simple-bridge: Add support for radxa ra620Andy Yan1-0/+5
The RA620 is an active DP to HDMI converter chip, basically no software is involved to drive it. Add it to simple bridge to make it can be find by the drm bridge chain. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250822063959.692098-7-andyshrk@163.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-22drm: re-allow no-op changes on non-primary planes in async flipsXaver Hugl1-11/+12
Commit fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to async flip") unintentionally disallowed no-op changes on non-primary planes that the driver doesn't allow async flips on. This broke async flips for compositors that disable the cursor plane in every async atomic commit. To fix that, change drm_atomic_set_property to again only run atomic_async_check if the plane would actually be changed by the atomic commit. Fixes: fd40a63c63a1 ("drm/atomic: Let drivers decide which planes to async flip") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4263 Signed-off-by: Xaver Hugl <xaver.hugl@kde.org> Reviewed-by: André Almeida <andrealmeid@igalia.com> Link: https://lore.kernel.org/r/20250822152849.87843-1-xaver.hugl@kde.org [andrealmeid: fix checkpatch warning] Signed-off-by: André Almeida <andrealmeid@igalia.com>
2025-08-22drm/xe/pcode: Initialize data0 for pcode read routineStuart Summers3-10/+10
There are two registers filled in when reading data from pcode besides the mailbox itself. Currently, we allow a NULL value for the second of these two (data1) and assume the first is defined. However, many of the routines that are calling this function assume that pcode will ignore the value being passed in and so leave that first value (data0) defined but uninitialized. To be safe, make sure this value is always initialized to something (0 generally) in the event pcode behavior changes and starts using this value. v2: Fix sob/author Signed-off-by: Stuart Summers <stuart.summers@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://lore.kernel.org/r/20250819201054.393220-1-stuart.summers@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-22drm/amdgpu: Pin buffers while vmap'ing exported dma-buf objectsThomas Zimmermann1-2/+32
Current dma-buf vmap semantics require that the mapped buffer remains in place until the corresponding vunmap has completed. For GEM-SHMEM, this used to be guaranteed by a pin operation while creating an S/G table in import. GEM-SHMEN can now import dma-buf objects without creating the S/G table, so the pin is missing. Leads to page-fault errors, such as the one shown below. [ 102.101726] BUG: unable to handle page fault for address: ffffc90127000000 [...] [ 102.157102] RIP: 0010:udl_compress_hline16+0x219/0x940 [udl] [...] [ 102.243250] Call Trace: [ 102.245695] <TASK> [ 102.2477V95] ? validate_chain+0x24e/0x5e0 [ 102.251805] ? __lock_acquire+0x568/0xae0 [ 102.255807] udl_render_hline+0x165/0x341 [udl] [ 102.260338] ? __pfx_udl_render_hline+0x10/0x10 [udl] [ 102.265379] ? local_clock_noinstr+0xb/0x100 [ 102.269642] ? __lock_release.isra.0+0x16c/0x2e0 [ 102.274246] ? mark_held_locks+0x40/0x70 [ 102.278177] udl_primary_plane_helper_atomic_update+0x43e/0x680 [udl] [ 102.284606] ? __pfx_udl_primary_plane_helper_atomic_update+0x10/0x10 [udl] [ 102.291551] ? lockdep_hardirqs_on_prepare.part.0+0x92/0x170 [ 102.297208] ? lockdep_hardirqs_on+0x88/0x130 [ 102.301554] ? _raw_spin_unlock_irq+0x24/0x50 [ 102.305901] ? wait_for_completion_timeout+0x2bb/0x3a0 [ 102.311028] ? drm_atomic_helper_calc_timestamping_constants+0x141/0x200 [ 102.317714] ? drm_atomic_helper_commit_planes+0x3b6/0x1030 [ 102.323279] drm_atomic_helper_commit_planes+0x3b6/0x1030 [ 102.328664] drm_atomic_helper_commit_tail+0x41/0xb0 [ 102.333622] commit_tail+0x204/0x330 [...] [ 102.529946] ---[ end trace 0000000000000000 ]--- [ 102.651980] RIP: 0010:udl_compress_hline16+0x219/0x940 [udl] In this stack strace, udl (based on GEM-SHMEM) imported and vmap'ed a dma-buf from amdgpu. Amdgpu relocated the buffer, thereby invalidating the mapping. Provide a custom dma-buf vmap method in amdgpu that pins the object before mapping it's buffer's pages into kernel address space. Do the opposite in vunmap. Note that dma-buf vmap differs from GEM vmap in how it handles relocation. While dma-buf vmap keeps the buffer in place, GEM vmap requires the caller to keep the buffer in place. Hence, this fix is in amdgpu's dma-buf code instead of its GEM code. A discussion of various approaches to solving the problem is available at [1]. v3: - try (GTT | VRAM); drop CPU domain (Christian) v2: - only use mapable domains (Christian) - try pinning to domains in preferred order Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 660cd44659a0 ("drm/shmem-helper: Import dmabuf without mapping its sg_table") Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Closes: https://lore.kernel.org/dri-devel/ba1bdfb8-dbf7-4372-bdcb-df7e0511c702@suse.de/ Cc: Shixiong Ou <oushixiong@kylinos.cn> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Link: https://lore.kernel.org/dri-devel/9792c6c3-a2b8-4b2b-b5ba-fba19b153e21@suse.de/ # [1] Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20250821064031.39090-1-tzimmermann@suse.de
2025-08-22gpu: nova-core: falcon: align DMA transfers to 256 bytesAlexandre Courbot2-17/+23
Falcon DMA transfers are done in 256 bytes increments, and the method responsible for initiating the transfer checked that the required length was indeed a multiple of 256. While correct, this also requires callers to specifically account for this limitation of DMA transfers, and we had for instance the fwsec code performing a seemingly arbitrary (and potentially overflowing) upwards alignment of the DMEM load size to match this requirement. Let's move that alignment into the loading code itself instead: since it is working in terms of number of transfers, we can turn this upwards alignment into a non-overflowing operation, and check that the requested transfer remains into the limits of the DMA object. This also allows us to remove a DMA-specific constant in the fwsec code. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://lore.kernel.org/r/20250821-falcondma_256b-v2-1-83e8647a24b5@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-21drm/xe: Fix vm_bind_ioctl double free bugChristoph Manszewski1-1/+2
If the argument check during an array bind fails, the bind_ops are freed twice as seen below. Fix this by setting bind_ops to NULL after freeing. ================================================================== BUG: KASAN: double-free in xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] Free of addr ffff88813bb9b800 by task xe_vm/14198 CPU: 5 UID: 0 PID: 14198 Comm: xe_vm Not tainted 6.16.0-xe-eudebug-cmanszew+ #520 PREEMPT(full) Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2411.A02.2110081023 10/08/2021 Call Trace: <TASK> dump_stack_lvl+0x82/0xd0 print_report+0xcb/0x610 ? __virt_addr_valid+0x19a/0x300 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] kasan_report_invalid_free+0xc8/0xf0 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] check_slab_allocation+0x102/0x130 kfree+0x10d/0x440 ? should_fail_ex+0x57/0x2f0 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] xe_vm_bind_ioctl+0x1b2/0x21f0 [xe] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] ? __lock_acquire+0xab9/0x27f0 ? lock_acquire+0x165/0x300 ? drm_dev_enter+0x53/0xe0 [drm] ? find_held_lock+0x2b/0x80 ? drm_dev_exit+0x30/0x50 [drm] ? drm_ioctl_kernel+0x128/0x1c0 [drm] drm_ioctl_kernel+0x128/0x1c0 [drm] ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] ? find_held_lock+0x2b/0x80 ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm] ? should_fail_ex+0x57/0x2f0 ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] drm_ioctl+0x352/0x620 [drm] ? __pfx_drm_ioctl+0x10/0x10 [drm] ? __pfx_rpm_resume+0x10/0x10 ? do_raw_spin_lock+0x11a/0x1b0 ? find_held_lock+0x2b/0x80 ? __pm_runtime_resume+0x61/0xc0 ? rcu_is_watching+0x20/0x50 ? trace_irq_enable.constprop.0+0xac/0xe0 xe_drm_ioctl+0x91/0xc0 [xe] __x64_sys_ioctl+0xb2/0x100 ? rcu_is_watching+0x20/0x50 do_syscall_64+0x68/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fa9acb24ded Fixes: b43e864af0d4 ("drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Christoph Manszewski <christoph.manszewski@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/20250813101231.196632-2-christoph.manszewski@intel.com (cherry picked from commit a01b704527c28a2fd43a17a85f8996b75ec8492a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-21drm/xe: Move ASID allocation and user PT BO tracking into xe_vm_createPiotr Piórkowski1-19/+15
Currently, ASID assignment for user VMs and page-table BO accounting for client memory tracking are performed in xe_vm_create_ioctl. To consolidate VM object initialization, move this logic to xe_vm_create. v2: - removed unnecessary duplicate BO tracking code - using the local variable xef to verify whether the VM is being created by userspace Fixes: 658a1c8e0a66 ("drm/xe: Assign ioctl xe file handler to vm in xe_vm_create") Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250811104358.2064150-3-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 30e0c3f43a414616e0b6ca76cf7f7b2cd387e1d4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo: Added fixes tag]
2025-08-21drm/xe/kunit: Extend platform generator with PTLMichal Wajdeczko1-0/+1
Our list of typical platforms used to generate test device objects does not contain any PANTHERLAKE. Add one. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250818192032.633-1-michal.wajdeczko@intel.com
2025-08-21drm/panel: jdi-lpm102a188a: Fix error code in jdi_panel_prepare()Dan Carpenter1-1/+3
If the mipi_dsi_dual() macro fails, the error code is stored in dsi_ctx.accum_err. Propagate that error back to the caller instead of returning success as the current code does. Fixes: a6adf47d30cc ("drm/panel: jdi-lpm102a188a: Fix bug and clean up driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/aKcRfq8xBrFmhqmO@stanley.mountain
2025-08-21drm: of: fix documentation referenceRaphael Gallais-Pou1-2/+5
Documentation/devicetree/bindings/graph.txt content has move directly to the dt-schema repo in commit 4b52be0ce6ad ("dt-bindings: Remove plain text OF graph binding"). Point to the YAML of the official repo instead of the old file. Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250328114148.260322-1-rgallaispou@gmail.com Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
2025-08-21gpu: nova-core: Update ARef imports from sync::arefShankari Anand2-2/+2
Update call sites in nova-core to import `ARef` from `sync::aref` instead of `types`. This aligns with the ongoing effort to move `ARef` and `AlwaysRefCounted` to sync. [acourbot@nvidia.com: use standard prefix for nova-core.] Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://lore.kernel.org/r/20250820112846.9665-1-shankari.ak0208@gmail.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-08-21drm/dp: drm_edp_backlight_set_level: do not always send 3-byte commandsVal Packett1-1/+3
At least some panels using the LSB register are not happy with the unconditional increase of the command buffer to 3 bytes. With the BOE NE14QDM in my Dell Latitude 7455, the recent patches for luminance based brightness have introduced a regression: the brightness range stopped being contiguous and became nonsensical (it probably was interpreting the last 2 bytes of the buffer and not the first 2). Change from using a fixed sizeof() to a length variable that's only set to 3 when luminance is used. Let's leave the default as 2 even for the single-byte version, since that's how it worked before. Fixes: f2db78e37fe7 ("drm/dp: Modify drm_edp_backlight_set_level") Signed-off-by: Val Packett <val@packett.cool> Tested-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250706204446.8918-1-val@packett.cool Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-08-21drm/i915/psr: Check pause counter before continuing to PSR activationJouni Högander1-0/+3
Currently intel_psr_work is re-activating PSR even when pause_counter > 0 which is incorrect. Fix this by checking pause_counter before re-activating PSR. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14822 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250815084534.1637030-4-jouni.hogander@intel.com
2025-08-21drm/i915/psr: Do not activate disabled PSR on irq_aux_errorJouni Högander1-1/+3
Currently intel_psr_work is continuing to activation of PSR which was just disabled when irq_aux_error == true. Fix this by skipping everything else than intel_psr_handle_irq in intel_psr_work when irq_aux_error == true. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250815084534.1637030-3-jouni.hogander@intel.com
2025-08-21drm/i915/psr: drm_WARN_ON when activating disabled PSRJouni Högander1-0/+2
Add drm_WARN_ON for scenario where PSR is activated while it is disabled. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250815084534.1637030-2-jouni.hogander@intel.com
2025-08-21Merge tag 'amd-drm-fixes-6.17-2025-08-20' of ↵Dave Airlie15-125/+112
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.17-2025-08-20: amdgpu: - Replay fixes - SMU14 fix - Null check DC fixes - DCE6 DC fixes - Misc DC fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250820194636.101975-1-alexander.deucher@amd.com
2025-08-21drm/i915/backlight: Fix divide by 0 error in i9xx_set_backlightSuraj Kandpal1-1/+2
pwm_level_max maybe 0 we do throw a warning but move ahead with execution which may later cause a /0 error. --v2 -return if the warn_on gets hit [Jani] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250819160438.145734-1-suraj.kandpal@intel.com
2025-08-20drm/xe: Use for_each_gt to define gt_countGustavo Sousa1-2/+7
We are currently bumping gt_count as we define GTs for each tile. While that works with our current code, there are reasons to improve that: * That section of the code is dedicated to define each tile's set of GTs and their respective info. The gt_count can be seen as a device level property. While it is fair to bump it as we define each GT, we can also focus on the GT themselves and count after we are done with the definitions. * More *importantly*, gt_count should reflect the number of GTs that we would get when looping over them with for_each_gt(). Bumping gt_count the way we are currently doing makes that value not really connected to for_each_gt(). This could bite us in the future if in the loop gets extra checks that are not accounted for in each existing "gt_count++". As such, let's use for_each_gt() and extract the calculation of gt_count into a separate block, just after we define the set of GTs for each tile. Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250818-gt_count-improvements-v4-2-ee12870c6f57@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-08-20drm/xe: Probe for tile count during device info initializationGustavo Sousa3-33/+48
The function mmio_multi_tile_setup() does not look like the proper location for probing for the number of existing tiles in the hardware. It should not be that function's responsibility and such information should instead be already available when it gets called. The fact that we need to adjust gt_count is a symptom of that. Move probing of available tile count to a dedicated function named xe_info_probe_tile_count() and call it from xe_info_init(), which seems like a more appropriate place for that. With that move, we no longer need to (and shouldn't) adjust gt_count as a part of xe_info_probe_tile_count(), as that field will be initialized later in xe_info_init(). v4: - Only probe for tile count if the default tile_count != 1 (just like was done in mmio_multi_tile_setup()). (CI) v3: - Unchanged. v2: - Use KUnit static stub so that we do not try to query hardware when running KUnit tests. (CI) - Tweak last paragraph of commit message to make it clearer. (Jonathan) Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250818-gt_count-improvements-v4-1-ee12870c6f57@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-08-20drm/xe/tuning: Apply "Disable NULL query for Anyhit Shader" to Xe2Nitin Gote1-1/+1
Extend the "Disable NULL query for Anyhit Shader" tuning to Xe2 (graphics version 2000+) platforms, in addition to Xe3. This sets the DIS_NULL_QUERY bit in RT_CTRL to disable null query for Anyhit shaders on both Xe2 and Xe3. This is a change in behavior that can regress a userspace not prepared for it. However it's not feasible to change dynamically the option per client or per exec queue via an opt-in flag. Mesa is already prepared for that and it got propagated to their stable versions. Even if it was possible, at this point adding a flag would mean mesa would also need to propagate such a flag to their stable versions, otherwise the previous fix would not be used. Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Acked-by: Tapani Pälli <tapani.palli@intel.com> Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35044 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35044 Link: https://lore.kernel.org/r/20250819061151.1272622-1-nitin.r.gote@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-08-20drm/bridge: anx7625: register content protect propertyHsin-Yi Wang1-0/+1
Set the `support_hdcp` bit to enable the connector to register content protection during initialization. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Fei Shao <fshao@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250812082135.3351172-3-fshao@chromium.org
2025-08-20drm_bridge: register content protect propertyHsin-Yi Wang1-0/+9
Some bridges can update HDCP status based on userspace requests if they support HDCP. The HDCP property is created after connector initialization and before registration, just like other connector properties. Add the content protection property to the connector if a bridge supports HDCP. Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Fei Shao <fshao@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250812082135.3351172-2-fshao@chromium.org
2025-08-20Merge drm/drm-fixes into drm-misc-fixesMaxime Ripard23-67/+209
Update drm-misc-fixes to -rc2. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-08-20drm/panel: panel-samsung-s6e88a0-ams427ap24: Fix includesThomas Zimmermann1-0/+2
Include <linux/property.h> to declare device_property_read_bool() and <linux/mod_devicetable.h> to declare struct of_device_id. Avoids the dependency on the backlight header to include both. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250812082509.227879-1-tzimmermann@suse.de
2025-08-20drm/virtio: clean up minor codestyle issuesAthul Raj Kollareth5-15/+16
Fix codestyle warnings and errors generated by CHECKPATCH in virtio source files. Signed-off-by: Athul Raj Kollareth <krathul3152@gmail.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://lore.kernel.org/r/20250813062109.5326-1-krathul3152@gmail.com
2025-08-20Merge drm/drm-next into drm-misc-nextMaxime Ripard23-67/+209
Bring v6.17-rc2 in to unstuck for-linux-next. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-08-20drm/i915/psr: Underrun on idle PSR wa only when pkgc latency > delayed vblankJouni Högander3-6/+17
Underrun on idle PSR workaround (Wa_16025596647) is supposed to be applied only when pkg c latency > delayed vblank. Currently we are applying it always when other criterias are met. Fix this by adding new boolean flag which is supposed to be set when calculating watermark levels and pkgc latency > delayed vblank is detected. currently this scenario is blocked but might be added later. Due to this add also TODO comment into skl_max_wm_level_for_vblank. Bspec: 74151 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://lore.kernel.org/r/20250519075223.443266-1-jouni.hogander@intel.com
2025-08-19drm/gpusvm: Make drm_gpusvm_for_each_* macros publicHimal Prasad Ghimiray1-97/+25
The drm_gpusvm_for_each_notifier, drm_gpusvm_for_each_notifier_safe and drm_gpusvm_for_each_range_safe macros are useful for locating notifiers and ranges within a user-specified range. By making these macros public, we enable broader access and utility for developers who need to leverage them in their implementations. v2 (Matthew Brost) - drop inline __drm_gpusvm_range_find - /s/notifier_iter_first/drm_gpusvm_notifier_find Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@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/20250819162058.2777306-5-himal.prasad.ghimiray@intel.com
2025-08-19drm/gpuvm: Introduce drm_gpuvm_madvise_ops_createHimal Prasad Ghimiray1-37/+188
This ops is used to iterate over GPUVA's in the user-provided range and split the existing sparse VMA's if the start or end of the input range lies within it. The operations can create up to 2 REMAPS and 2 MAPs. The primary use case is for drivers to assign attributes to GPU VAs in the specified range without performing unmaps or merging mappings, supporting fine-grained control over sparse va's. Cc: Danilo Krummrich <dakr@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Himal Prasad Ghimiray<himal.prasad.ghimiray@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250819162058.2777306-4-himal.prasad.ghimiray@intel.com
2025-08-19drm/gpuvm: Kill drm_gpuva_init()Boris Brezillon1-1/+7
drm_gpuva_init() only has one internal user, and given we are about to add new optional fields, it only add maintenance burden for no real benefit, so let's kill the thing now. Cc: Danilo Krummrich <dakr@kernel.org> Cc: Rob Clark <robin.clark@oss.qualcomm.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250819162058.2777306-3-himal.prasad.ghimiray@intel.com
2025-08-19drm/gpuvm: Pass map arguments through a structBoris Brezillon6-65/+88
We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](), so, before we do that, let's pass arguments through a struct instead of changing each call site every time a new optional argument is added. Cc: Danilo Krummrich <dakr@kernel.org> Cc: Brendan King <Brendan.King@imgtec.com> Cc: Matt Coster <matt.coster@imgtec.com> Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Caterina Shablia <caterina.shablia@collabora.com> Cc: Rob Clark <robin.clark@oss.qualcomm.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <dri-devel@lists.freedesktop.org> 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: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> # imagination/pvr_vm.c Acked-by: Matt Coster <matt.coster@imgtec.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250819162058.2777306-2-himal.prasad.ghimiray@intel.com
2025-08-19drm/xe: Assign ioctl xe file handler to vm in xe_vm_createPiotr Piórkowski4-8/+9
In several code paths, such as xe_pt_create(), the vm->xef field is used to determine whether a VM originates from userspace or the kernel. Previously, this handler was only assigned in xe_vm_create_ioctl(), after the VM was created by xe_vm_create(). However, xe_vm_create() triggers page table creation, and that function assumes vm->xef should be already set. This could lead to incorrect origin detection. To fix this problem and ensure consistency in the initialization of the VM object, let's move the assignment of this handler to xe_vm_create. v2: - take reference to the xe file object only when xef is not NULL - release the reference to the xe file object on the error path (Matthew) Fixes: 7f387e6012b6 ("drm/xe: add XE_BO_FLAG_PINNED_LATE_RESTORE") Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250811104358.2064150-2-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> (cherry picked from commit 9337166fa1d80f7bb7c7d3a8f901f21c348c0f2a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-08-19drm/i915/dram: move fsb_freq and mem_freq to dram infoJani Nikula5-30/+26
Store fsb_freq and mem_freq in dram info the same way we do for other memory info on later platforms for a slightly more unified approach. This allows us to remove fsb_freq, mem_freq and is_ddr3 members from struct drm_i915_private and struct xe_device. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/a38c4b105ba9098fa0b128cb86cd4eb63bcc27e8.1755511595.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19drm/i915/dram: bypass fsb/mem freq detection on dg2 and no displayJani Nikula1-1/+4
Non-display now calls the intel_fsb_freq() and intel_mem_freq() functions, so we don't have to have the frequencies initialized for dg2 or non-display cases. This is in preparation for unifying the pre-gen9 handling in dram info. DG2 remains a special case as described in commit 5eb6bf0b44e7 ("drm/i915/dg2: Don't read DRAM info"). v2: Rebase Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/7bfed06d431354f3918ea73d43a2ec8ed9426a76.1755511595.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19drm/i915/rps: use intel_fsb_freq() and intel_mem_freq()Jani Nikula1-3/+8
The rps init only happens once, so it's not important to use the cached versions, and we can drop the dependency on them. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/6f3b703f7cb5605bf139cbe27697c1d4ffe7e719.1755511595.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19drm/i915/dram: add intel_mem_freq()Jani Nikula2-5/+13
Add a more generic intel_mem_freq() function instead of platform specific ones. Expose it for future use outside of intel_dram.c. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/602103b290a92ba26d581eeb595ba5e707eb5bc4.1755511595.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19drm/i915/dram: add intel_fsb_freq() and use itJani Nikula4-7/+13
Add a more generic intel_fsb_freq() function instead of platform specific ones. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/c5b77311c5f64b7163c86a042b7d023c07a685e2.1755511595.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-08-19drm/i915/switcheroo: check for NULL before dereferencingJani Nikula1-2/+2
Both i915_switcheroo_set_state() and i915_switcheroo_can_switch() check for i915 == NULL. Commit d2e184f8e16a ("drm/i915/switcheroo: pass display to HAS_DISPLAY()") started dereferencing it before the NULL check. Fix it. Fixes: d2e184f8e16a ("drm/i915/switcheroo: pass display to HAS_DISPLAY()") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202508160035.hmzuKiww-lkp@intel.com/ Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20250818071605.2541523-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-01-04 03:23:57 +0000