kernel/linux.git/include/drm/drm_drv.h, branch v6.6.134

drm: Disable the cursor plane on atomic contexts with virtualized drivers

2024-02-01T00:19:08+00:00

commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream. Cursor planes on virtualized drivers have special meaning and require that the clients handle them in specific ways, e.g. the cursor plane should react to the mouse movement the way a mouse cursor would be expected to and the client is required to set hotspot properties on it in order for the mouse events to be routed correctly. This breaks the contract as specified by the "universal planes". Fix it by disabling the cursor planes on virtualized drivers while adding a foundation on top of which it's possible to special case mouse cursor planes for clients that want it. Disabling the cursor planes makes some kms compositors which were broken, e.g. Weston, fallback to software cursor which works fine or at least better than currently while having no effect on others, e.g. gnome-shell or kwin, which put virtualized drivers on a deny-list when running in atomic context to make them fallback to legacy kms and avoid this issue. Signed-off-by: Zack Rusin Fixes: 681e7ec73044 ("drm: Allow userspace to ask for universal plane list (v2)") Cc: # v5.4+ Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Hans de Goede Cc: Gurchetan Singh Cc: Chia-I Wu Cc: dri-devel@lists.freedesktop.org Cc: virtualization@lists.linux-foundation.org Cc: spice-devel@lists.freedesktop.org Acked-by: Pekka Paalanen Reviewed-by: Javier Martinez Canillas Acked-by: Simon Ser Signed-off-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20231023074613.41327-2-aesteve@redhat.com Signed-off-by: Greg Kroah-Hartman

drm: manager to keep track of GPUs VA mappings

2023-07-20T03:15:53+00:00

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1) Provide infrastructure to track GPU VA allocations and mappings, using an interval tree (RB-tree). 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. Acked-by: Thomas Hellström Acked-by: Matthew Brost Reviewed-by: Boris Brezillon Tested-by: Matthew Brost Tested-by: Donald Robson Suggested-by: Dave Airlie Signed-off-by: Danilo Krummrich Link: https://patchwork.freedesktop.org/patch/msgid/20230720001443.2380-2-dakr@redhat.com

drm: Enable PRIME import/export for all drivers

2023-06-26T09:08:39+00:00

Call drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle() by default if no PRIME import/export helpers have been set. Both functions are the default for almost all drivers. DRM drivers implement struct drm_driver.gem_prime_import_sg_table to import dma-buf objects from other drivers. Having the function drm_gem_prime_fd_to_handle() functions set by default allows each driver to import dma-buf objects to itself, even without support for other drivers. For drm_gem_prime_handle_to_fd() it is similar: using it by default allows each driver to export to itself, even without support for other drivers. This functionality enables userspace to share per-driver buffers across process boundaries via PRIME (e.g., wlroots requires this functionality). The patch generalizes a pattern that has previously been implemented by GEM VRAM helpers [1] to work with any driver. For example, gma500 can now run the wlroots-based sway compositor. v2: * clean up docs and TODO comments (Simon, Zack) * clean up style in drm_getcap() Signed-off-by: Thomas Zimmermann Link: https://lore.kernel.org/dri-devel/20230302143502.500661-1-contact@emersion.fr/ # 1 Reviewed-by: Simon Ser Acked-by: Alex Deucher Reviewed-by: Jeffrey Hugo Link: https://patchwork.freedesktop.org/patch/msgid/20230620080252.16368-2-tzimmermann@suse.de

drm: Remove struct drm_driver.gem_prime_mmap

2023-06-19T11:56:40+00:00

All drivers initialize this field with drm_gem_prime_mmap(). Call the function directly and remove the field. Simplifies the code and resolves a long-standing TODO item. Signed-off-by: Thomas Zimmermann Reviewed-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20230613150441.17720-3-tzimmermann@suse.de

drm: Add common fdinfo helper

2023-05-24T16:03:26+00:00

Handle a bit of the boiler-plate in a single case, and make it easier to add some core tracked stats. This also ensures consistent behavior across drivers for standardised fields. v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo v3: Rebase on drm-misc-next Reviewed-by: Daniel Vetter Signed-off-by: Rob Clark Acked-by: Dave Airlie Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20230524155956.382440-3-robdclark@gmail.com

drm: remove drm_dev_set_unique

2023-03-22T09:24:47+00:00

Not used by any drivers any more, the only use case in drm_dev_init() can be inlined now. Signed-off-by: Christian König Reviewed-by: Jeffrey Hugo Link: https://patchwork.freedesktop.org/patch/msgid/20230316082035.567520-2-christian.koenig@amd.com

drm: remove dumb_destroy callback

2023-02-10T11:19:27+00:00

Not used by any driver any more. Signed-off-by: Christian König Reviewed-by: Thomas Zimmermann Tested-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20230126102814.8722-2-christian.koenig@amd.com

Merge drm/drm-next into drm-misc-next

2023-01-19T09:56:12+00:00

Backmerging into drm-misc-next to get DRM accelerator infrastructure, which is required by ipuv driver. Signed-off-by: Thomas Zimmermann

drm/nouveau: Remove support for legacy contexts/buffers

2023-01-13T08:22:02+00:00

Remove nouveau's support for legacy contexts and buffers. It was required by libdrm earlier than 2.4.33, released in March 2012. A previous attempt in 2013 to remove the functionality [1] had to be reverted [2] as there were still users left. Libdrm 2.4.33 is now almost 11 years old and it is time for userspace to move on. With the nouveau code gone, we can also remove the driver-feature bit DRIVER_KMS_LEGACY_CONTEXT. Signed-off-by: Thomas Zimmermann Reviewed-by: Karol Herbst Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c510133d93dd6f15ca040733ba7b2891ed61fd1 # 1 Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095 # 2 Link: https://patchwork.freedesktop.org/patch/msgid/20230112133858.17087-1-tzimmermann@suse.de

accel: add dedicated minor for accelerator devices

2022-11-22T11:14:44+00:00

The accelerator devices are exposed to user-space using a dedicated major. In addition, they are represented in /dev with new, dedicated device char names: /dev/accel/accel*. This is done to make sure any user-space software that tries to open a graphic card won't open the accelerator device by mistake. The above implies that the minor numbering should be separated from the rest of the DRM devices. However, to avoid code duplication, we want the drm_minor structure to be able to represent the accelerator device. To achieve this, we add a new drm_minor* to drm_device that represents the accelerator device. This pointer is initialized for drivers that declare they handle compute accelerator, using a new driver feature flag called DRIVER_COMPUTE_ACCEL. It is important to note that this driver feature is mutually exclusive with DRIVER_RENDER. Devices that want to expose both graphics and compute device char files should be handled by two drivers that are connected using the auxiliary bus framework. In addition, we define a different IDR to handle the accelerators minors. This is done to make the minor's index be identical to the device index in /dev/. Any access to the IDR is done solely by functions in accel_drv.c, as the IDR is define as static. The DRM core functions call those functions in case they detect the minor's type is DRM_MINOR_ACCEL. We define a separate accel_open function (from drm_open) that the accel drivers should set as their open callback function. Both these functions eventually call the same drm_open_helper(), which had to be changed to be non-static so it can be called from accel_drv.c. accel_open() only partially duplicates drm_open as I removed some code from it that handles legacy devices. To help new drivers, I defined DEFINE_DRM_ACCEL_FOPS macro to easily set the required function operations pointers structure. Signed-off-by: Oded Gabbay Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jeffrey Hugo Reviewed-by: Dave Airlie Acked-by: Thomas Zimmermann Acked-by: Jacek Lawrynowicz Tested-by: Jacek Lawrynowicz Reviewed-by: Melissa Wen