kernel/linux.git/drivers/gpu/drm/drm_drv.c, branch v7.1

drm/gem: Make the GEM LRU lock part of drm_device

2026-05-18T13:16:47+00:00

Recently, a few races have been discovered in the GEM LRU logic, all of them caused by the fact the LRU lock is accessed through gem->lru->lock, and that very same lock also protects changes to gem->lru, leading to situations where gem->lru needs to first be accessed without the lock held, to then get the lru to access the lock through and finally take the lock and do the expected operation. Currently, the only driver making use of this API (MSM) declares a device-wide lock, and the user we're about to add (panthor) will do the same. There's no evidence that we will ever have a driver that wants different pools of LRUs protected by different locks under the same drm_device. So we're better off moving this lock to drm_device and always locking it through obj->dev->gem_lru_mutex, or directly through dev->gem_lru_mutex. If anyone ever needs more fine-grained locking, this can be revisited to pass some drm_gem_lru_pool object representing the pool of LRUs under a specific lock, but for now, the per-device lock seems to be enough. Fixes: e7c2af13f811 ("drm/gem: Add LRU/shrinker helper") Reported-by: Chia-I Wu Closes: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/86 Reviewed-by: Rob Clark Reviewed-by: Liviu Dudau Reviewed-by: Steven Price Reviewed-by: Chia-I Wu Link: https://patch.msgid.link/20260518-panthor-shrinker-fixes-v4-1-1920234470d5@collabora.com Signed-off-by: Boris Brezillon

Merge tag 'drm-misc-next-2026-03-26' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next

2026-03-27T02:45:54+00:00

drm-misc-next for v7.1: UAPI Changes: amdxdna: - support per-BO memory-usage queries docs: - Improve UAPI documentation panthor: - extend timestamp query with flags Core Changes: edid: - provide enum drm_output_color_format; mass-convert drivers gem-dma: - use drm_dev_dma_dev() for DMA mappings - set VM_DONTDUMP on mmap mipi-dbi: - drop simple-display; mass-convert drivers prime: - use drm_dev_dma_dev() for DMA mappings ttm: - improve handling of gfp_retry_mayfail Driver Changes: amdgpu: - use atomic_create_state for private_obj amdxdna: - refactor GEM implementation - fixes bridge: - provide clear-and-put helper for reliable cleanup - analogix_dp: Use DP helpers for link training - lontium-lt8713sx: Fix 64-bit division and Kconfig - samsung-dsim: Use clear-and-put imagination: - improve power-off sequence - support context-reset notification from firmware komeda: - support Arm China Linlon D6 plus DT bindings mediatek: - use drm_dev_dma_dev() for DMA mappings panel: - support Himax HX83121A plus DT bindings - support JuTouch JT070TM041 plus DT bindings - support Samsung S6E8FC0 plus DT bindings - himax-hx83102c: support Samsung S6E8FC0 plus DT bindings; support backlight - ili9806e: support Rocktech RK050HR345-CT106A plus DT bindings - simple: support Tianma TM050RDH03 plus DT bindings panthor: - support various sources for timestamp queries - fixes omapdrm: - use atomic_create_state for private_obj rcar-du: - fix suspend/resume wrt VSP interface - fix leak of device_link - clean up sun4i: - use drm_dev_dma_dev() for DMA mappings tegra: - use atomic_create_state for private_obj xe: - send 'none' recovery method for XE_WEDGED_MODE_UPON_ANY_HANG_NO_RESET Signed-off-by: Dave Airlie From: Thomas Zimmermann Link: https://patch.msgid.link/20260326151812.GA76082@linux.fritz.box

drm: Update log for 'none' recovery method

2026-03-24T05:00:38+00:00

Update log for 'none' recovery method for wedged event where driver wants to hint "no recovery" without resetting the device from driver context. Signed-off-by: Raag Jadav Reviewed-by: Rodrigo Vivi Reviewed-by: Christian König Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260305130720.3685754-3-raag.jadav@intel.com

drm/ras: Introduce the DRM RAS infrastructure over generic netlink

2026-03-06T00:38:55+00:00

Introduces the DRM RAS infrastructure over generic netlink. The new interface allows drivers to expose RAS nodes and their associated error counters to userspace in a structured and extensible way. Each drm_ras node can register its own set of error counters, which are then discoverable and queryable through netlink operations. This lays the groundwork for reporting and managing hardware error states in a unified manner across different DRM drivers. Currently it only supports error-counter nodes. But it can be extended later. The registration is also not tied to any drm node, so it can be used by accel devices as well. It uses the new and mandatory YAML description format stored in Documentation/netlink/specs/. This forces a single generic netlink family namespace for the entire drm: "drm-ras". But multiple-endpoints are supported within the single family. Any modification to this API needs to be applied to Documentation/netlink/specs/drm_ras.yaml before regenerating the code: $ tools/net/ynl/pyynl/ynl_gen_c.py --spec \ Documentation/netlink/specs/drm_ras.yaml --mode uapi --header \ -o include/uapi/drm/drm_ras.h $ tools/net/ynl/pyynl/ynl_gen_c.py --spec \ Documentation/netlink/specs/drm_ras.yaml --mode kernel \ --header -o drivers/gpu/drm/drm_ras_nl.h $ tools/net/ynl/pyynl/ynl_gen_c.py --spec \ Documentation/netlink/specs/drm_ras.yaml \ --mode kernel --source -o drivers/gpu/drm/drm_ras_nl.c Cc: Zack McKevitt Cc: Lijo Lazar Cc: Hawking Zhang Cc: Jakub Kicinski Cc: David S. Miller Cc: Paolo Abeni Cc: Eric Dumazet Cc: netdev@vger.kernel.org Co-developed-by: Aravind Iddamsetty Signed-off-by: Aravind Iddamsetty Signed-off-by: Riana Tauro Reviewed-by: Zack McKevitt Acked-by: Jakub Kicinski Acked-by: Maarten Lankhorst Link: https://patch.msgid.link/20260304074412.464435-8-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi

drm/client: Support emergency restore via sysrq for all clients

2025-11-25T07:43:47+00:00

Move the sysrq functionality from DRM fbdev helpers to the DRM device and in-kernel clients, so that it becomes available on all clients. DRM fbdev helpers support emergency restoration of the console output via a special key combination. Press SysRq+v to replace the current compositor with the kernel's output on the framebuffer console. This allows users to see the log messages during system emergencies. By moving the functionality from fbdev helpers to the DRM device, any in-kernel client can serve as emergency output. This can be used to bring up drm_log, for example. Each DRM device registers itself to the list of possible sysrq handlers. On receiving SysRq+v, the DRM core goes over all registered devices and restores an in-kernel DRM client for each of them. See Documentation/admin-guide/sysrq.rst on how to invoke SysRq. Switch VTs to bring back the user-space compositor. v2: - declare placeholders as 'static inline' (kernel test robot) - fix grammar in commit description Signed-off-by: Thomas Zimmermann Reviewed-by: Jocelyn Falempe Link: https://patch.msgid.link/20251110154616.539328-3-tzimmermann@suse.de

Merge drm/drm-next into drm-intel-next

2025-09-10T12:01:42+00:00

Catching up with some display dependencies. Signed-off-by: Rodrigo Vivi

drm/i915: Move struct_mutex to drm_i915_private

2025-09-09T14:34:08+00:00

Move legacy BKL struct_mutex from drm_device to drm_i915_private, which is the last remaining user. Signed-off-by: Luiz Otavio Mello Reviewed-by: Rodrigo Vivi Link: https://lore.kernel.org/r/20250908131518.36625-2-luiz.mello@estudante.ufscar.br Acked-by: Thomas Zimmermann Signed-off-by: Rodrigo Vivi

drm: Add a vendor-specific recovery method to drm device wedged uevent

2025-08-26T14:11:34+00:00

Address the need for a recovery method (firmware flash on Firmware errors) introduced in the later patches of Xe KMD. Whenever XE KMD detects a firmware error, a firmware flash is required to recover the device to normal operation. The initial proposal to use 'firmware-flash' as a recovery method was not applicable to other drivers and could cause multiple recovery methods specific to vendors to be added. To address this a more generic 'vendor-specific' method is introduced, guiding users to refer to vendor specific documentation and system logs for detailed vendor specific recovery procedure. Add a recovery method 'WEDGED=vendor-specific' for such errors. Vendors must provide additional recovery documentation if this method is used. It is the responsibility of the consumer to refer to the correct vendor specific documentation and usecase before attempting a recovery. For example: If driver is XE KMD, the consumer must refer to the documentation of 'Device Wedging' under 'Documentation/gpu/xe/'. v2: fix documentation (Raag) v3: add more details to commit message (Sima, Rodrigo, Raag) add an example script to the documentation (Raag) v4: use consistent naming (Raag) v5: fix commit message v6: add more documentation Cc: André Almeida Cc: Christian König Cc: David Airlie Cc: Simona Vetter Cc: Maxime Ripard Signed-off-by: Riana Tauro Reviewed-by: Rodrigo Vivi Acked-by: Maxime Ripard Link: https://lore.kernel.org/r/20250826063419.3022216-3-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi

drm: move drm based debugfs funcs to drm_debugfs.c

2025-07-04T13:58:22+00:00

Requirement is to create per client-id based directories to hold key debugging information and for that access to root debugfs dentry is need which is not in one place and that information cannot be stored in drm_device. Move the debugfs functionality from drm_drv.c and drm_accel.c to drm_debugfs.c This enables debugfs root node reference directly drm_debugfs.c and hence enable to create per client-id directory. v8: Create drm_accel dentry only if it's config is enabled (Jeff, Hugo) v8: Merge drm_drv and drm_accel debugfs patches (Koenig, Christian) v10: Since we moved drm_debugfs_root, hence to handle drm bridge debugfs add a new function which call drm_bridge_debugfs_params where drm_debugfs_root is accessible. Suggested-by: Christian König Signed-off-by: Sunil Khatri Link: https://lore.kernel.org/r/20250704075548.1549849-2-sunil.khatri@amd.com Reviewed-by: Christian König Signed-off-by: Christian König

drm: Create a task info option for wedge events

2025-06-17T14:32:47+00:00

When a device get wedged, it might be caused by a guilty application. For userspace, knowing which task was involved can be useful for some situations, like for implementing a policy, logs or for giving a chance for the compositor to let the user know what task was involved in the problem. This is an optional argument, when the task info is not available, the PID and TASK string won't appear in the event string. Sometimes just the PID isn't enough giving that the task might be already dead by the time userspace will try to check what was this PID's name, so to make the life easier also notify what's the task's name in the user event. Acked-by: Rodrigo Vivi Reviewed-by: Krzysztof Karas Reviewed-by: Raag Jadav Acked-by: Christian König Link: https://lore.kernel.org/r/20250617124949.2151549-4-andrealmeid@igalia.com Signed-off-by: André Almeida