dri-devel February 2021

dri-devel@lists.freedesktop.org

314 participants
684 discussions

[PATCH rdma-core v7 0/6] Add user space dma-buf support
by Jianxin Xiong 03 Feb '21

03 Feb '21

This is the seventh version of the patch series. Change log: v7: * Rebase to the latest rdma-core master (commit a4885eda9addc4) * Rerun kernel-headers/update against linux-rdma for-next so that the kernel commit id in the commit message is correct v6: https://www.spinics.net/lists/linux-rdma/msg99221.html * Rebase to the latest rdma-core master (commit 14006f2f841b0c) * Update the ABI symbol version to match new package version; also bump the private ABI version because new function has been added to the provider interface * Avoid changing 'struct ibv_context_ops' by replacing SET_OP() with SET_PRIV_OP_IC() * Replace sprintf() with snprintf() * Keep the ops in verbs_set_ops() sorted * Fix some styling issues: extra spaces, struct 0-initialization, error checking control flow v5: https://www.spinics.net/lists/linux-rdma/msg99015.html * Use a different mr_type for dmabuf so that ibv_dofork_range() is not called inside ibv_dereg_mr() for dmabuf based mr v4: https://www.spinics.net/lists/linux-rdma/msg98135.html * Rework the cmake funciton rdma_cython_module to support both single source (.pyx) and multiple source (.pyx + [.c]*) scenarios instead of using two separate functions * Rename 'dri_*' to 'drm_*' for the dmabuf allocation interface * Add option to dmabuf allocation routine to allow allocation from GTT instead of VRAM * Add proper CPU access flags when allocating dmabufs * Remove 'radeon' driver support from the dmabuf allocation routines * Add comand line arguments to the tests for selecting GPU unit and setting the option for allocating from GTT v3: https://www.spinics.net/lists/linux-rdma/msg98059.html * Add parameter 'iova' to the new ibv_reg_dmabuf_mr() API * Change the way of allocating dma-buf object - use /dev/dri/renderD* instead of /dev/dri/card* and use GEM object instead of dumb buffer * Add cmake function to allow building modules with mixed cython and C source files * Add new tests that use dma-buf MRs for send/recv and rdma traffic * Skip dma-buf tests on unsupported systems * Remove some use of random values in the new tests * Add dealloc() and close() methods to the new classes * Replace string.format with f-string in python code * Fix some coding style issues: spacing, indentation, typo, comments v2: https://www.spinics.net/lists/linux-rdma/msg97936.html * Put the kernel header updates into a separate commit * Add comments for the data structure used in python ioctl calls * Fix issues related to symbol versioning * Fix styling issues: extra spaces, unncecessary variable, typo * Fix an inproper error code usage * Put the new op into ibv_context_ops instead if verbs_context v1: https://www.spinics.net/lists/linux-rdma/msg97865.html * Add user space API for registering dma-buf based memory regions * Update pyverbs with the new API * Add new tests This is the user space counter-part of the kernel patch set to add dma-buf support to the RDMA subsystem. This series consists of six patches. The first patch updates the kernel headers for dma-buf support. Patch 2 adds the new API function and updates the man pages. Patch 3 implements the new API in the mlx5 provider. Patch 4 adds new class definitions to pyverbs for the new API. Patch 5 adds a set of new tests for the new API. Patch 6 fixes bug in the utility code of the tests. Pull request at github: https://github.com/linux-rdma/rdma-core/pull/895 Jianxin Xiong (6): Update kernel headers verbs: Support dma-buf based memory region mlx5: Support dma-buf based memory region pyverbs: Add dma-buf based MR support tests: Add tests for dma-buf based memory regions tests: Bug fix for get_access_flags() buildlib/pyverbs_functions.cmake | 78 ++++++--- debian/libibverbs1.symbols | 2 + kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++ libibverbs/CMakeLists.txt | 2 +- libibverbs/cmd_mr.c | 38 +++++ libibverbs/driver.h | 8 + libibverbs/dummy_ops.c | 11 ++ libibverbs/libibverbs.map.in | 6 + libibverbs/man/ibv_reg_mr.3 | 27 ++- libibverbs/verbs.c | 19 +++ libibverbs/verbs.h | 7 + providers/mlx5/mlx5.c | 2 + providers/mlx5/mlx5.h | 3 + providers/mlx5/verbs.c | 22 +++ pyverbs/CMakeLists.txt | 11 +- pyverbs/dmabuf.pxd | 15 ++ pyverbs/dmabuf.pyx | 73 ++++++++ pyverbs/dmabuf_alloc.c | 278 +++++++++++++++++++++++++++++++ pyverbs/dmabuf_alloc.h | 19 +++ pyverbs/libibverbs.pxd | 2 + pyverbs/mr.pxd | 6 + pyverbs/mr.pyx | 105 +++++++++++- tests/args_parser.py | 4 + tests/test_mr.py | 266 ++++++++++++++++++++++++++++- tests/utils.py | 30 +++- 25 files changed, 1012 insertions(+), 36 deletions(-) create mode 100644 pyverbs/dmabuf.pxd create mode 100644 pyverbs/dmabuf.pyx create mode 100644 pyverbs/dmabuf_alloc.c create mode 100644 pyverbs/dmabuf_alloc.h -- 1.8.3.1

8 20

[PATCH v4 1/2] drm/msm: Add speed-bin support to a618 gpu
by Akhil P Oommen 03 Feb '21

03 Feb '21

Some GPUs support different max frequencies depending on the platform. To identify the correct variant, we should check the gpu speedbin fuse value. Add support for this speedbin detection to a6xx family along with the required fuse details for a618 gpu. Signed-off-by: Akhil P Oommen <akhilpo(a)codeaurora.org> --- Changes from v2: 1. Made the changes a6xx specific to save space. Changes from v1: 1. Added the changes to support a618 sku to the series. 2. Avoid failing probe in case of an unsupported sku. (Rob) Changes from v3: 1. Replace a618_speedbins[] with a function. (Jordan) drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 83 +++++++++++++++++++++++++++++++++++ drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 + 2 files changed, 85 insertions(+) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 1306618..499d134 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -10,6 +10,7 @@ #include <linux/bitfield.h> #include <linux/devfreq.h> +#include <linux/nvmem-consumer.h> #include <linux/soc/qcom/llcc-qcom.h> #define GPU_PAS_ID 13 @@ -1208,6 +1209,10 @@ static void a6xx_destroy(struct msm_gpu *gpu) a6xx_gmu_remove(a6xx_gpu); adreno_gpu_cleanup(adreno_gpu); + + if (a6xx_gpu->opp_table) + dev_pm_opp_put_supported_hw(a6xx_gpu->opp_table); + kfree(a6xx_gpu); } @@ -1264,6 +1269,78 @@ static uint32_t a6xx_get_rptr(struct msm_gpu *gpu, struct msm_ringbuffer *ring) return ring->memptrs->rptr = gpu_read(gpu, REG_A6XX_CP_RB_RPTR); } +static u32 a618_get_speed_bin(u32 fuse) +{ + if (fuse == 0) + return 0; + else if (fuse == 169) + return 1; + else if (fuse == 174) + return 2; + + return UINT_MAX; +} + +static u32 fuse_to_supp_hw(struct device *dev, u32 revn, u32 fuse) +{ + u32 val = UINT_MAX; + + if (revn == 618) + val = a618_get_speed_bin(fuse); + + if (val == UINT_MAX) { + DRM_DEV_ERROR(dev, + "missing support for speed-bin: %u. Some OPPs may not be supported by hardware", + fuse); + return UINT_MAX; + } + + return (1 << val); +} + +static int a6xx_set_supported_hw(struct device *dev, struct a6xx_gpu *a6xx_gpu, + u32 revn) +{ + struct opp_table *opp_table; + struct nvmem_cell *cell; + u32 supp_hw = UINT_MAX; + void *buf; + + cell = nvmem_cell_get(dev, "speed_bin"); + /* + * -ENOENT means that the platform doesn't support speedbin which is + * fine + */ + if (PTR_ERR(cell) == -ENOENT) + return 0; + else if (IS_ERR(cell)) { + DRM_DEV_ERROR(dev, + "failed to read speed-bin. Some OPPs may not be supported by hardware"); + goto done; + } + + buf = nvmem_cell_read(cell, NULL); + if (IS_ERR(buf)) { + nvmem_cell_put(cell); + DRM_DEV_ERROR(dev, + "failed to read speed-bin. Some OPPs may not be supported by hardware"); + goto done; + } + + supp_hw = fuse_to_supp_hw(dev, revn, *((u32 *) buf)); + + kfree(buf); + nvmem_cell_put(cell); + +done: + opp_table = dev_pm_opp_set_supported_hw(dev, &supp_hw, 1); + if (IS_ERR(opp_table)) + return PTR_ERR(opp_table); + + a6xx_gpu->opp_table = opp_table; + return 0; +} + static const struct adreno_gpu_funcs funcs = { .base = { .get_param = adreno_get_param, @@ -1325,6 +1402,12 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev) a6xx_llc_slices_init(pdev, a6xx_gpu); + ret = a6xx_set_supported_hw(&pdev->dev, a6xx_gpu, info->revn); + if (ret) { + a6xx_destroy(&(a6xx_gpu->base.base)); + return ERR_PTR(ret); + } + ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1); if (ret) { a6xx_destroy(&(a6xx_gpu->base.base)); diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h index e793d32..ce0610c 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h @@ -33,6 +33,8 @@ struct a6xx_gpu { void *llc_slice; void *htw_llc_slice; bool have_mmu500; + + struct opp_table *opp_table; }; #define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base) -- 2.7.4

3 4

[amdgpu] deadlock
by Daniel Gomez 03 Feb '21

03 Feb '21

Hi all, I have a deadlock with the amdgpu mainline driver when running in parallel two OpenCL applications. So far, we've been able to replicate it easily by executing clinfo and MatrixMultiplication (from AMD opencl-samples). It's quite old the opencl-samples so, if you have any other suggestion for testing I'd be very happy to test it as well. How to replicate the issue: # while true; do /usr/bin/MatrixMultiplication --device gpu \ --deviceId 0 -x 1000 -y 1000 -z 1000 -q -t -i 50; done # while true; do clinfo; done Output: After a minute or less (sometimes could be more) I can see that MatrixMultiplication and clinfo hang. In addition, with radeontop you can see how the Graphics pipe goes from ~50% to 100%. Also the shader clocks goes up from ~35% to ~96%. clinfo keeps printing: ioctl(7, DRM_IOCTL_SYNCOBJ_WAIT, 0x7ffe46e5f950) = -1 ETIME (Timer expired) And MatrixMultiplication prints the following (strace) if you try to kill the process: sched_yield() = 0 futex(0x557e945343b8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANYstrace: Process 651 detached <detached ...> After this, the gpu is not functional at all and you'd need a power cycle reset to restore the system. Hardware info: CPU: AMD Ryzen Embedded V1605B with Radeon Vega Gfx (8) @ 2.000GHz GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev 83) DeviceName: Broadcom 5762 Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] Kernel driver in use: amdgpu Kernel modules: amdgpu Linux kernel info: root@qt5222:~# uname -a Linux qt5222 5.11.0-rc6-qtec-standard #2 SMP Tue Feb 2 09:41:46 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux By enabling the kernel locks stats I could see the MatrixMultiplication is hanged in the amdgpu_mn_invalidate_gfx function: [ 738.359202] 1 lock held by MatrixMultiplic/653: [ 738.359206] #0: ffff88810e364fe0 (&adev->notifier_lock){+.+.}-{3:3}, at: amdgpu_mn_invalidate_gfx+0x34/0xa0 [amdgpu] I can see in the the amdgpu_mn_invalidate_gfx function: the dma_resv_wait_timeout_rcu uses wait_all (fences) and MAX_SCHEDULE_TIMEOUT so, I guess the code gets stuck there waiting forever. According to the documentation: "When somebody tries to invalidate the page tables we block the update until all operations on the pages in question are completed, then those pages are marked as accessed and also dirty if it wasn’t a read only access." Looks like the fences are deadlocked and therefore, it never returns. Could it be possible? any hint to where can I look to fix this? Thank you in advance. Here the full dmesg output: [ 738.337726] INFO: task MatrixMultiplic:653 blocked for more than 122 seconds. [ 738.344937] Not tainted 5.11.0-rc6-qtec-standard #2 [ 738.350384] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 738.358240] task:MatrixMultiplic state:D stack: 0 pid: 653 ppid: 1 flags:0x00004000 [ 738.358254] Call Trace: [ 738.358261] ? dma_fence_default_wait+0x1eb/0x230 [ 738.358276] __schedule+0x370/0x960 [ 738.358291] ? dma_fence_default_wait+0x117/0x230 [ 738.358297] ? dma_fence_default_wait+0x1eb/0x230 [ 738.358305] schedule+0x51/0xc0 [ 738.358312] schedule_timeout+0x275/0x380 [ 738.358324] ? dma_fence_default_wait+0x1eb/0x230 [ 738.358332] ? mark_held_locks+0x4f/0x70 [ 738.358341] ? dma_fence_default_wait+0x117/0x230 [ 738.358347] ? lockdep_hardirqs_on_prepare+0xd4/0x180 [ 738.358353] ? _raw_spin_unlock_irqrestore+0x39/0x40 [ 738.358362] ? dma_fence_default_wait+0x117/0x230 [ 738.358370] ? dma_fence_default_wait+0x1eb/0x230 [ 738.358375] dma_fence_default_wait+0x214/0x230 [ 738.358384] ? dma_fence_release+0x1a0/0x1a0 [ 738.358396] dma_fence_wait_timeout+0x105/0x200 [ 738.358405] dma_resv_wait_timeout_rcu+0x1aa/0x5e0 [ 738.358421] amdgpu_mn_invalidate_gfx+0x55/0xa0 [amdgpu] [ 738.358688] __mmu_notifier_release+0x1bb/0x210 [ 738.358710] exit_mmap+0x2f/0x1e0 [ 738.358723] ? find_held_lock+0x34/0xa0 [ 738.358746] mmput+0x39/0xe0 [ 738.358756] do_exit+0x5c3/0xc00 [ 738.358763] ? find_held_lock+0x34/0xa0 [ 738.358780] do_group_exit+0x47/0xb0 [ 738.358791] get_signal+0x15b/0xc50 [ 738.358807] arch_do_signal_or_restart+0xaf/0x710 [ 738.358816] ? lockdep_hardirqs_on_prepare+0xd4/0x180 [ 738.358822] ? _raw_spin_unlock_irqrestore+0x39/0x40 [ 738.358831] ? ktime_get_mono_fast_ns+0x50/0xa0 [ 738.358844] ? amdgpu_drm_ioctl+0x6b/0x80 [amdgpu] [ 738.359044] exit_to_user_mode_prepare+0xf2/0x1b0 [ 738.359054] syscall_exit_to_user_mode+0x19/0x60 [ 738.359062] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 738.359069] RIP: 0033:0x7f6b89a51887 [ 738.359076] RSP: 002b:00007f6b82b54b18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 738.359086] RAX: fffffffffffffe00 RBX: 00007f6b82b54b50 RCX: 00007f6b89a51887 [ 738.359091] RDX: 00007f6b82b54b50 RSI: 00000000c02064c3 RDI: 0000000000000007 [ 738.359096] RBP: 00000000c02064c3 R08: 0000000000000003 R09: 00007f6b82b54bbc [ 738.359101] R10: 0000000000000001 R11: 0000000000000246 R12: 0000000165a0bc00 [ 738.359106] R13: 0000000000000007 R14: 0000000000000001 R15: 0000000000000000 [ 738.359129] Showing all locks held in the system: [ 738.359141] 1 lock held by khungtaskd/54: [ 738.359148] #0: ffffffff829f6840 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x15/0x183 [ 738.359187] 1 lock held by systemd-journal/174: [ 738.359202] 1 lock held by MatrixMultiplic/653: [ 738.359206] #0: ffff88810e364fe0 (&adev->notifier_lock){+.+.}-{3:3}, at: amdgpu_mn_invalidate_gfx+0x34/0xa0 [amdgpu] Daniel

6 19

[PATCH] drm/v3d: Fix incorrect return type to timedout_job
by Patrik Jakobsson 03 Feb '21

03 Feb '21

The commit a6a1f036c74e ("drm/scheduler: Job timeout handler returns status (v3)") incorrectly uses "enum drm_task_status" for v3d and causes a build failure. "enum drm_task_status" got changed into "enum drm_gpu_sched_status" in v3 of the patch but the change for v3d got lost. Fixes: ("drm/scheduler: Job timeout handler returns status (v3)") Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> --- drivers/gpu/drm/v3d/v3d_sched.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c index ef2338a294ca..ceb33f8e4379 100644 --- a/drivers/gpu/drm/v3d/v3d_sched.c +++ b/drivers/gpu/drm/v3d/v3d_sched.c @@ -259,7 +259,7 @@ v3d_cache_clean_job_run(struct drm_sched_job *sched_job) return NULL; } -static enum drm_gpu_sched_status +static enum drm_gpu_sched_stat v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job *sched_job) { enum v3d_queue q; @@ -294,7 +294,7 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job *sched_job) * could fail if the GPU got in an infinite loop in the CL, but that * is pretty unlikely outside of an i-g-t testcase. */ -static enum drm_task_status +static enum drm_gpu_sched_stat v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q, u32 *timedout_ctca, u32 *timedout_ctra) { @@ -312,7 +312,7 @@ v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q, return v3d_gpu_reset_for_timeout(v3d, sched_job); } -static enum drm_task_status +static enum drm_gpu_sched_stat v3d_bin_job_timedout(struct drm_sched_job *sched_job) { struct v3d_bin_job *job = to_bin_job(sched_job); @@ -321,7 +321,7 @@ v3d_bin_job_timedout(struct drm_sched_job *sched_job) &job->timedout_ctca, &job->timedout_ctra); } -static enum drm_task_status +static enum drm_gpu_sched_stat v3d_render_job_timedout(struct drm_sched_job *sched_job) { struct v3d_render_job *job = to_render_job(sched_job); @@ -330,7 +330,7 @@ v3d_render_job_timedout(struct drm_sched_job *sched_job) &job->timedout_ctca, &job->timedout_ctra); } -static enum drm_task_status +static enum drm_gpu_sched_stat v3d_generic_job_timedout(struct drm_sched_job *sched_job) { struct v3d_job *job = to_v3d_job(sched_job); @@ -338,7 +338,7 @@ v3d_generic_job_timedout(struct drm_sched_job *sched_job) return v3d_gpu_reset_for_timeout(job->v3d, sched_job); } -static enum drm_task_status +static enum drm_gpu_sched_stat v3d_csd_job_timedout(struct drm_sched_job *sched_job) { struct v3d_csd_job *job = to_csd_job(sched_job); -- 2.30.0

4 4

[PATCH 0/3] drm/panfrost: MMU fixes
by Boris Brezillon 03 Feb '21

03 Feb '21

Hello, Here are 2 fixes and one improvement for the page fault handling. Those bugs were found while working on indirect draw supports which requires the allocation of a big heap buffer for varyings, and the vertex/tiler shaders seem to have access pattern that trigger those issues. I remember discussing the first issue with Steve or Robin a while back, but we never hit it before (now we do :)). The last patch is a perf improvement: no need to re-enable hardware interrupts if we know the threaded irq handler will be woken up right away. Regards, Boris Boris Brezillon (3): drm/panfrost: Clear MMU irqs before handling the fault drm/panfrost: Don't try to map pages that are already mapped drm/panfrost: Stay in the threaded MMU IRQ handler until we've handled all IRQs drivers/gpu/drm/panfrost/panfrost_mmu.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) -- 2.26.2

3 11

[PATCH v5 0/6] drm/qxl: fix driver shutdown issues.
by Gerd Hoffmann 03 Feb '21

03 Feb '21

Almost there. Still getting this on driver unbind: kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_put(= ) is being called [ ... ] Call Trace: ttm_device_fini+0x133/0x1b0 [ttm] qxl_ttm_fini+0x2f/0x40 [qxl] qxl_device_fini+0x88/0x120 [qxl] drm_minor_release+0x3d/0x60 but I don't think this is the qxl driver's fault. v5: - add release_event wait queue. - also cleanup qxl_fence_wait(). Gerd Hoffmann (6): drm/qxl: use drmm_mode_config_init drm/qxl: unpin release objects drm/qxl: release shadow on shutdown drm/qxl: handle shadow in primary destroy drm/qxl: properly free qxl releases drm/qxl: simplify qxl_fence_wait drivers/gpu/drm/qxl/qxl_drv.h | 2 ++ drivers/gpu/drm/qxl/qxl_cmd.c | 1 + drivers/gpu/drm/qxl/qxl_display.c | 11 ++++++-- drivers/gpu/drm/qxl/qxl_irq.c | 1 + drivers/gpu/drm/qxl/qxl_kms.c | 22 +++++++++++++-- drivers/gpu/drm/qxl/qxl_release.c | 45 +++++-------------------------- 6 files changed, 40 insertions(+), 42 deletions(-) --=20 2.29.2

3 12

[PATCH 0/6 RFC] drm: Move vmap out of commit tail for SHMEM drivers
by Thomas Zimmermann 03 Feb '21

03 Feb '21

Several SHMEM-based drivers use the BO as shadow buffer for the real framebuffer memory. Damage handling requires a vmap of the BO memory. Vmap/vunmap can acquire the dma-buf reservation lock, which is not allowed in commit tails. This patchset introduces a set of helpers that implement vmap/vunmap in the plane's prepare_fb and cleanup_fb; and provide the mapping's address to commit-tail functions. Wrapper sfor simple KMS are provides, as all of the involved drivers are built upon simple-KMS helpers. Patch 1 adds the support for private plane state to the simple-KMS helper library. Patch 2 provides plane state for SHMEM-based shadow planes. It's a DRM plane with BO mappings into kernel address space. The involved helpers take care of the details. Patches 3 to 6 convert each involved driver to the new shadow-plane helpers. The vmap operations are being removed from commit-tail functions. An additional benefit is that vmap errors are now detected before the commit starts. The original commit-tail functions could not handle failed vmap operations. I smoke-tested the code by running fbdev, Xorg and weston with the converted mgag200 driver. Thomas Zimmermann (6): drm/simple-kms: Add plane-state helpers drm/shmem-helper: Add additional KMS helpers drm/mgag200: Move vmap out of commit tail drm/cirrus: Move vmap out of commit tail drm/gm12u320: Move vmap out of commit tail drm/udl: Move vmap out of commit tail drivers/gpu/drm/Kconfig | 7 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_gem_shmem_kms_helper.c | 159 +++++++++++++++++++++ drivers/gpu/drm/drm_simple_kms_helper.c | 40 +++++- drivers/gpu/drm/mgag200/Kconfig | 1 + drivers/gpu/drm/mgag200/mgag200_mode.c | 25 ++-- drivers/gpu/drm/tiny/Kconfig | 6 +- drivers/gpu/drm/tiny/cirrus.c | 45 +++--- drivers/gpu/drm/tiny/gm12u320.c | 30 ++-- drivers/gpu/drm/udl/Kconfig | 1 + drivers/gpu/drm/udl/udl_modeset.c | 36 ++--- include/drm/drm_gem_shmem_kms_helper.h | 56 ++++++++ include/drm/drm_simple_kms_helper.h | 28 ++++ 13 files changed, 353 insertions(+), 82 deletions(-) create mode 100644 drivers/gpu/drm/drm_gem_shmem_kms_helper.c create mode 100644 include/drm/drm_gem_shmem_kms_helper.h base-commit: 1e37c3960fd3910f3f65cd6927a6ebab8e8efc26 -- 2.30.0

2 9

[PATCH][next] drm/nouveau/fifo/tu102: Fix potential array out of bounds access error
by Colin King 03 Feb '21

03 Feb '21

From: Colin Ian King <colin.king(a)canonical.com> Currently the for_each_set_bit loop is iterating index engn from 0..31 and calls to tu102_fifo_recover_engn can potentiall access fifo->engine[engn] where engn is larger than the array engine (which is currently hard coded as 16 elements). Avoid any potential array out of bounds accesses by replacing the hard coded value 32 with the number of elements in the array. Addresses-Coverity: ("Out-of-bounds access") Fixes: 26a0cfc163ab ("drm/nouveau/fifo/tu102: FIFO interrupt fixes for Turing") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.c index 14e5b70e0255..1f33f8c757bf 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.c @@ -366,7 +366,7 @@ tu102_fifo_intr_ctxsw_timeout(struct gk104_fifo *fifo) engm = nvkm_rd32(device, 0x2a30); nvkm_wr32(device, 0x2a30, engm); - for_each_set_bit(engn, &engm, 32) + for_each_set_bit(engn, &engm, ARRAY_SIZE(fifo->engine)) tu102_fifo_recover_engn(fifo, engn); spin_unlock_irqrestore(&fifo->base.lock, flags); -- 2.29.2

1 0

[PATCH] drm/todo: Add entry for moving to dma_resv_lock
by Daniel Vetter 03 Feb '21

03 Feb '21

Requested by Thomas. I think it justifies a new level, since I tried to make some forward progress on this last summer, and gave up (for now). This is very tricky. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- Documentation/gpu/todo.rst | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index dea9082c0e5f..f872d3d33218 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -23,6 +23,9 @@ Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem and graphics topics. Generally need the relevant hardware for development and testing. +Expert: Only attempt these if you've successfully completed some tricky +refactorings already and are an expert in the specific area + Subsystem-wide refactorings =========================== @@ -168,6 +171,22 @@ Contact: Daniel Vetter, respective driver maintainers Level: Advanced +Move Buffer Object Locking to dma_resv_lock() +--------------------------------------------- + +Many drivers have their own per-object locking scheme, usually using +mutex_lock(). This causes all kinds of trouble for buffer sharing, since +depending which driver is the exporter and importer, the locking hierarchy is +reversed. + +To solve this we need one standard per-object locking mechanism, which is +dma_resv_lock(). This lock needs to be called as the outermost lock, with all +other driver specific per-object locks removed. The problem is tha rolling out +the actual change to the locking contract is a flag day, due to struct dma_buf +buffer sharing. + +Level: Expert + Convert logging to drm_* functions with drm_device paramater ------------------------------------------------------------ -- 2.30.0

4 4

[PATCH v4 0/5] drm/qxl: fix driver shutdown issues.
by Gerd Hoffmann 03 Feb '21

03 Feb '21

Almost there. Still getting this on driver unbind: kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_put(= ) is being called [ ... ] Call Trace: ttm_device_fini+0x133/0x1b0 [ttm] qxl_ttm_fini+0x2f/0x40 [qxl] qxl_device_fini+0x88/0x120 [qxl] drm_minor_release+0x3d/0x60 but I don't think this is the qxl driver's fault. Gerd Hoffmann (5): drm/qxl: use drmm_mode_config_init drm/qxl: unpin release objects drm/qxl: release shadow on shutdown drm/qxl: handle shadow in primary destroy drm/qxl: properly free qxl releases drivers/gpu/drm/qxl/qxl_drv.h | 1 + drivers/gpu/drm/qxl/qxl_display.c | 11 +++++++++-- drivers/gpu/drm/qxl/qxl_kms.c | 22 ++++++++++++++++++++-- drivers/gpu/drm/qxl/qxl_release.c | 3 +++ 4 files changed, 33 insertions(+), 4 deletions(-) --=20 2.29.2

2 7

← Newer
1
...
58
59
60
61
62
63
64
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2021