Linaro-mm-sig November 2023

linaro-mm-sig@lists.linaro.org

22 participants
38 discussions

[RFC PATCH] dma-buf/dma-fence: Use a successful read_trylock() annotation for dma_fence_begin_signalling()

by Thomas Hellström

Condsider the following call sequence: /* Upper layer */ dma_fence_begin_signalling(); lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); ... The driver might here use a utility that is annotated as intended for the dma-fence signalling critical path. Now if the upper layer isn't correctly annotated yet for whatever reason, resulting in /* Upper layer */ lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); We will receive a false lockdep locking order violation notification from dma_fence_begin_signalling(). However entering a dma-fence signalling critical section itself doesn't block and could not cause a deadlock. So use a successful read_trylock() annotation instead for dma_fence_begin_signalling(). That will make sure that the locking order is correctly registered in the first case, and doesn't register any locking order in the second case. The alternative is of course to make sure that the "Upper layer" is always correctly annotated. But experience shows that's not easily achievable in all cases. Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/dma-buf/dma-fence.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index f177c56269bb..17f632768ef9 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -308,8 +308,8 @@ bool dma_fence_begin_signalling(void) if (in_atomic()) return true; - /* ... and non-recursive readlock */ - lock_acquire(&dma_fence_lockdep_map, 0, 0, 1, 1, NULL, _RET_IP_); + /* ... and non-recursive successful read_trylock */ + lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _RET_IP_); return false; } @@ -340,7 +340,7 @@ void __dma_fence_might_wait(void) lock_map_acquire(&dma_fence_lockdep_map); lock_map_release(&dma_fence_lockdep_map); if (tmp) - lock_acquire(&dma_fence_lockdep_map, 0, 0, 1, 1, NULL, _THIS_IP_); + lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _THIS_IP_); } #endif -- 2.39.2

4 weeks

[PATCH] drm/shmem-helper: Remove duplicate include

by Jiapeng Chong

./drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4567 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 4ea6507a77e5..f401df26facf 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include <linux/shmem_fs.h> #include <linux/slab.h> #include <linux/vmalloc.h> -#include <linux/module.h> #ifdef CONFIG_X86 #include <asm/set_memory.h> -- 2.20.1.7.g153144c

7 months, 1 week

[syzbot] [dri?] KMSAN: uninit-value in drm_mode_setcrtc

by syzbot

Hello, syzbot found the following issue on: HEAD commit: 2741f1b02117 string: use __builtin_memcpy() in strlcpy/str.. git tree: https://github.com/google/kmsan.git master console+strace: https://syzkaller.appspot.com/x/log.txt?x=17bb33d1280000 kernel config: https://syzkaller.appspot.com/x/.config?x=753079601b2300f9 dashboard link: https://syzkaller.appspot.com/bug?extid=4fad2e57beb6397ab2fc compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16d669a5280000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14d8f095280000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/ebd05512d8d7/disk-2741f1b0.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/aa555b09582c/vmlinux-2741f1b0.… kernel image: https://storage.googleapis.com/syzbot-assets/5ea0934e02cc/bzImage-2741f1b0.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+4fad2e57beb6397ab2fc(a)syzkaller.appspotmail.com ===================================================== BUG: KMSAN: uninit-value in drm_mode_setcrtc+0x1ad3/0x24a0 drivers/gpu/drm/drm_crtc.c:896 drm_mode_setcrtc+0x1ad3/0x24a0 drivers/gpu/drm/drm_crtc.c:896 drm_ioctl_kernel+0x5ae/0x730 drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0xd12/0x1590 drivers/gpu/drm/drm_ioctl.c:891 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0x222/0x400 fs/ioctl.c:856 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716 slab_alloc_node mm/slub.c:3451 [inline] __kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490 __do_kmalloc_node mm/slab_common.c:965 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:979 kmalloc_array include/linux/slab.h:596 [inline] drm_mode_setcrtc+0x1dba/0x24a0 drivers/gpu/drm/drm_crtc.c:846 drm_ioctl_kernel+0x5ae/0x730 drivers/gpu/drm/drm_ioctl.c:788 drm_ioctl+0xd12/0x1590 drivers/gpu/drm/drm_ioctl.c:891 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0x222/0x400 fs/ioctl.c:856 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 1 PID: 4955 Comm: syz-executor275 Not tainted 6.4.0-rc4-syzkaller-g2741f1b02117 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 ===================================================== --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the bug is already fixed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to change bug's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the bug is a duplicate of another bug, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

10 months, 2 weeks

[RFC] drm/scheduler: Unwrap job dependencies

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> Container fences have burner contexts, which makes the trick to store at most one fence per context somewhat useless if we don't unwrap array or chain fences. Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- tbh, I'm not sure why we weren't doing this already, unless there is something I'm overlooking drivers/gpu/drm/scheduler/sched_main.c | 43 +++++++++++++++++--------- 1 file changed, 28 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index c2ee44d6224b..f59e5335afbb 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -41,20 +41,21 @@ * 4. Entities themselves maintain a queue of jobs that will be scheduled on * the hardware. * * The jobs in a entity are always scheduled in the order that they were pushed. */ #include <linux/kthread.h> #include <linux/wait.h> #include <linux/sched.h> #include <linux/completion.h> +#include <linux/dma-fence-unwrap.h> #include <linux/dma-resv.h> #include <uapi/linux/sched/types.h> #include <drm/drm_print.h> #include <drm/drm_gem.h> #include <drm/gpu_scheduler.h> #include <drm/spsc_queue.h> #define CREATE_TRACE_POINTS #include "gpu_scheduler_trace.h" @@ -665,41 +666,27 @@ void drm_sched_job_arm(struct drm_sched_job *job) sched = entity->rq->sched; job->sched = sched; job->s_priority = entity->rq - sched->sched_rq; job->id = atomic64_inc_return(&sched->job_id_count); drm_sched_fence_init(job->s_fence, job->entity); } EXPORT_SYMBOL(drm_sched_job_arm); -/** - * drm_sched_job_add_dependency - adds the fence as a job dependency - * @job: scheduler job to add the dependencies to - * @fence: the dma_fence to add to the list of dependencies. - * - * Note that @fence is consumed in both the success and error cases. - * - * Returns: - * 0 on success, or an error on failing to expand the array. - */ -int drm_sched_job_add_dependency(struct drm_sched_job *job, - struct dma_fence *fence) +static int _add_dependency(struct drm_sched_job *job, struct dma_fence *fence) { struct dma_fence *entry; unsigned long index; u32 id = 0; int ret; - if (!fence) - return 0; - /* Deduplicate if we already depend on a fence from the same context. * This lets the size of the array of deps scale with the number of * engines involved, rather than the number of BOs. */ xa_for_each(&job->dependencies, index, entry) { if (entry->context != fence->context) continue; if (dma_fence_is_later(fence, entry)) { dma_fence_put(entry); @@ -709,20 +696,46 @@ int drm_sched_job_add_dependency(struct drm_sched_job *job, } return 0; } ret = xa_alloc(&job->dependencies, &id, fence, xa_limit_32b, GFP_KERNEL); if (ret != 0) dma_fence_put(fence); return ret; } + +/** + * drm_sched_job_add_dependency - adds the fence as a job dependency + * @job: scheduler job to add the dependencies to + * @fence: the dma_fence to add to the list of dependencies. + * + * Note that @fence is consumed in both the success and error cases. + * + * Returns: + * 0 on success, or an error on failing to expand the array. + */ +int drm_sched_job_add_dependency(struct drm_sched_job *job, + struct dma_fence *fence) +{ + struct dma_fence_unwrap iter; + struct dma_fence *f; + int ret = 0; + + dma_fence_unwrap_for_each (f, &iter, fence) { + ret = _add_dependency(job, f); + if (ret) + break; + } + + return ret; +} EXPORT_SYMBOL(drm_sched_job_add_dependency); /** * drm_sched_job_add_resv_dependencies - add all fences from the resv to the job * @job: scheduler job to add the dependencies to * @resv: the dma_resv object to get the fences from * @usage: the dma_resv_usage to use to filter the fences * * This adds all fences matching the given usage from @resv to @job. * Must be called with the @resv lock held. -- 2.39.2

10 months, 2 weeks

[PATCH v9 0/3] dma-fence: Deadline awareness (uabi edition)

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> This is a re-post of the remaining patches from: https://patchwork.freedesktop.org/series/114490/ Part of the hold-up of the remaining uabi patches was compositor support, but now an MR for kwin exists: https://invent.kde.org/plasma/kwin/-/merge_requests/4358 The syncobj userspace is: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21973 v1: https://patchwork.freedesktop.org/series/93035/ v2: Move filtering out of later deadlines to fence implementation to avoid increasing the size of dma_fence v3: Add support in fence-array and fence-chain; Add some uabi to support igt tests and userspace compositors. v4: Rebase, address various comments, and add syncobj deadline support, and sync_file EPOLLPRI based on experience with perf/ freq issues with clvk compute workloads on i915 (anv) v5: Clarify that this is a hint as opposed to a more hard deadline guarantee, switch to using u64 ns values in UABI (still absolute CLOCK_MONOTONIC values), drop syncobj related cap and driver feature flag in favor of allowing count_handles==0 for probing kernel support. v6: Re-work vblank helper to calculate time of _start_ of vblank, and work correctly if the last vblank event was more than a frame ago. Add (mostly unrelated) drm/msm patch which also uses the vblank helper. Use dma_fence_chain_contained(). More verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v7: Fix kbuild complaints about vblank helper. Add more docs. v8: Add patch to surface sync_file UAPI, and more docs updates. v9: Repost the remaining patches that expose new uabi to userspace. Rob Clark (3): drm/syncobj: Add deadline support for syncobj waits dma-buf/sync_file: Add SET_DEADLINE ioctl dma-buf/sw_sync: Add fence deadline support drivers/dma-buf/dma-fence.c | 3 +- drivers/dma-buf/sw_sync.c | 82 ++++++++++++++++++++++++++++++++++ drivers/dma-buf/sync_debug.h | 2 + drivers/dma-buf/sync_file.c | 19 ++++++++ drivers/gpu/drm/drm_syncobj.c | 64 ++++++++++++++++++++------ include/uapi/drm/drm.h | 17 +++++++ include/uapi/linux/sync_file.h | 22 +++++++++ 7 files changed, 195 insertions(+), 14 deletions(-) -- 2.41.0

10 months, 3 weeks

Re: [PATCH] dma-buf: Correct the documentation of name and exp_name symbols

by Christian König

Am 22.11.23 um 17:05 schrieb Ramesh Errabolu: > Fix the documentation of struct dma_buf members name and exp_name > as to how these members are to be used and accessed. > > Signed-off-by: Ramesh Errabolu <Ramesh.Errabolu(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > include/linux/dma-buf.h | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h > index 3f31baa3293f..8ff4add71f88 100644 > --- a/include/linux/dma-buf.h > +++ b/include/linux/dma-buf.h > @@ -343,16 +343,19 @@ struct dma_buf { > /** > * @exp_name: > * > - * Name of the exporter; useful for debugging. See the > - * DMA_BUF_SET_NAME IOCTL. > + * Name of the exporter; useful for debugging. Must not be NULL > */ > const char *exp_name; > > /** > * @name: > * > - * Userspace-provided name; useful for accounting and debugging, > - * protected by dma_resv_lock() on @resv and @name_lock for read access. > + * Userspace-provided name. Default value is NULL. If not NULL, > + * length cannot be longer than DMA_BUF_NAME_LEN, including NIL > + * char. Useful for accounting and debugging. Read/Write accesses > + * are protected by @name_lock > + * > + * See the IOCTLs DMA_BUF_SET_NAME or DMA_BUF_SET_NAME_A/B > */ > const char *name; >

10 months, 3 weeks

[PATCH v2 0/6] DRM driver for verisilicon

by Keith Zhao

This patch is a drm driver for Starfive Soc JH7110, I am sending Drm driver part and HDMI driver part. We used GEM framework for buffer management , and for buffer allocation,we use DMA APIs. the Starfive HDMI servers as interface between a LCD Controller and a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and one HDMI transmitter PHY. (Sound support is not include in this patch) This patchset should be applied after the patchset: https://patchwork.kernel.org/project/linux-clk/cover/20230713113902.56519-1… V1: Changes since v1: - Further standardize the yaml file. - Dts naming convention improved. - Fix the problem of compiling and loading ko files. - Use drm new api to automatically manage resources. - Drop struct vs_crtc_funcs&vs_plane_funcs��subdivide the plane's help interface - Reduce the modifiers unused. - Optimize the hdmi driver code V2: Changes since v2: - fix the error about checking the yaml file. - match drm driver GEM DMA API. - Delete the custom crtc property . - hdmi use drmm_ new api to automatically manage resources. - update the modifiers comments. - enabling KASAN, fix the error during removing module Keith Zhao (6): dt-bindings: display: Add yamls for JH7110 display system riscv: dts: starfive: jh7110: add dc controller and hdmi node drm/fourcc: Add drm/vs tiled modifiers drm/vs: Register DRM device drm/vs: Add KMS crtc&plane drm/vs: Add hdmi driver .../starfive/starfive,display-subsystem.yaml | 41 + .../starfive/starfive,jh7110-dc8200.yaml | 109 + .../starfive/starfive,jh7110-inno-hdmi.yaml | 85 + MAINTAINERS | 7 + .../jh7110-starfive-visionfive-2.dtsi | 91 + arch/riscv/boot/dts/starfive/jh7110.dtsi | 41 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/verisilicon/Kconfig | 21 + drivers/gpu/drm/verisilicon/Makefile | 12 + drivers/gpu/drm/verisilicon/starfive_hdmi.c | 949 ++++++++ drivers/gpu/drm/verisilicon/starfive_hdmi.h | 295 +++ drivers/gpu/drm/verisilicon/vs_crtc.c | 257 +++ drivers/gpu/drm/verisilicon/vs_crtc.h | 43 + drivers/gpu/drm/verisilicon/vs_dc.c | 1002 +++++++++ drivers/gpu/drm/verisilicon/vs_dc.h | 80 + drivers/gpu/drm/verisilicon/vs_dc_hw.c | 1959 +++++++++++++++++ drivers/gpu/drm/verisilicon/vs_dc_hw.h | 492 +++++ drivers/gpu/drm/verisilicon/vs_drv.c | 234 ++ drivers/gpu/drm/verisilicon/vs_drv.h | 31 + drivers/gpu/drm/verisilicon/vs_modeset.c | 36 + drivers/gpu/drm/verisilicon/vs_modeset.h | 10 + drivers/gpu/drm/verisilicon/vs_plane.c | 526 +++++ drivers/gpu/drm/verisilicon/vs_plane.h | 58 + drivers/gpu/drm/verisilicon/vs_type.h | 69 + include/uapi/drm/drm_fourcc.h | 57 + include/uapi/drm/vs_drm.h | 50 + 27 files changed, 6558 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml create mode 100644 Documentation/devicetree/bindings/display/starfive/starfive,jh7110-inno-hdmi.yaml create mode 100644 drivers/gpu/drm/verisilicon/Kconfig create mode 100644 drivers/gpu/drm/verisilicon/Makefile create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.c create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.h create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h create mode 100644 include/uapi/drm/vs_drm.h -- 2.34.1

10 months, 3 weeks

Re: [PATCH v4] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

On Fri, Nov 24, 2023 at 11:15:12AM +0100, Marco Pagani wrote: > > > On 2023-11-24 09:49, Maxime Ripard wrote: > > Hi, > > > > On Thu, Nov 23, 2023 at 11:01:46AM +0100, Marco Pagani wrote: > >> +static int drm_gem_shmem_test_init(struct kunit *test) > >> +{ > >> + struct device *dev; > >> + struct fake_dev { > >> + struct drm_device drm_dev; > >> + } *fdev; > >> + > > > > [...] > > > >> + > >> + /* > >> + * The DRM core will automatically initialize the GEM core and create > >> + * a DRM Memory Manager object which provides an address space pool > >> + * for GEM objects allocation. > >> + */ > >> + fdev = drm_kunit_helper_alloc_drm_device(test, dev, struct fake_dev, > >> + drm_dev, DRIVER_GEM); > >> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fdev); > > > > Sorry I missed it earlier, but you don't need the intermediate structure > > if you use > > > > struct drm_device *drm; > > > > drm = __drm_kunit_helper_alloc_drm_device(test, dev, sizeof(*drm), 0, DRIVER_GEM); > > KUNIT_ASSERT_NOT_ERR_OR_NULL(test, drm); > > > > I prefer to use drm_kunit_helper_alloc_drm_device() with the intermediate > structure. It makes the code clearer, in my opinion. Initially, when > developing the suite, I was using __drm_kunit_helper_alloc_drm_device() > as most test suites do, but I feel the list of arguments including > "sizeof(*drm), 0," is less straightforward to understand. Then we can create an init helper, and you can allocate the drm_device through drmm_kzalloc, but I'd like tests to use consistent constructs. This can of course be made as a later patch: you use the same construct the other tests do here, and later we work on the init function and convert all tests to use it. Maxime

10 months, 3 weeks

[PATCH] dma-buf: fix check in dma_resv_add_fence

by Christian König

It's valid to add the same fence multiple times to a dma-resv object and we shouldn't need one extra slot for each. Signed-off-by: Christian König <christian.koenig(a)amd.com> Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really later") Cc: stable(a)vger.kernel.org # v5.19+ --- drivers/dma-buf/dma-resv.c | 2 +- include/linux/dma-fence.h | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 38b4110378de..eb8b733065b2 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -301,7 +301,7 @@ void dma_resv_add_fence(struct dma_resv *obj, struct dma_fence *fence, dma_resv_list_entry(fobj, i, obj, &old, &old_usage); if ((old->context == fence->context && old_usage >= usage && - dma_fence_is_later(fence, old)) || + dma_fence_is_later_or_same(fence, old)) || dma_fence_is_signaled(old)) { dma_resv_list_set(fobj, i, fence, usage); dma_fence_put(old); diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index ebe78bd3d121..b3772edca2e6 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -498,6 +498,21 @@ static inline bool dma_fence_is_later(struct dma_fence *f1, return __dma_fence_is_later(f1->seqno, f2->seqno, f1->ops); } +/** + * dma_fence_is_later_or_same - return true if f1 is later or same as f2 + * @f1: the first fence from the same context + * @f2: the second fence from the same context + * + * Returns true if f1 is chronologically later than f2 or the same fence. Both + * fences must be from the same context, since a seqno is not re-used across + * contexts. + */ +static inline bool dma_fence_is_later_or_same(struct dma_fence *f1, + struct dma_fence *f2) +{ + return f1 == f2 || dma_fence_is_later(f1, f2); +} + /** * dma_fence_later - return the chronologically later fence * @f1: the first fence from the same context -- 2.34.1

10 months, 3 weeks

Re: [PATCH v4] drm/test: add a test suite for GEM objects backed by shmem

by Maxime Ripard

Hi, On Thu, Nov 23, 2023 at 11:01:46AM +0100, Marco Pagani wrote: > +static int drm_gem_shmem_test_init(struct kunit *test) > +{ > + struct device *dev; > + struct fake_dev { > + struct drm_device drm_dev; > + } *fdev; > + [...] > + > + /* > + * The DRM core will automatically initialize the GEM core and create > + * a DRM Memory Manager object which provides an address space pool > + * for GEM objects allocation. > + */ > + fdev = drm_kunit_helper_alloc_drm_device(test, dev, struct fake_dev, > + drm_dev, DRIVER_GEM); > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fdev); Sorry I missed it earlier, but you don't need the intermediate structure if you use struct drm_device *drm; drm = __drm_kunit_helper_alloc_drm_device(test, dev, sizeof(*drm), 0, DRIVER_GEM); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, drm); Maxime

10 months, 4 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig November 2023