dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

[PATCH v5 00/17] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers
by Dmitry Osipenko 28 Apr '22

28 Apr '22

Hello, This patchset introduces memory shrinker for the VirtIO-GPU DRM driver. During OOM, the shrinker will release BOs that are marked as "not needed" by userspace using the new madvise IOCTL, it will also evict idling BOs to SWAP. The userspace in this case is the Mesa VirGL driver, it will mark the cached BOs as "not needed", allowing kernel driver to release memory of the cached shmem BOs on lowmem situations, preventing OOM kills. This patchset adds memory purging and eviction support to VirtIO-GPU driver. The Panfrost driver is switched to use generic memory shrinker. Eviction support will come later on, after resolving the blocker bug in Panfrost. This patchset also includes couple improvements and fixes for various minor things that I found while was working on the shrinker. The Mesa and IGT patches will be kept on hold until this kernel series will be approved and merged. This patchset was tested using Qemu and crosvm, including both cases of IOMMU off/on. Mesa: https://gitlab.freedesktop.org/digetx/mesa/-/commits/virgl-madvise IGT: https://gitlab.freedesktop.org/digetx/igt-gpu-tools/-/commits/virtio-madvise https://gitlab.freedesktop.org/digetx/igt-gpu-tools/-/commits/panfrost-madv… Changelog: v5: - Added new for-stable patch "drm/panfrost: Put mapping instead of shmem obj on panfrost_mmu_map_fault_addr() error" that corrects GEM's refcounting in case of error. - The drm_gem_shmem_v[un]map() now takes a separate vmap_lock for imported GEMs to avoid recursive locking of DMA reservations. This addresses v4 comment from Thomas Zimmermann about the potential deadlocking of vmapping. - Added ack from Thomas Zimmermann to "drm/shmem-helper: Correct doc-comment of drm_gem_shmem_get_sg_table()" patch. - Dropped explicit shmem states from the generic shrinker patch as was requested by Thomas Zimmermann. - Improved variable names and comments of the generic shrinker code. - Extended drm_gem_shmem_print_info() with the shrinker-state info in the "drm/virtio: Support memory shrinking" patch. - Moved evict()/swap_in()/purge() callbacks from drm_gem_object_funcs to drm_gem_shmem_object in the generic shrinker patch, for more consistency. - Corrected bisectability of the patches that was broken in v4 by accident. - The virtio_gpu_plane_prepare_fb() now uses drm_gem_shmem_pin() instead of drm_gem_shmem_set_unpurgeable_and_unevictable() and does it only for shmem BOs in the "drm/virtio: Support memory shrinking" patch. - Made more functions private to drm_gem_shmem_helper.c as was requested by Thomas Zimmermann. This minimizes number of the public shmem helpers. v4: - Corrected minor W=1 warnings reported by kernel test robot for v3. - Renamed DRM_GEM_SHMEM_PAGES_STATE_ACTIVE/INACTIVE to PINNED/UNPINNED, for more clarity. v3: - Hardened shrinker's count() with usage of READ_ONCE() since we don't use atomic type for counting and technically compiler is free to re-fetch counter's variable. - "Correct drm_gem_shmem_get_sg_table() error handling" now uses PTR_ERR_OR_ZERO(), fixing typo that was made in v2. - Removed obsoleted shrinker from the Panfrost driver, which I missed to do in v2 by accident and Alyssa Rosenzweig managed to notice it. - CCed stable kernels in all patches that make fixes, even the minor ones, like was suggested by Emil Velikov and added his r-b to the patches. - Added t-b from Steven Price to the Panfrost's shrinker patch. - Corrected doc-comment of drm_gem_shmem_object.madv, like was suggested by Steven Price. Comment now says that madv=1 means "object is purged" instead of saying that value is unused. - Added more doc-comments to the new shmem shrinker API. - The "Improve DMA API usage for shmem BOs" patch got more improvements by removing the obsoleted drm_dev_set_unique() quirk and its comment. - Added patch that makes Virtio-GPU driver to use common dev_is_pci() helper, which was suggested by Robin Murphy. - Added new "drm/shmem-helper: Take GEM reservation lock instead of drm_gem_shmem locks" patch, which was suggested by Daniel Vetter. - Added new "drm/virtio: Simplify error handling of virtio_gpu_object_create()" patch. - Improved "Correct doc-comment of drm_gem_shmem_get_sg_table()" patch, like was suggested by Daniel Vetter, by saying that function returns ERR_PTR() and not errno. - virtio_gpu_purge_object() is fenced properly now, turned out virtio_gpu_notify() doesn't do fencing as I was supposing before. Stress testing of memory eviction revealed that. - Added new patch that corrects virtio_gpu_plane_cleanup_fb() to use appropriate atomic plane state. - SHMEM shrinker got eviction support. - VirtIO-GPU driver now supports memory eviction. It's enabled for a non-blob GEMs only, i.e. for VirGL. The blobs don't support dynamic attaching/detaching of guest's memory, so it's not trivial to enable them. - Added patch that removes obsoleted drm_gem_shmem_purge() - Added patch that makes drm_gem_shmem_get_pages() private. - Added patch that fixes lockup on dma_resv_reserve_fences() error. v2: - Improved shrinker by using a more fine-grained locking to reduce contention during scan of objects and dropped locking from the 'counting' callback by tracking count of shrinkable pages. This was suggested by Rob Clark in the comment to v1. - Factored out common shrinker code into drm_gem_shmem_helper.c and switched Panfrost driver to use the new common memory shrinker. This was proposed by Thomas Zimmermann in his prototype series that he shared with us in the comment to v1. Note that I only compile-tested the Panfrost driver. - Shrinker now takes object_name_lock during scan to prevent racing with dma-buf exporting. - Shrinker now takes vmap_lock during scan to prevent racing with shmem vmap/unmap code. - Added "Correct doc-comment of drm_gem_shmem_get_sg_table()" patch, which I sent out previously as a standalone change, since the drm_gem_shmem_helper.c is now touched by this patchset anyways and it doesn't hurt to group all the patches together. Dmitry Osipenko (17): drm/panfrost: Put mapping instead of shmem obj on panfrost_mmu_map_fault_addr() error drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling drm/virtio: Check whether transferred 2D BO is shmem drm/virtio: Unlock reservations on virtio_gpu_object_shmem_init() error drm/virtio: Unlock reservations on dma_resv_reserve_fences() error drm/virtio: Use appropriate atomic state in virtio_gpu_plane_cleanup_fb() drm/virtio: Simplify error handling of virtio_gpu_object_create() drm/virtio: Improve DMA API usage for shmem BOs drm/virtio: Use dev_is_pci() drm/shmem-helper: Correct doc-comment of drm_gem_shmem_get_sg_table() drm/shmem-helper: Take reservation lock instead of drm_gem_shmem locks drm/shmem-helper: Add generic memory shrinker drm/virtio: Support memory shrinking drm/panfrost: Switch to generic memory shrinker drm/shmem-helper: Make drm_gem_shmem_get_pages() private drm/shmem-helper: Make drm_gem_shmem_is_purgeable() private drm/shmem-helper: Remove drm_gem_shmem_purge_locked() drivers/gpu/drm/drm_gem_shmem_helper.c | 800 ++++++++++++++++-- drivers/gpu/drm/lima/lima_gem.c | 8 +- drivers/gpu/drm/panfrost/Makefile | 1 - drivers/gpu/drm/panfrost/panfrost_device.h | 4 - drivers/gpu/drm/panfrost/panfrost_drv.c | 19 +- drivers/gpu/drm/panfrost/panfrost_gem.c | 28 +- drivers/gpu/drm/panfrost/panfrost_gem.h | 9 - .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 122 --- drivers/gpu/drm/panfrost/panfrost_job.c | 18 +- drivers/gpu/drm/panfrost/panfrost_mmu.c | 17 +- drivers/gpu/drm/virtio/virtgpu_drv.c | 53 +- drivers/gpu/drm/virtio/virtgpu_drv.h | 20 +- drivers/gpu/drm/virtio/virtgpu_gem.c | 50 +- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 37 + drivers/gpu/drm/virtio/virtgpu_kms.c | 16 +- drivers/gpu/drm/virtio/virtgpu_object.c | 195 +++-- drivers/gpu/drm/virtio/virtgpu_plane.c | 28 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 55 +- include/drm/drm_device.h | 4 + include/drm/drm_gem_shmem_helper.h | 127 ++- include/uapi/drm/virtgpu_drm.h | 14 + 21 files changed, 1227 insertions(+), 398 deletions(-) delete mode 100644 drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c -- 2.35.1

3 21

[PATCH] gpu/drm/radeon: Fix spelling typo in comments
by pengfuyuan 28 Apr '22

28 Apr '22

Fix spelling typo in comments. Signed-off-by: pengfuyuan <pengfuyuan(a)kylinos.cn> --- drivers/gpu/drm/radeon/atombios.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios.h b/drivers/gpu/drm/radeon/atombios.h index bd5dc09e860f..e00d6adf7262 100644 --- a/drivers/gpu/drm/radeon/atombios.h +++ b/drivers/gpu/drm/radeon/atombios.h @@ -3599,7 +3599,7 @@ typedef struct _ATOM_LCD_RTS_RECORD UCHAR ucRTSValue; }ATOM_LCD_RTS_RECORD; -//!! If the record below exits, it shoud always be the first record for easy use in command table!!! +//!! If the record below exits, it should always be the first record for easy use in command table!!! // The record below is only used when LVDS_Info is present. From ATOM_LVDS_INFO_V12, use ucLCDPanel_SpecialHandlingCap instead. typedef struct _ATOM_LCD_MODE_CONTROL_CAP { @@ -3823,7 +3823,7 @@ typedef struct _ATOM_DPCD_INFO // Note1: This table is filled by SetBiosReservationStartInFB in CoreCommSubs.asm // at running time. // note2: From RV770, the memory is more than 32bit addressable, so we will change -// ucTableFormatRevision=1,ucTableContentRevision=4, the strcuture remains +// ucTableFormatRevision=1,ucTableContentRevision=4, the structure remains // exactly same as 1.1 and 1.2 (1.3 is never in use), but ulStartAddrUsedByFirmware // (in offset to start of memory address) is KB aligned instead of byte aligend. /***********************************************************************************/ @@ -3858,7 +3858,7 @@ typedef struct _ATOM_VRAM_USAGE_BY_FIRMWARE ATOM_FIRMWARE_VRAM_RESERVE_INFO asFirmwareVramReserveInfo[ATOM_MAX_FIRMWARE_VRAM_USAGE_INFO]; }ATOM_VRAM_USAGE_BY_FIRMWARE; -// change verion to 1.5, when allow driver to allocate the vram area for command table access. +// change version to 1.5, when allow driver to allocate the vram area for command table access. typedef struct _ATOM_FIRMWARE_VRAM_RESERVE_INFO_V1_5 { ULONG ulStartAddrUsedByFirmware; @@ -5973,7 +5973,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3 #define CLEAR_ATOM_S7_DOS_8BIT_DAC_EN ((ATOM_DOS_MODE_INFO_DEF << 8 )|ATOM_S7_DOS_8BIT_DAC_EN_SHIFT | ATOM_FLAG_CLEAR ) /****************************************************************************/ -//Portion II: Definitinos only used in Driver +//Portion II: Definitions only used in Driver /****************************************************************************/ // Macros used by driver @@ -7162,7 +7162,7 @@ typedef struct _DP_ENCODER_SERVICE_PARAMETERS // ucAction #define ATOM_DP_ACTION_GET_SINK_TYPE 0x01 -/* obselete */ +/* obsolete */ #define ATOM_DP_ACTION_TRAINING_START 0x02 #define ATOM_DP_ACTION_TRAINING_COMPLETE 0x03 #define ATOM_DP_ACTION_TRAINING_PATTERN_SEL 0x04 -- 2.25.1

2 1

[PATCH v3] drm/display: Select DP helper for DRM_DP_AUX_CHARDEV and DRM_DP_CEC
by Javier Martinez Canillas 28 Apr '22

28 Apr '22

The DRM_DP_AUX_CHARDEV and DRM_DP_CEC Kconfig symbols enable code that use DP helper functions, that are only present if CONFIG_DRM_DISPLAY_DP_HELPER is also enabled. But these don't select the DRM_DISPLAY_DP_HELPER symbol, meaning that it is possible to enable any of them without CONFIG_DRM_DISPLAY_DP_HELPER. That will lead to the following linking errors with the mentioned config: LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.kallsyms1 KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.S LD .tmp_vmlinux.kallsyms2 KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.S LD vmlinux SYSMAP System.map SORTTAB vmlinux OBJCOPY arch/arm64/boot/Image MODPOST modules-only.symvers ERROR: modpost: "drm_dp_dpcd_write" [drivers/gpu/drm/display/drm_display_helper.ko] undefined! ERROR: modpost: "drm_dp_read_desc" [drivers/gpu/drm/display/drm_display_helper.ko] undefined! ERROR: modpost: "drm_dp_dpcd_read" [drivers/gpu/drm/display/drm_display_helper.ko] undefined! make[1]: *** [scripts/Makefile.modpost:134: modules-only.symvers] Error 1 make[1]: *** Deleting file 'modules-only.symvers' make: *** [Makefile:1749: modules] Error 2 Besides making these symbols to select CONFIG_DRM_DISPLAY_DP_HELPER, make them to depend on DRM_DISPLAY_HELPER, since can't be enabled without it. Note: It seems this has been an issue for a long time but was made easier to reproduce after the commit 1e0f66420b13 ("drm/display: Introduce a DRM display-helper module"). Adding a Fixes: tag just to make sure that this fix will be picked for stable once the mentioned change also lands there. Fixes: 1e0f66420b13 ("drm/display: Introduce a DRM display-helper module") Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> --- Changes in v3: - Also make DRM_DP_AUX_CHARDEV and DRM_DP_CEC depend on DRM_DISPLAY_HELPER (Thomas Zimmermann). Changes in v2: - Explain better the issue in the change description. - Only select DRM_DISPLAY_DP_HELPER and not DRM_DISPLAY_HELPER. drivers/gpu/drm/display/Kconfig | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig index f84f1b0cd23f..1b6e6af37546 100644 --- a/drivers/gpu/drm/display/Kconfig +++ b/drivers/gpu/drm/display/Kconfig @@ -31,7 +31,8 @@ config DRM_DISPLAY_HDMI_HELPER config DRM_DP_AUX_CHARDEV bool "DRM DP AUX Interface" - depends on DRM + depends on DRM && DRM_DISPLAY_HELPER + select DRM_DISPLAY_DP_HELPER help Choose this option to enable a /dev/drm_dp_auxN node that allows to read and write values to arbitrary DPCD registers on the DP aux @@ -39,7 +40,8 @@ config DRM_DP_AUX_CHARDEV config DRM_DP_CEC bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" - depends on DRM + depends on DRM && DRM_DISPLAY_HELPER + select DRM_DISPLAY_DP_HELPER select CEC_CORE help Choose this option if you want to enable HDMI CEC support for -- 2.35.1

3 4

[PATCH] drm/msm/dpu: remove unused refcount for encoder_phys_wb
by Abhinav Kumar 28 Apr '22

28 Apr '22

Remove the unused local variable refcount for encoder_phys_wb as the one part of wb_enc is used directly. Fixes: 0ce51f19453e ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Abhinav Kumar <quic_abhinavk(a)quicinc.com> --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c index cb5c7da53c29..904124a3477e 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c @@ -407,9 +407,6 @@ static void dpu_encoder_phys_wb_irq_ctrl( struct dpu_encoder_phys_wb *wb_enc = to_dpu_encoder_phys_wb(phys); int ret = 0; - int refcount; - - refcount = atomic_read(&wb_enc->wbirq_refcount); if (enable && atomic_inc_return(&wb_enc->wbirq_refcount) == 1) { dpu_core_irq_register_callback(phys->dpu_kms, -- 2.7.4

2 2

[PATCH] drm/plane: Move range check for format_count earlier
by Steven Price 28 Apr '22

28 Apr '22

While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place. Signed-off-by: Steven Price <steven.price(a)arm.com> --- drivers/gpu/drm/drm_plane.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 82afb854141b..fd0bf90fb4c2 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -249,6 +249,13 @@ static int __drm_universal_plane_init(struct drm_device *dev, if (WARN_ON(config->num_total_plane >= 32)) return -EINVAL; + /* + * First driver to need more than 64 formats needs to fix this. Each + * format is encoded as a bit and the current code only supports a u64. + */ + if (WARN_ON(format_count > 64)) + return -EINVAL; + WARN_ON(drm_drv_uses_atomic_modeset(dev) && (!funcs->atomic_destroy_state || !funcs->atomic_duplicate_state)); @@ -270,13 +277,6 @@ static int __drm_universal_plane_init(struct drm_device *dev, return -ENOMEM; } - /* - * First driver to need more than 64 formats needs to fix this. Each - * format is encoded as a bit and the current code only supports a u64. - */ - if (WARN_ON(format_count > 64)) - return -EINVAL; - if (format_modifiers) { const uint64_t *temp_modifiers = format_modifiers; -- 2.25.1

3 4

[PATCH v4, 0/3] Add mt8186 dsi compatoble & Convert dsi_dtbinding to .yaml
by xinlei.lee＠mediatek.com 28 Apr '22

28 Apr '22

From: Xinlei Lee <xinlei.lee(a)mediatek.com> Changes since v3: 1. Add dsi port property. 2. Fix some formatting. Changes since v2: 1. Added #address-cells, #size-cells two properties. 2. Fix some formatting issues. Changes since v1: 1. Delete the mediatek,dsi.txt & Add the mediatek,dsi.yaml. 2. Ignore the Move the getting bridge node function patch for V1. Xinlei Lee (3): dt-bindings: display: mediatek: dsi: Convert dsi_dtbinding to .yaml dt-bindings: display: mediatek: dsi: Add compatible for MediaTek MT8186 drm/mediatek: Add mt8186 dsi compatible to mtk_dsi.c .../display/mediatek/mediatek,dsi.txt | 62 --------- .../display/mediatek/mediatek,dsi.yaml | 119 ++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_dsi.c | 8 ++ 3 files changed, 127 insertions(+), 62 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml -- 2.18.0

5 8

[PATCH] drm: handle kernel fences in drm_gem_plane_helper_prepare_fb
by Christian König 28 Apr '22

28 Apr '22

drm_gem_plane_helper_prepare_fb() was using drm_atomic_set_fence_for_plane() which ignores all implicit fences when an explicit fence is already set. That's rather unfortunate when the fb still has a kernel fence we need to wait for to avoid presenting garbage on the screen. So instead update the fence in the plane state directly. While at it also take care of all potential GEM objects and not just the first one. Also remove the now unused drm_atomic_set_fence_for_plane() function, new drivers should probably use the atomic helpers directly. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/drm_atomic_uapi.c | 37 --------------- drivers/gpu/drm/drm_gem_atomic_helper.c | 63 +++++++++++++++++++++---- include/drm/drm_atomic_uapi.h | 2 - include/drm/drm_plane.h | 4 +- 4 files changed, 54 insertions(+), 52 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index c6394ba13b24..0f461261b3f3 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -254,43 +254,6 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state *plane_state, } EXPORT_SYMBOL(drm_atomic_set_fb_for_plane); -/** - * drm_atomic_set_fence_for_plane - set fence for plane - * @plane_state: atomic state object for the plane - * @fence: dma_fence to use for the plane - * - * Helper to setup the plane_state fence in case it is not set yet. - * By using this drivers doesn't need to worry if the user choose - * implicit or explicit fencing. - * - * This function will not set the fence to the state if it was set - * via explicit fencing interfaces on the atomic ioctl. In that case it will - * drop the reference to the fence as we are not storing it anywhere. - * Otherwise, if &drm_plane_state.fence is not set this function we just set it - * with the received implicit fence. In both cases this function consumes a - * reference for @fence. - * - * This way explicit fencing can be used to overrule implicit fencing, which is - * important to make explicit fencing use-cases work: One example is using one - * buffer for 2 screens with different refresh rates. Implicit fencing will - * clamp rendering to the refresh rate of the slower screen, whereas explicit - * fence allows 2 independent render and display loops on a single buffer. If a - * driver allows obeys both implicit and explicit fences for plane updates, then - * it will break all the benefits of explicit fencing. - */ -void -drm_atomic_set_fence_for_plane(struct drm_plane_state *plane_state, - struct dma_fence *fence) -{ - if (plane_state->fence) { - dma_fence_put(fence); - return; - } - - plane_state->fence = fence; -} -EXPORT_SYMBOL(drm_atomic_set_fence_for_plane); - /** * drm_atomic_set_crtc_for_connector - set CRTC for connector * @conn_state: atomic state object for the connector diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c b/drivers/gpu/drm/drm_gem_atomic_helper.c index a6d89aed0bda..8fc0b42acdff 100644 --- a/drivers/gpu/drm/drm_gem_atomic_helper.c +++ b/drivers/gpu/drm/drm_gem_atomic_helper.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-or-later #include <linux/dma-resv.h> +#include <linux/dma-fence-chain.h> #include <drm/drm_atomic_state_helper.h> #include <drm/drm_atomic_uapi.h> @@ -141,25 +142,67 @@ * See drm_atomic_set_fence_for_plane() for a discussion of implicit and * explicit fencing in atomic modeset updates. */ -int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, struct drm_plane_state *state) +int drm_gem_plane_helper_prepare_fb(struct drm_plane *plane, + struct drm_plane_state *state) { + struct dma_fence *fence = dma_fence_get(state->fence); struct drm_gem_object *obj; - struct dma_fence *fence; + enum dma_resv_usage usage; + size_t i; int ret; if (!state->fb) return 0; - obj = drm_gem_fb_get_obj(state->fb, 0); - ret = dma_resv_get_singleton(obj->resv, DMA_RESV_USAGE_WRITE, &fence); - if (ret) - return ret; - - /* TODO: drm_atomic_set_fence_for_plane() should be changed to be able - * to handle more fences in general for multiple BOs per fb. + /* + * Only add the kernel fences here if there is already a fence set via + * explicit fencing interfaces on the atomic ioctl. + * + * This way explicit fencing can be used to overrule implicit fencing, + * which is important to make explicit fencing use-cases work: One + * example is using one buffer for 2 screens with different refresh + * rates. Implicit fencing will clamp rendering to the refresh rate of + * the slower screen, whereas explicit fence allows 2 independent + * render and display loops on a single buffer. If a driver allows + * obeys both implicit and explicit fences for plane updates, then it + * will break all the benefits of explicit fencing. */ - drm_atomic_set_fence_for_plane(state, fence); + usage = fence ? DMA_RESV_USAGE_KERNEL : DMA_RESV_USAGE_WRITE; + + for (i = 0; i < ARRAY_SIZE(state->fb->obj); ++i) { + struct dma_fence *new; + + obj = drm_gem_fb_get_obj(state->fb, i); + if (!obj) + continue; + + ret = dma_resv_get_singleton(obj->resv, usage, &new); + if (ret) + goto error; + + if (new && fence) { + struct dma_fence_chain *chain = dma_fence_chain_alloc(); + + if (!chain) { + ret = -ENOMEM; + goto error; + } + + dma_fence_chain_init(chain, fence, new, 1); + fence = &chain->base; + + } else if (new) { + fence = new; + } + } + + dma_fence_put(state->fence); + state->fence = fence; return 0; + +error: + dma_fence_put(fence); + return ret; } EXPORT_SYMBOL_GPL(drm_gem_plane_helper_prepare_fb); diff --git a/include/drm/drm_atomic_uapi.h b/include/drm/drm_atomic_uapi.h index 8cec52ad1277..4c6d39d7bdb2 100644 --- a/include/drm/drm_atomic_uapi.h +++ b/include/drm/drm_atomic_uapi.h @@ -49,8 +49,6 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state *plane_state, struct drm_crtc *crtc); void drm_atomic_set_fb_for_plane(struct drm_plane_state *plane_state, struct drm_framebuffer *fb); -void drm_atomic_set_fence_for_plane(struct drm_plane_state *plane_state, - struct dma_fence *fence); int __must_check drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state, struct drm_crtc *crtc); diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index 2628c7cde2da..89ea54652e87 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -74,9 +74,7 @@ struct drm_plane_state { * * Optional fence to wait for before scanning out @fb. The core atomic * code will set this when userspace is using explicit fencing. Do not - * write this field directly for a driver's implicit fence, use - * drm_atomic_set_fence_for_plane() to ensure that an explicit fence is - * preserved. + * write this field directly for a driver's implicit fence. * * Drivers should store any implicit fence in this from their * &drm_plane_helper_funcs.prepare_fb callback. See drm_gem_plane_helper_prepare_fb() -- 2.25.1

4 6

dim question: How to revert patches?
by Helge Deller 28 Apr '22

28 Apr '22

Hello dri-devel & dim users, I committed this patch to the drm-misc-next branch: commit d6cd978f7e6b6f6895f8d0c4ce6e5d2c8e979afe video: fbdev: fbmem: fix pointer reference to null device field then I noticed that it was fixed already in another branch which led to this error: Merging drm-misc/drm-misc-next... dim: dim: FAILURE: Could not merge drm-misc/drm-misc-next dim: See the section "Resolving Conflicts when Rebuilding drm-tip" dim: in the drm-tip.rst documentation for how to handle this situation. I fixed it by reverting that patch above with this new commit in the drm-misc-next branch: commit cabfa2bbe617ddf0a0cc4d01f72b584dae4939ad (HEAD -> drm-misc-next, drm-misc/for-linux-next, drm-misc/drm-misc-next) Author: Helge Deller <deller(a)gmx.de> Revert "video: fbdev: fbmem: fix pointer reference to null device field" My question (as "dim" newbie): Was that the right solution? Is there a possibility to drop those two patches from the drm-misc-next branch before it gets pushed upstream? TIA, Helge

2 3

[RFC PATCH 0/3] i915 writeback private framework
by Suraj Kandpal 28 Apr '22

28 Apr '22

A patch series was floated in the drm mailing list which aimed to change the drm_connector and drm_encoder fields to pointer in the drm_connector_writeback structure, this received a huge pushback from the community but since i915 expects each connector present in the drm_device list to be a intel_connector but drm_writeback framework. [1] https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1… [2] https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6… This forces us to use a drm_connector which is not embedded in intel_connector the current drm_writeback framework becomes very unfeasible to us as it would mean a lot of checks at a lot of places to take into account the above issue.Since no one had an issue with encoder field being changed into a pointer it was decided to break the connector and encoder pointer changes into two different series.The encoder field changes is currently being worked upon by Abhinav Kumar [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 In the meantime for i915 to start using the writeback functionality we came up with a interim solution to own writeback pipeline bypassing one provided by drm which is what these patches do. Note: these are temp patches till we figure out how we can either change drm core writeback to work with our intel_connector structure or find a different solution which allows us to work with the current drm_writeback framework Suraj Kandpal (3): drm/i915: Creating writeback pipeline to bypass drm_writeback framework drm/i915: Define WD trancoder for i915 drm/i915: Enabling WD Transcoder drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/display/intel_acpi.c | 1 + drivers/gpu/drm/i915/display/intel_display.c | 89 +- drivers/gpu/drm/i915/display/intel_display.h | 15 + .../drm/i915/display/intel_display_types.h | 18 + drivers/gpu/drm/i915/display/intel_dpll.c | 3 + drivers/gpu/drm/i915/display/intel_opregion.c | 3 + .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++++++ .../gpu/drm/i915/display/intel_wb_connector.h | 99 ++ drivers/gpu/drm/i915/display/intel_wd.c | 978 ++++++++++++++++++ drivers/gpu/drm/i915/display/intel_wd.h | 82 ++ drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_irq.c | 8 +- drivers/gpu/drm/i915/i915_pci.c | 7 +- drivers/gpu/drm/i915/i915_reg.h | 139 +++ 15 files changed, 1742 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.c create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h -- 2.35.1

3 8

[RFC v2 0/2] Attach and Set vrr_enabled property
by Bhanuprakash Modem 28 Apr '22

28 Apr '22

This series will add a support to attach & set the vrr_enabled property for crtc based on the platform support and the request from userspace. And userspace can also query to get the status of "vrr_enabled". Test-with: 20220422075223.2792586-2-bhanuprakash.modem(a)intel.com Bhanuprakash Modem (2): drm/vrr: Attach vrr_enabled property to the drm crtc drm/i915/vrr: Attach and set drm crtc vrr_enabled property drivers/gpu/drm/drm_crtc.c | 44 +++++++++++++++++++++++ drivers/gpu/drm/drm_mode_config.c | 2 +- drivers/gpu/drm/i915/display/intel_crtc.c | 3 ++ drivers/gpu/drm/i915/display/intel_vrr.c | 8 +++++ include/drm/drm_crtc.h | 4 +++ 5 files changed, 60 insertions(+), 1 deletion(-) -- 2.35.1

3 4

← Newer
1
...
19
20
21
22
23
24
25
...
96
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022