linux/include/drm/drm_device.h, branch v6.17

drm: Add missing struct drm_wedge_task_info kernel doc

2025-07-10T21:07:47Z

Fix the following kernel doc warning: include/drm/drm_device.h:40: warning: Function parameter or struct member 'pid' not described in 'drm_wedge_task_info' include/drm/drm_device.h:40: warning: Function parameter or struct member 'comm' not described in 'drm_wedge_task_info' Fixes: 183bccafa176 ("drm: Create a task info option for wedge events") Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/lkml/20250618151307.4a1a5e17@canb.auug.org.au/ Reviewed-by: Raag Jadav Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://lore.kernel.org/r/20250704190724.1159416-2-andrealmeid@igalia.com Signed-off-by: André Almeida

drm: Create a task info option for wedge events

2025-06-17T14:32:47Z

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

drm/prime: Support dedicated DMA device for dma-buf imports

2025-03-12T08:03:46Z

Importing dma-bufs via PRIME requires a DMA-capable device. Devices on peripheral busses, such as USB, often cannot perform DMA by themselves. Without DMA-capable device PRIME import fails. DRM drivers for USB devices already use a separate DMA device for dma-buf imports. Make the mechanism generally available. Besides the case of USB, there are embedded DRM devices without DMA capability. DMA is performed by a separate controller. DRM drivers should set this accordingly. Add the field dma_dev to struct drm_device to refer to the device's DMA device. For USB this should be the USB controller. Use dma_dev in the PRIME import helpers, if set. v2: - acquire internal reference on dma_dev (Jani) - add DMA-controller usecase to docs (Maxime) Signed-off-by: Thomas Zimmermann Reviewed-by: Jani Nikula Reviewed-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20250307080836.42848-2-tzimmermann@suse.de

drm: Introduce device wedged event

2025-02-13T17:15:43Z

Introduce device wedged event, which notifies userspace of 'wedged' (hanged/unusable) state of the DRM device through a uevent. This is useful especially in cases where the device is no longer operating as expected and has become unrecoverable from driver context. Purpose of this implementation is to provide drivers a generic way to recover the device with the help of userspace intervention without taking any drastic measures (like resetting or re-enumerating the full bus, on which the underlying physical device is sitting) in the driver. A 'wedged' device is basically a device that is declared dead by the driver after exhausting all possible attempts to recover it from driver context. The uevent is the notification that is sent to userspace along with a hint about what could possibly be attempted to recover the device from userspace and bring it back to usable state. Different drivers may have different ideas of a 'wedged' device depending on hardware implementation of the underlying physical device, and hence the vendor agnostic nature of the event. It is up to the drivers to decide when they see the need for device recovery and how they want to recover from the available methods. Driver prerequisites -------------------- The driver, before opting for recovery, needs to make sure that the 'wedged' device doesn't harm the system as a whole by taking care of the prerequisites. Necessary actions must include disabling DMA to system memory as well as any communication channels with other devices. Further, the driver must ensure that all dma_fences are signalled and any device state that the core kernel might depend on is cleaned up. All existing mmaps should be invalidated and page faults should be redirected to a dummy page. Once the event is sent, the device must be kept in 'wedged' state until the recovery is performed. New accesses to the device (IOCTLs) should be rejected, preferably with an error code that resembles the type of failure the device has encountered. This will signify the reason for wedging, which can be reported to the application if needed. Recovery -------- Current implementation defines three recovery methods, out of which, drivers can use any one, multiple or none. Method(s) of choice will be sent in the uevent environment as ``WEDGED=[,..,]`` in order of less to more side-effects. If driver is unsure about recovery or method is unknown (like soft/hard system reboot, firmware flashing, physical device replacement or any other procedure which can't be attempted on the fly), ``WEDGED=unknown`` will be sent instead. Userspace consumers can parse this event and attempt recovery as per the following expectations. =============== ======================================== Recovery method Consumer expectations =============== ======================================== none optional telemetry collection rebind unbind + bind driver bus-reset unbind + bus reset/re-enumeration + bind unknown consumer policy =============== ======================================== The only exception to this is ``WEDGED=none``, which signifies that the device was temporarily 'wedged' at some point but was recovered from driver context using device specific methods like reset. No explicit recovery is expected from the consumer in this case, but it can still take additional steps like gathering telemetry information (devcoredump, syslog). This is useful because the first hang is usually the most critical one which can result in consequential hangs or complete wedging. Consumer prerequisites ---------------------- It is the responsibility of the consumer to make sure that the device or its resources are not in use by any process before attempting recovery. With IOCTLs erroring out, all device memory should be unmapped and file descriptors should be closed to prevent leaks or undefined behaviour. The idea here is to clear the device of all user context beforehand and set the stage for a clean recovery. Example ------- Udev rule:: SUBSYSTEM=="drm", ENV{WEDGED}=="rebind", DEVPATH=="*/drm/card[0-9]", RUN+="/path/to/rebind.sh $env{DEVPATH}" Recovery script:: #!/bin/sh DEVPATH=$(readlink -f /sys/$1/device) DEVICE=$(basename $DEVPATH) DRIVER=$(readlink -f $DEVPATH/driver) echo -n $DEVICE > $DRIVER/unbind echo -n $DEVICE > $DRIVER/bind Customization ------------- Although basic recovery is possible with a simple script, consumers can define custom policies around recovery. For example, if the driver supports multiple recovery methods, consumers can opt for the suitable one depending on scenarios like repeat offences or vendor specific failures. Consumers can also choose to have the device available for debugging or telemetry collection and base their recovery decision on the findings. This is useful especially when the driver is unsure about recovery or method is unknown. v4: s/drm_dev_wedged/drm_dev_wedged_event Use drm_info() (Jani) Kernel doc adjustment (Aravind) v5: Send recovery method with uevent (Lina) v6: Access wedge_recovery_opts[] using helper function (Jani) Use snprintf() (Jani) v7: Convert recovery helpers into regular functions (Andy, Jani) Aesthetic adjustments (Andy) Handle invalid recovery method v8: Allow sending multiple methods with uevent (Lucas, Michal) static_assert() globally (Andy) v9: Provide 'none' method for device reset (Christian) Provide recovery opts using switch cases v11: Log device reset (André) Signed-off-by: Raag Jadav Reviewed-by: André Almeida Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20250204070528.1919158-2-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi

drm/vblank: add dynamic per-crtc vblank configuration support

2024-07-26T21:40:10Z

We would like to be able to enable vblank_disable_immediate unconditionally, however there are a handful of cases where a small off delay is necessary (e.g. with PSR enabled). So, we would like to be able to adjust the vblank off delay and disable imminent values dynamically for a given CRTC. Since, it will allow drivers to apply static screen optimizations more quickly and consequently allow users to benefit more so from the power savings afforded by the aforementioned optimizations, while avoiding issues in cases where an off delay is still warranted. In particular, the PSR case requires a small off delay of 2 frames, otherwise display firmware isn't able to keep up with all of the requests made to amdgpu. So, introduce drm_crtc_vblank_on_config() which is like drm_crtc_vblank_on(), but it allows drivers to specify the vblank CRTC configuration before enabling vblanking support for a given CRTC. Signed-off-by: Hamza Mahfooz Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20240725205109.209743-1-hamza.mahfooz@amd.com

drm: Remove source code for non-KMS drivers

2023-12-06T09:08:37Z

Remove all remaining source code for non-KMS drivers. These drivers have been removed in v6.3 and won't comeback. Signed-off-by: Thomas Zimmermann Reviewed-by: David Airlie Reviewed-by: Daniel Vetter Acked-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-13-tzimmermann@suse.de

drm/debugfs: remove dev->debugfs_list and debugfs_mutex v2

2023-09-01T06:53:05Z

The mutex was completely pointless in the first place since any parallel adding of files to this list would result in random behavior since the list is filled and consumed multiple times. Completely drop that approach and just create the files directly but return -ENODEV while opening the file when the minors are not registered yet. v2: rebase on debugfs directory rework, limit access before minors are registered. Signed-off-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20230829110115.3442-5-christian.koenig@amd.com Reviewed-by: Andi Shyti

drm/debugfs: rework debugfs directory creation v5

2023-09-01T06:51:18Z

Instead of the per minor directories only create a single debugfs directory for the whole device directly when the device is initialized. For DRM devices each minor gets a symlink to the per device directory for now until we can be sure that this isn't useful any more in any way. Accel devices create only the per device directory and also drops the mid layer callback to create driver specific files. v2: cleanup accel component as well v3: fix typo when debugfs is disabled v4: call drm_debugfs_dev_fini() during release as well, some kerneldoc typos fixed v5: rebased and one more kerneldoc fix Signed-off-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20230829110115.3442-4-christian.koenig@amd.com Reviewed-by: Andi Shyti

Merge tag 'drm-misc-next-2023-01-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2023-01-16T05:33:28Z

drm-misc-next for v6.3: UAPI Changes: * fourcc: Document Open Source user waiver Cross-subsystem Changes: * firmware: fix color-format selection for system framebuffers Core Changes: * format-helper: Add conversion from XRGB8888 to various sysfb formats; Make XRGB8888 the only driver-emulated legacy format * fb-helper: Avoid blank consoles from selecting an incorrect color format * probe-helper: Enable/disable HPD on connectors plus driver updates * Use drm_dbg_ helpers in several places * docs: Document defaults for CRTC backgrounds; Document use of drm_minor Driver Changes: * arm/hdlcd: Use new debugfs helpers * gud: Use new debugfs helpers * panel: Support Visionox VTDR6130 AMOLED DSI; Support Himax HX8394; Convert many drivers to common generic DSI write-sequence helper * v3d: Do not opencode drm_gem_object_lookup() * vc4: Various HVS an CRTC fixes * vkms: Fix SEGFAULT from incorrect GEM-buffer mapping * Convert various drivers to i2c probe_new() Signed-off-by: Dave Airlie From: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/Y8ADeSzZDj+tpibF@linux-uq9g

drm: document better that drivers shouldn't use drm_minor directly

2023-01-11T23:19:14Z

The documentation for struct drm_minor already states this, but that's not always that easy to find. Also due to historical reasons we still have the minor-centric interfaces (like drm_debugfs_create_files), but since this is now getting fixed we can put a few more pointers in place as to how this should be done ideally. Note that debugfs isn't there yet for all cases (debugfs files on kms objects like crtc/connector aren't supported, neither debugfs files with full fops), so the debugfs side of this is still rather aspirational and more for new users than converting everything existing. todo.rst covers the additional work needed already. Motivated by some discussion with Rodrigo on irc about how drm/xe should lay out its sysfs interfaces. v2: Make the debugfs situation clearer in the commit message, but don't elaborate more in the actual kerneldoc to avoid distracting from the main message around sysfs (Jani) Also fix some typos. Acked-by: Rodrigo Vivi Reviewed-by: Melissa Wen Reviewed-by: Maíra Canal Acked-by: Maxime Ripard Acked-by: Jani Nikula Cc: Rodrigo Vivi Cc: Wambui Karuga Cc: Maíra Canal Cc: Maxime Ripard Cc: Melissa Wen Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20230109164604.3860862-1-daniel.vetter@ffwll.ch