aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-12drm/xe: Prepare format for GT-oriented messages in one placeMichal Wajdeczko1-4/+9
To avoid code duplication (and thus potential mistakes) and to allow easier changes (if needed) of the prefix format of the GT-oriented messages, prepare that prefix in dedicated macro. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250909165941.31730-4-michal.wajdeczko@intel.com
2025-09-12drm/xe: Drop "gt_" prefix from xe_gt_WARN() macrosMichal Wajdeczko1-2/+2
Those WARN messages will already include GT-specific "GT%u:" prefix so there is no point to include additional "gt_" prefix. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250909165941.31730-3-michal.wajdeczko@intel.com
2025-09-12drm/xe: Keep xe_gt_err() macro definitions togetherMichal Wajdeczko1-5/+5
There is no need to keep them separated. No functional changes. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250909165941.31730-2-michal.wajdeczko@intel.com
2025-09-12drm/i915: split out i915_wait_util.hJani Nikula24-150/+183
Move waiting related utilities from i915_utils.h to separate new file i915_wait_util.h. Clean up related includes. Note: Many of the various wait macro usages could likely be refactored to use poll_timeout_us(). Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/431396ac8cdb3e2f4ff053a8933290289a66ce42.1757582214.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-12drm/i915: split out i915_list_util.hJani Nikula5-15/+26
Move list related utilities from i915_utils.h to separate new file i915_list_util.h. Clean up related includes. Note: Arguably none of this should exist in i915 in the first place. At least isolate it better. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/d7526809735194137116682f37cfa126a6a87ec9.1757582214.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-12drm/i915: split out i915_timer_util.[ch]Jani Nikula7-45/+64
Move timer related utilities from i915_utils.[ch] to separate new files i915_timer_util.[ch]. Clean up related includes. Note: Arguably none of this should exist in i915 in the first place. At least isolate it better. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/0a83d9489626121dcefcd4c1a05317399b5708f3.1757582214.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-12drm/i915: split out i915_ptr_util.hJani Nikula6-63/+73
Move pointer related utilities from i915_utils.h to a separate new i915_ptr_util.h header. Clean up related includes. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/3cd06aa2483e68f19401292e9d4c28bf2977fce5.1757582214.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-09-12Merge tag 'amd-drm-next-6.18-2025-09-09' of ↵Dave Airlie105-1026/+1756
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.18-2025-09-09: amdgpu: - Add CRIU support for gem objects - SI UVD fix - SI DPM fixes - Misc code cleanups - RAS updates - GPUVM debugfs fixes - Cyan Skillfish updates - UserQ updates - OEM i2c fix - SMU 13.0.x updates - DPCD probe quirk fix - Make vbios build number available in sysfs - HDCP updates - Brightness curve fixes - eDP updates - Vblank fixes - DCN 3.5 PG fix - PBN calcution fix amdkfd: - Add CRIU support for gem objects - Flexible array fix - P2P topology fix - APU memlimit fixes - Misc code cleanups UAPI: - Add CRIU support for gem objects Proposed userspace: https://github.com/checkpoint-restore/criu/pull/2613 radeon: - Use dev_warn_once() in CS parsers Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250909161928.942785-1-alexander.deucher@amd.com
2025-09-12Merge tag 'drm-misc-next-2025-09-11' of ↵Dave Airlie30-434/+2074
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.18: UAPI Changes: - Provide 'boot_display' attribute on boot-up devices amdxdma: - Add ioctl DRM_IOCTL_AMDXDNA_GET_ARRAY Cross-subsystem Changes: bindings: - Add Mayqueen vendor prefix mayqueen- pci: - vgaarb: Use screen_info helpers Core Changes: ttm: - Add interface to populate buffers Driver Changes: amdgpu: - Pre-populate exported buffers ast: - Clean up detection of DRAM config bochs: - Clean up bridge: - adv7511: Write full Audio infoframe - ite6263: Support vendor-specific infoframes - simple: Add support for Realtek RTD2171 DP-to-HDMI plus DT bindings - Clean up gma500: - Clean up nouveau: - Pre-populate exported buffers panel: - edp: Add support for additonal mt8189 Chromebook panels - lvds: Add DT bindings for EDT ETML0700Z8DHA - Clean up pixpaper: - Add support for Mayqueen Pixpaper plus DT bindings rcar-du: - Use RUNTIME_PM_OPS - Add support for DSI commands vkms: - Support variants of ARGB8888, ARGB16161616, RGB565, RGB888 and P01x - Spport YUV with 16-bit components xe: - Pre-populate exported buffers Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250911091737.GA39831@linux.fritz.box
2025-09-12Merge tag 'drm-intel-next-2025-09-05' of ↵Dave Airlie123-1336/+2005
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next Cross-subsystem Changes: - iopoll: Generalize read_poll_timeout() into poll_timeout_us() (Ville) Non-display related: - PREEMPT_RT fix (Sebastian) - Replace DRM_DEBUG_SELFTEST with DRM_KUNIT_TEST (Ruben, Imre) - Some changes oeveral like in RPS, SoC, debugfs targeting display separation (Jani) Display related: - General refactor in favor of intel_display (Suraj) - Prune modes for YUV420 (Suraj) - Reject HBR3 in any eDP Panel (Ankit) - Change AUX DPCD probe address (Imre) - Display Wa fix, additions, and updates (Ankit, Vinod, Nemesa, Suraj, Jouni)) - DP: Fix 2.7 Gbps link training on g4x (Ville) - DP: Adjust the idle pattern handling (Ville) - DP: Shuffle the link training code a bit (Ville) - Don't set/read the DSI C clock divider on GLK (Ville) - Precompute plane SURF address/etc (Ville) - Enable_psr kernel parameter changes (Jouni) - PHY LFPS sending configuration fixes (Jouni) - Fix dma_fence_wait_timeout() return value handling (Aakash) - DP: Fix disabling training pattern (Imre) - Small code clean-ups (Gustavo, Colin, Jani, Juha-Pekka) - Change vblank log from err to debug (Suraj) - More display clean-up towards intel_display split (Jani) - Use the recomended min_hblank values (Arun) - Block hpd during suspend (Dibin) - DSI: Fix overflow issue in pclk parsing (Jouni) - PSR: Do not trigger Frame Change events from frontbuffer flush (Jouni) - VBT cleanups and new fields (Jani, Suraj) - Type-C enabled/disconnected dp-alt sink (Imre) - Optimize panel power-on wait time (Dibin) - Wildcat Lake enabling (Imre, Chaitanya) - DP HDR updates (Chaitanya) - Fix divide by 0 error in i9xx_set_backlight (Suraj) - Fixes for PSR (Jouni) - Remove the encoder check in hdcp enable (Suraj) - Control HDMI output bpc (Lee) - Fix possible overflow on tc power (Mika) - Convert code towards poll_timeout_* (Jani) - Use REG_BIT on FW_BLC_SELF_* macros (Luca) - ALPM LFPS and silence period calculation (Jouni) - Remove power state verification before HW readout (Imre) - Fix HPD mtp_tc_hpd_enable_detection (Ville) - DRAM detection (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/aLtc-gk3jhwcWxZh@intel.com
2025-09-12Merge tag 'drm-xe-fixes-2025-09-11' of ↵Dave Airlie13-29/+115
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Don't touch survivability_mode on fini (Michal) - Fixes around eviction and suspend (Thomas) - Extend Wa_13011645652 to PTL-H, WCL (Julia) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/aMLq7QlaEPHGKXKX@intel.com
2025-09-12Merge tag 'drm-misc-fixes-2025-09-11' of ↵Dave Airlie6-45/+25
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A maintainer update, an out-of-bound check for panthor and a revert for nouveau to fix a race. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://lore.kernel.org/r/20250911-glistening-uakari-of-serendipity-06ceb1@houat
2025-09-12Merge tag 'mediatek-drm-fixes-20250910' of ↵Dave Airlie1-14/+9
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Mediatek DRM Fixes - 20250910 1. fix potential OF node use-after-free Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://lore.kernel.org/r/20250910231813.3526-1-chunkuang.hu@kernel.org
2025-09-12Merge tag 'amd-drm-fixes-6.17-2025-09-10' of ↵Dave Airlie17-256/+202
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.17-2025-09-10: amdgpu: - PSP 11.x fix - DPCD quirk handing fix - DCN 3.5 PG fix - Audio suspend fix - OEM i2c clean up fix - Module unload memory leak fix - DC delay fix - ISP firmware fix - VCN fixes amdkfd: - P2P topology fix - APU mem limit calculation fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250910162855.2507853-1-alexander.deucher@amd.com
2025-09-11drm/i915/guc: Include the GuC registers in the error stateDaniele Ceraolo Spurio4-0/+112
If GuC hangs, the GuC logs might not contain enough information to understand exactly why the hang occurred. In this case, we need to look at the GuC HW state to try to understand where the GuC is stuck. It is therefore useful to include the GuC HW state in the error capture. The list of registers that are part of the GuC HW state can change based on platform, but it is the same for all platforms from TGL to MTL so we only need to support one version for i915. v2: revised list v3: remove confusing comment, use sizeof(u32) instead of 4 (John) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://lore.kernel.org/r/20250909223621.3782625-2-daniele.ceraolospurio@intel.com
2025-09-11drm/xe/guc: Set RCS/CCS yield policyDaniele Ceraolo Spurio6-5/+97
All recent platforms (including all the ones officially supported by the Xe driver) do not allow concurrent execution of RCS and CCS workloads from different address spaces, with the HW blocking the context switch when it detects such a scenario. The DUAL_QUEUE flag helps with this, by causing the GuC to not submit a context it knows will not be able to execute. This, however, causes a new problem: if RCS and CCS queues have pending workloads from different address spaces, the GuC needs to choose from which of the 2 queues to pick the next workload to execute. By default, the GuC prioritizes RCS submissions over CCS ones, which can lead to CCS workloads being significantly (or completely) starved of execution time. The driver can tune this by setting a dedicated scheduling policy KLV; this KLV allows the driver to specify a quantum (in ms) and a ratio (percentage value between 0 and 100), and the GuC will prioritize the CCS for that percentage of each quantum. Given that we want to guarantee enough RCS throughput to avoid missing frames, we set the yield policy to 20% of each 80ms interval. v2: updated quantum and ratio, improved comment, use xe_guc_submit_disable in gt_sanitize Fixes: d9a1ae0d17bd ("drm/xe/guc: Enable WA_DUAL_QUEUE for newer platforms") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Tested-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://lore.kernel.org/r/20250905235632.3333247-2-daniele.ceraolospurio@intel.com
2025-09-11drm/xe/pf: Drop rounddown_pow_of_two fair LMEM limitationMichal Wajdeczko1-1/+0
This effectively reverts commit 4c3fe5eae46b ("drm/xe/pf: Limit fair VF LMEM provisioning") since we don't need it any more after non-contig VRAM allocations were fixed. This allows larger LMEM auto-provisioning for VFs, so instead: [ ] GT0: PF: LMEM available(14096M) fair(1 x 8192M) [ ] GT0: PF: VF1 provisioned with 8589934592 (8.00 GiB) LMEM or [ ] GT0: PF: LMEM available(14096M) fair(2 x 4096M) [ ] GT0: PF: VF1..VF2 provisioned with 4294967296 (4.00 GiB) LMEM we may get: [ ] GT0: PF: LMEM available(14096M) fair(1 x 14096M) [ ] GT0: PF: VF1 provisioned with 14780727296 (13.8 GiB) LMEM and [ ] GT0: PF: LMEM available(14096M) fair(2 x 7048M) [ ] GT0: PF: VF1..VF2 provisioned with 7390363648 (6.88 GiB) LMEM Fixes: 1e32ffbc9dc8 ("drm/xe/sriov: support non-contig VRAM provisioning") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20250910222439.32869-1-michal.wajdeczko@intel.com
2025-09-11drm/xe: Fix driver reference in FLR commentVarun Gupta1-1/+1
Rectify the reference of i915 to Xe in a comment. v2: Cosmetic changes. (Karthik) v3: Rephrased the commit message. (Karthik) Signed-off-by: Varun Gupta <varun.gupta@intel.com> Reviewed-by: Karthik Poosa <karthik.poosa@intel.com> Link: https://lore.kernel.org/r/20250911111712.811524-1-varun.gupta@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-11drm/xe/guc: Add SLPC power profile interfaceVinay Belgaumkar5-0/+102
GuC has an interface to set a power profile for the SLPC algorithm. Base mode is default and ensures a balanced performance, power_saving mode has conservative up/down thresholds and is suitable for use with apps that typically need to be power efficient. This will result in lower GT frequencies, thus consuming lower power. Selected power profile will be displayed in this format: $ cat power_profile [base] power_saving $ echo power_saving > power_profile $ cat power_profile base [power_saving] v2: Address review comments (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250903232120.390190-1-vinay.belgaumkar@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-11rust: drm: Introduce the Tyr driver for Arm Mali GPUsDaniel Almeida10-0/+653
Add a Rust driver for ARM Mali CSF-based GPUs. It is a port of Panthor and therefore exposes Panthor's uAPI and name to userspace, and the product of a joint effort between Collabora, Arm and Google engineers. The aim is to incrementally develop Tyr with the abstractions that are currently available until it is consider to be in parity with Panthor feature-wise. The development of Tyr itself started in January, after a few failed attempts of converting Panthor piecewise through a mix of Rust and C code. There is a downstream branch that's much further ahead in terms of capabilities than this initial patch. The downstream code is capable of booting the MCU, doing sync VM_BINDS through the work-in-progress GPUVM abstraction and also doing (trivial) submits through Asahi's drm_scheduler and dma_fence abstractions. So basically, most of what one would expect a modern GPU driver to do, except for power management and some other very important adjacent pieces. It is not at the point where submits can correctly deal with dependencies, or at the point where it can rotate access to the GPU hardware fairly through a software scheduler, but that is simply a matter of writing more code. This first patch, however, only implements a subset of the current features available downstream, as the rest is not implementable without pulling in even more abstractions. In particular, a lot of things depend on properly mapping memory on a given VA range, which itself depends on the GPUVM abstraction that is currently work-in-progress. For this reason, we still cannot boot the MCU and thus, cannot do much for the moment. This constitutes a change in the overall strategy that we have been using to develop Tyr so far. By submitting small parts of the driver upstream iteratively, we aim to: a) evolve together with Nova and rvkms, hopefully reducing regressions due to upstream changes (that may break us because we were not there, in the first place) b) prove any work-in-progress abstractions by having them run on a real driver and hardware and, c) provide a reason to work on and review said abstractions by providing a user, which would be tyr itself. Despite its limited feature-set, we offer IGT tests. It is only tested on the rk3588, so any other SoC is probably not going to work at all for now. The skeleton is basically taken from Nova and also rust_platform_driver.rs. Lastly, the name "Tyr" is inspired by Norse mythology, reflecting ARM's tradition of naming their GPUs after Nordic mythological figures and places. Co-developed-by: Beata Michalska <beata.michalska@arm.com> Signed-off-by: Beata Michalska <beata.michalska@arm.com> Co-developed-by: Carsten Haitzler <carsten.haitzler@foss.arm.com> Signed-off-by: Carsten Haitzler <carsten.haitzler@foss.arm.com> Co-developed-by: Rob Herring <robh@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://www.collabora.com/news-and-blog/news-and-events/introducing-tyr-a-new-rust-drm-driver.html Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Boris Brezillon <boris.brezillon@collabora.com> [aliceryhl: minor Kconfig update on apply] [aliceryhl: s/drm::device::/drm::/] Link: https://lore.kernel.org/r/20250910-tyr-v3-1-dba3bc2ae623@collabora.com Co-developed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2025-09-11drm/i915/backlight: Honor VESA eDP backlight luminance control capabilityAaron Ma1-1/+1
The VESA AUX backlight fails to be enable luminance based backlight mainpulation becaused luminance_set is false by default. Fix it by using luminance support control capabitliy. Fixes: e13af5166a359 ("drm/i915/backlight: Use drm helper to initialize edp backlight") Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250823121647.275834-1-aaron.ma@canonical.com
2025-09-11drm/xe: Fix uninitialized return valuesThomas Hellström2-2/+2
clang warned about two uninitialized variables used as return values in the exhaustive eviction series. Fix those. Fixes: 1f1541720f65 ("drm/xe: Rework instances of variants of xe_bo_create_locked()") Fixes: 7bcb6e38c14d ("drm/xe/display: Convert __xe_pin_fb_vma()") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://lore.kernel.org/r/20250910151128.49693-1-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe/tile: Release kobject for the failure pathShuicheng Lin1-5/+7
Call kobject_put() for the failure path to release the kobject v2: remove extra newline. (Matt) Fixes: e3d0839aa501 ("drm/xe/tile: Abort driver load for sysfs creation failure") Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://lore.kernel.org/r/20250819153950.2973344-2-shuicheng.lin@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-11xe: populate buffers before exporting them.Dave Airlie1-0/+12
Before exporting a buffer, make sure it has been populated with pages at least once. While discussing cgroups we noticed a problem where you could export a BO to a dma-buf without having it ever being backed or accounted for. This meant in low memory situations or eventually with cgroups, a lower privledged process might cause the compositor to try and allocate a lot of memory on it's behalf and this could fail. At least make sure the exporter has managed to allocate the RAM at least once before exporting the object. This only applies currently to TTM_PL_SYSTEM objects, because GTT objects get populated on first validate, and VRAM doesn't use TT. Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250904021643.2050497-4-airlied@gmail.com
2025-09-11nouveau: populate buffers before exporting them.Dave Airlie1-0/+12
Before exporting a buffer, make sure it has been populated with pages at least once. While discussing cgroups we noticed a problem where you could export a BO to a dma-buf without having it ever being backed or accounted for. This meant in low memory situations or eventually with cgroups, a lower privledged process might cause the compositor to try and allocate a lot of memory on it's behalf and this could fail. At least make sure the exporter has managed to allocate the RAM at least once before exporting the object. This only applies currently to TTM_PL_SYSTEM objects, because GTT objects get populated on first validate, and VRAM doesn't use TT. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250904021643.2050497-3-airlied@gmail.com
2025-09-11amdgpu: populate buffers before exporting them.Dave Airlie1-0/+12
Before exporting a buffer, make sure it has been populated with pages at least once. While discussing cgroups we noticed a problem where you could export a BO to a dma-buf without having it ever being backed or accounted for. This meant in low memory situations or eventually with cgroups, a lower privledged process might cause the compositor to try and allocate a lot of memory on it's behalf and this could fail. At least make sure the exporter has managed to allocate the RAM at least once before exporting the object. This only applies currently to TTM_PL_SYSTEM objects, because GTT objects get populated on first validate, and VRAM doesn't use TT. Reviewed-by: Christian Koenig <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250904021643.2050497-2-airlied@gmail.com
2025-09-11ttm/bo: add an API to populate a bo before exporting.Dave Airlie1-0/+15
While discussing cgroups we noticed a problem where you could export a BO to a dma-buf without having it ever being backed or accounted for. This meant in low memory situations or eventually with cgroups, a lower privledged process might cause the compositor to try and allocate a lot of memory on it's behalf and this could fail. At least make sure the exporter has managed to allocate the RAM at least once before exporting the object. This only applies currently to TTM_PL_SYSTEM objects, because GTT objects get populated on first validate, and VRAM doesn't use TT. Reviewed-by: Christian Koenig <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Simona Vetter <simona.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250904021643.2050497-1-airlied@gmail.com
2025-09-10drm/msm/registers: Sync GPU registers from mesaRob Clark6-475/+508
In particular, to pull in a SP_READ_SEL_LOCATION bitfield size fix to fix a7xx GPU snapshot. Sync from mesa commit 15ee3873aa4d ("freedreno/registers: Update GMU register xml"). Cc: Karmjit Mahil <karmjit.mahil@igalia.com> 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/673558/
2025-09-10drm/msm/registers: Generate _HI/LO builders for reg64Rob Clark1-0/+7
The upstream mesa copy of the GPU regs has shifted more things to reg64 instead of seperate 32b HI/LO reg32's. This works better with the "new- style" c++ builders that mesa has been migrating to for a6xx+ (to better handle register shuffling between gens), but it leaves the C builders with missing _HI/LO builders. So handle the special case of reg64, automatically generating the missing _HI/LO builders. 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/673559/
2025-09-10drm/msm/registers: Make TPL1_BICUBIC_WEIGHTS_TABLE an arrayRob Clark3-21/+17
Synced from mesa commit 77c42c1a5752 ("freedreno/registers: Make TPL1_BICUBIC_WEIGHTS_TABLE an array"). 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/673552/
2025-09-10drm/msm/registers: Sync gen_header.py from mesaRob Clark1-50/+107
Sync from mesa commit 04e2140d8be7 ("freedreno/registers: remove python 3.9 dependency for compiling msm"). Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673556/
2025-09-10drm/msm/registers: Remove license/etc from generated headersRob Clark1-36/+1
Since these generated files are no longer checked in, either in mesa or in the linux kernel, simplify things by dropping the verbose generated comment. These were semi-nerf'd on the kernel side, in the name of build reproducibility, by commit ba64c6737f86 ("drivers: gpu: drm: msm: registers: improve reproducibility"), but in a way that was semi- kernel specific. We can just reduce the divergence between kernel and mesa by just dropping all of this. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/673551/
2025-09-10DRM: Add a new 'boot_display' attributeMario Limonciello (AMD)1-0/+41
On systems with multiple GPUs there can be uncertainty which GPU is the primary one used to drive the display at bootup. In some desktop environments this can lead to increased power consumption because secondary GPUs may be used for rendering and never go to a low power state. In order to disambiguate this add a new sysfs attribute 'boot_display' that uses the output of video_is_primary_device() to populate whether the PCI device was used for driving the display. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/issues/23 Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250811162606.587759-5-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2025-09-10drm/mediatek: clean up driver data initialisationJohan Hovold1-8/+4
The platform and drm devices are only used to look up the drm device and its driver data respectively when initialising the driver data during bind(). Drop the reference counts as soon as they have been used to make the code more readable. Note that the crtc count is never incremented on lookup failures. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250829090345.21075-3-johan@kernel.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-09-10drm/mediatek: fix potential OF node use-after-freeJohan Hovold1-6/+5
The for_each_child_of_node() helper drops the reference it takes to each node as it iterates over children and an explicit of_node_put() is only needed when exiting the loop early. Drop the recently introduced bogus additional reference count decrement at each iteration that could potentially lead to a use-after-free. Fixes: 1f403699c40f ("drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv") Cc: Ma Ke <make24@iscas.ac.cn> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250829090345.21075-2-johan@kernel.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-09-10Merge drm/drm-next into drm-intel-nextRodrigo Vivi1193-24834/+46077
Catching up with some display dependencies. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-10Merge drm-misc-next-2025-08-21 into drm-rust-nextDanilo Krummrich113-1470/+3972
We need the DRM Rust changes that went into drm-misc before the existence of the drm-rust tree in here as well. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10drm/xe: Convert pinned suspend eviction for exhaustive evictionThomas Hellström1-81/+103
Pinned suspend eviction and preparation for eviction validates system memory for eviction buffers. Do that under a validation exclusive lock to avoid interfering with other processes validating system graphics memory. v2: - Avoid gotos from within xe_validation_guard(). - Adapt to signature change of xe_validation_guard(). Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-14-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Rework instances of variants of xe_bo_create_locked()Thomas Hellström5-87/+70
A common pattern is to create a locked bo, pin it without mapping and then unlock it. Add a function to do that, which internally uses xe_validation_guard(). With that we can remove xe_bo_create_locked_range() and add exhaustive eviction to stolen, pf_provision_vf_lmem and psmi_alloc_object. v4: - New patch after reorganization. v5: - Replace DRM_XE_GEM_CPU_CACHING_WB with 0. (CI) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-13-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Convert xe_bo_create_pin_map() for exhaustive evictionThomas Hellström17-130/+231
Introduce an xe_bo_create_pin_map_novm() function that does not take the drm_exec paramenter to simplify the conversion of many callsites. For the rest, ensure that the same drm_exec context that was used for locking the vm is passed down to validation. Use xe_validation_guard() where appropriate. v2: - Avoid gotos from within xe_validation_guard(). (Matt Brost) - Break out the change to pf_provision_vf_lmem8 to a separate patch. - Adapt to signature change of xe_validation_guard(). Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-12-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Convert xe_bo_create_pin_map_at() for exhaustive evictionThomas Hellström5-53/+83
Most users of xe_bo_create_pin_map_at() and xe_bo_create_pin_map_at_aligned() are not using the vm parameter, and that simplifies conversion. Introduce an xe_bo_create_pin_map_at_novm() function and make the _aligned() version static. Use xe_validation_guard() for conversion. v2: - Adapt to signature change of xe_validation_guard(). (Matt Brost) - Fix up documentation. v4: - Postpone the change to i915_gem_stolen_insert_node_in_range() to a later patch. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-11-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Rename ___xe_bo_create_locked()Thomas Hellström3-28/+27
Don't start external function names with underscores. Rename to xe_bo_init_locked(). Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-10-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Convert xe_dma_buf.c for exhaustive evictionThomas Hellström1-20/+41
Convert dma-buf migration to XE_PL_TT and dma-buf import to support exhaustive eviction, using xe_validation_guard(). It seems unlikely that the import would result in an -ENOMEM, but convert import anyway for completeness. The dma-buf map_attachment() functionality unfortunately doesn't support passing a drm_exec, which means that foreign devices validating a dma-buf that we exported will not, unless they are xeKMD devices, participate in the exhaustive eviction scheme. v2: - Avoid gotos from within xe_validation_guard(). (Matt Brost) - Adapt to signature change of xe_validation_guard(). (Matt Brost) - Remove an unneeded (void)ret. (Matt Brost) - Fix up an error path. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-9-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe/display: Convert __xe_pin_fb_vma()Thomas Hellström1-12/+18
Convert __xe_pin_fb_vma() for exhaustive eviction using xe_validation_guard(). v2: - Avoid gotos from within xe_validation_guard(). (Matt Brost) - Adapt to signature change of xe_validation_guard(). (Matt Brost) - Use interruptible waiting, since xe_bo_migrate() already does that. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-8-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Convert the CPU fault handler for exhaustive evictionThomas Hellström7-51/+225
The CPU fault handler may populate bos and migrate, and in doing so might interfere with other tasks validating. Rework the CPU fault handler completely into a fastpath and a slowpath. The fastpath trylocks only the validation lock in read-mode. If that fails, there's a fallback to the slowpath, where we do a full validation transaction. This mandates open-coding of bo locking, bo idling and bo populating, but we still call into TTM for fault finalizing. v2: - Rework the CPU fault handler to actually take part in the exhaustive eviction scheme (Matthew Brost). v3: - Don't return anything but VM_FAULT_RETRY if we've dropped the mmap_lock. Not even if a signal is pending. - Rebase on gpu_madvise() and split out fault migration. - Wait for idle after migration. - Check whether the resource manager uses tts to determine whether to map the tt or iomem. - Add a number of asserts. - Allow passing a ttm_operation_ctx to xe_bo_migrate() so that it's possible to try non-blocking migration. - Don't fall through to TTM on migration / population error Instead remove the gfp_retry_mayfail in mode 2 where we must succeed. (Matthew Brost) v5: - Don't allow faulting in the imported bo case (Matthew Brost) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthews Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-7-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Convert existing drm_exec transactions for exhaustive evictionThomas Hellström4-106/+75
Convert existing drm_exec transactions, like GT pagefault validation, non-LR exec() IOCTL and the rebind worker to support exhaustive eviction using the xe_validation_guard(). v2: - Adapt to signature change in xe_validation_guard() (Matt Brost) - Avoid gotos from within xe_validation_guard() (Matt Brost) - Check error return from xe_validation_guard() v3: - Rebase on gpu_madvise() Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v1 Link: https://lore.kernel.org/r/20250908101246.65025-6-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Convert SVM validation for exhaustive evictionThomas Hellström1-48/+55
Convert SVM validation to support exhaustive eviction, using xe_validation_guard(). v2: - Wrap also xe_vm_range_rebind (Matt Brost) - Adapt to argument changes of xe_validation_guard(). v5: - Rebase on SVM stats. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-5-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Convert xe_bo_create_user() for exhaustive evictionThomas Hellström9-61/+115
Use the xe_validation_guard() to convert xe_bo_create_user() for exhaustive eviction. v2: - Adapt to argument changes of xe_validation_guard() Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v1 Link: https://lore.kernel.org/r/20250908101246.65025-4-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Introduce an xe_validation wrapper around drm_execThomas Hellström2-0/+351
Introduce a validation wrapper xe_validation_guard() as a helper intended to be used around drm_exec transactions what perform validations. Once TTM can handle exhaustive eviction we could remove this wrapper or make it mostly a NO-OP unless other functionality is added to it. Currently the wrapper takes a read lock upon entry and if the transaction hits an OOM, all locks are released and the transaction is retried with a write-lock. If all other validations participate in this scheme, the transaction with the write lock will be the only transaction validating and should have access to all available non-pinned memory. There is currently a problem in that TTM converts -EDEADLOCKS to -ENOMEM, and with ww_mutex slowpath error injections, we can hit -ENOMEMs without having actually ran out of memory. We abuse ww_mutex internals to detect such situations until TTM is fixes to not convert the error code. In the meantime, injecting ww_mutex slowpath -EDEADLOCKs is a good way to test the implementation in the absence of real OOMs. Just introduce the wrapper in this commit. It will be hooked up to the driver in following commits. v2: - Mark class_xe_validation conditional so that the loop is skipped on initialization error. - Argument sanitation (Matt Brost) - Fix conditional execution of xe_validation_ctx_fini() (Matt Brost) - Add a no_block mode for upcoming use in the CPU fault handler. v4: - Update kerneldoc. (Xe CI). Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20250908101246.65025-3-thomas.hellstrom@linux.intel.com
2025-09-10drm/xe: Pass down drm_exec context to validationThomas Hellström21-110/+407
We want all validation (potential backing store allocation) to be part of a drm_exec transaction. Therefore add a drm_exec pointer argument to xe_bo_validate() and ___xe_bo_create_locked(). Upcoming patches will deal with making all (or nearly all) calls to these functions part of a drm_exec transaction. In the meantime, define special values of the drm_exec pointer: XE_VALIDATION_UNIMPLEMENTED: Implementation of the drm_exec transaction has not been done yet. XE_VALIDATION_UNSUPPORTED: Some Middle-layers (dma-buf) doesn't allow the drm_exec context to be passed down to map_attachment where validation takes place. XE_VALIDATION_OPT_OUT: May be used only for kunit tests where exhaustive eviction isn't crucial and the ROI of converting those is very small. For XE_VALIDATION_UNIMPLEMENTED and XE_VALIDATION_OPT_OUT there is also a lockdep check that a drm_exec transaction can indeed start at the location where the macro is expanded. This is to encourage developers to take this into consideration early in the code development process. v2: - Fix xe_vm_set_validation_exec() imbalance. Add an assert that hopefully catches future instances of this (Matt Brost) v3: - Extend to psmi_alloc_object Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v3 Link: https://lore.kernel.org/r/20250908101246.65025-2-thomas.hellstrom@linux.intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-01-03 23:19:41 +0000