Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

6 participants
2911 discussions

Re: [PATCH 07/11] drm/mediatek: Rename files "mtk_drm_ddp_comp.*" to "mtk_ddp_comp.*"

by AngeloGioacchino Del Regno

Il 26/02/24 09:50, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_ddp_comp.* to mtk_ddp_comp.*. > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>

1 year, 4 months

Re: [PATCH 08/11] drm/mediatek: Rename files "mtk_drm_plane.*" to "mtk_plane.*"

by AngeloGioacchino Del Regno

Il 26/02/24 09:50, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_plane.* to mtk_plane.*. > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>

1 year, 4 months

Re: [PATCH 09/11] drm/mediatek: Rename files "mtk_drm_gem.*" to "mtk_gem.*"

by AngeloGioacchino Del Regno

Il 26/02/24 09:50, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_gem.* to mtk_gem.*. > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>

1 year, 4 months

Re: [PATCH 10/11] drm/mediatek: Rename mtk_ddp_comp functions

by AngeloGioacchino Del Regno

Il 26/02/24 09:50, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename functions of mtk_ddp_comp: > - To align the naming rule > - To reduce the code size > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGiaocchino Del Regno <angelogioacchino.delregno(a)collabora.com>

1 year, 4 months

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

by Guenter Roeck

On Thu, Feb 22, 2024 at 05:33:48PM +0100, Marco Pagani wrote: > > > > In this context, the TTM unit tests fail as well in qemu, with worse result: > > It seems there is some bad cleanup after a failed test case, causing list > > corruptions in the drm core and ultimately a crash. I don't know if this > > is also caused by the missing dma_mask initialization. > > > > That's interesting. Which --arch argument are you using to run the > tests with QEMU? Example (I am not sure if any of those parameters matters; it is just one of my tests): qemu-system-x86_64 -kernel arch/x86/boot/bzImage -M q35 -cpu IvyBridge \ -no-reboot -snapshot -smp 2 \ -device e1000,netdev=net0 -netdev user,id=net0 -m 512 \ -drive file=rootfs.ext2,format=raw,if=ide \ --append "earlycon=uart8250,io,0x3f8,9600n8 root=/dev/sda1 console=ttyS0" \ -d unimp,guest_errors -nographic -monitor none This results in: [ ... ] [ 5.989496] KTAP version 1 [ 5.989639] # Subtest: ttm_device [ 5.989711] # module: ttm_device_test [ 5.989760] 1..5 [ 6.002044] ok 1 ttm_device_init_basic [ 6.013557] ok 2 ttm_device_init_multiple ILLOPC: ffffffffb8ac9350: 0f 0b [ 6.022481] ok 3 ttm_device_fini_basic [ 6.026172] ------------[ cut here ]------------ [ 6.026315] WARNING: CPU: 1 PID: 1575 at drivers/gpu/drm/ttm/ttm_device.c:206 ttm_device_init+0x170/0x190 ... [ 6.135016] ok 3 Above the allocation limit [ 6.138759] ------------[ cut here ]------------ [ 6.138925] WARNING: CPU: 1 PID: 1595 at kernel/dma/mapping.c:503 dma_alloc_attrs+0xf6/0x100 ... [ 6.143850] # ttm_pool_alloc_basic: ASSERTION FAILED at drivers/gpu/drm/ttm/tests/ttm_pool_test.c:162 [ 6.143850] Expected err == 0, but [ 6.143850] err == -12 (0xfffffffffffffff4) [ 6.148824] not ok 4 One page, with coherent DMA mappings enabled From there things go downhill. [ 6.152821] list_add corruption. prev->next should be next (ffffffffbbd53950), but was 0000000000000000. (prev=ffff8af1c38f9e20). and so on until the emulation crashes. Guenter

1 year, 4 months

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

by Guenter Roeck

Hi Marco, On 2/22/24 07:32, Marco Pagani wrote: > > > On 2024-02-18 16:49, Guenter Roeck wrote: >> Hi, >> >> On Thu, Nov 30, 2023 at 06:14:16PM +0100, Marco Pagani wrote: >>> This patch introduces an initial KUnit test suite for GEM objects >>> backed by shmem buffers. >>> >>> Suggested-by: Javier Martinez Canillas <javierm(a)redhat.com> >>> Signed-off-by: Marco Pagani <marpagan(a)redhat.com> >> >> When running this in qemu, I get lots of warnings backtraces in the drm >> core. >> >> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:327 >> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:173 >> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:385 >> WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:211 >> WARNING: CPU: 0 PID: 1345 at kernel/dma/mapping.c:194 >> WARNING: CPU: 0 PID: 1347 at drivers/gpu/drm/drm_gem_shmem_helper.c:429 >> WARNING: CPU: 0 PID: 1349 at drivers/gpu/drm/drm_gem_shmem_helper.c:445 >> >> It looks like dma_resv_assert_held() asserts each time it is executed. >> The backtrace in kernel/dma/mapping.c is triggered by >> if (WARN_ON_ONCE(!dev->dma_mask)) >> return 0; >> in __dma_map_sg_attrs(). >> >> Is this a possible problem in the test code, or can it be caused by >> some limitations or bugs in the qemu emulation ? If so, do you have any >> thoughts or ideas what those limitations / bugs might be ? > > Hi Guenter, > > Thanks for reporting this issue. As you correctly noted, the warnings appear to > be caused by the dma_mask in the mock device being uninitialized. I'll send a > patch to fix it soon. > Thanks a lot for the update. In this context, the TTM unit tests fail as well in qemu, with worse result: It seems there is some bad cleanup after a failed test case, causing list corruptions in the drm core and ultimately a crash. I don't know if this is also caused by the missing dma_mask initialization. Thanks, Guenter

1 year, 4 months

[PATCH v2] udmabuf: Fix a potential (and unlikely) access to unallocated memory

by Christophe JAILLET

If 'list_limit' is set to a very high value, 'lsize' computation could overflow if 'head.count' is big enough. In such a case, udmabuf_create() would access to memory beyond 'list'. Use memdup_array_user() which checks for overflow. While at it, include <linux/string.h>. Fixes: fbb0de795078 ("Add udmabuf misc device") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- v2: - Use memdup_array_user() [Kees Cook] - Use sizeof(*list) [Gustavo A. R. Silva] - Add include <linux/string.h> v1: https://lore.kernel.org/all/3e37f05c7593f1016f0a46de188b3357cbbd0c0b.169506… Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> --- drivers/dma-buf/udmabuf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index c40645999648..5728948ea6f2 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -11,6 +11,7 @@ #include <linux/module.h> #include <linux/shmem_fs.h> #include <linux/slab.h> +#include <linux/string.h> #include <linux/udmabuf.h> #include <linux/vmalloc.h> #include <linux/iosys-map.h> @@ -314,14 +315,13 @@ static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) struct udmabuf_create_list head; struct udmabuf_create_item *list; int ret = -EINVAL; - u32 lsize; if (copy_from_user(&head, (void __user *)arg, sizeof(head))) return -EFAULT; if (head.count > list_limit) return -EINVAL; - lsize = sizeof(struct udmabuf_create_item) * head.count; - list = memdup_user((void __user *)(arg + sizeof(head)), lsize); + list = memdup_array_user((void __user *)(arg + sizeof(head)), + sizeof(*list), head.count); if (IS_ERR(list)) return PTR_ERR(list); -- 2.43.2

1 year, 4 months

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

by Guenter Roeck

Hi, On Thu, Nov 30, 2023 at 06:14:16PM +0100, Marco Pagani wrote: > This patch introduces an initial KUnit test suite for GEM objects > backed by shmem buffers. > > Suggested-by: Javier Martinez Canillas <javierm(a)redhat.com> > Signed-off-by: Marco Pagani <marpagan(a)redhat.com> When running this in qemu, I get lots of warnings backtraces in the drm core. WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:327 WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:173 WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:385 WARNING: CPU: 0 PID: 1341 at drivers/gpu/drm/drm_gem_shmem_helper.c:211 WARNING: CPU: 0 PID: 1345 at kernel/dma/mapping.c:194 WARNING: CPU: 0 PID: 1347 at drivers/gpu/drm/drm_gem_shmem_helper.c:429 WARNING: CPU: 0 PID: 1349 at drivers/gpu/drm/drm_gem_shmem_helper.c:445 It looks like dma_resv_assert_held() asserts each time it is executed. The backtrace in kernel/dma/mapping.c is triggered by if (WARN_ON_ONCE(!dev->dma_mask)) return 0; in __dma_map_sg_attrs(). Is this a possible problem in the test code, or can it be caused by some limitations or bugs in the qemu emulation ? If so, do you have any thoughts or ideas what those limitations / bugs might be ? Thanks, Guenter

1 year, 4 months

[PATCH] dma-buf: try to catch swiotlb bounce buffers

by Daniel Vetter

They rather fundamentally break the entire concept of zero copy, so if an exporter manages to hand these out things will break all over. Luckily there's not too many case that use swiotlb_sync_single_for_device/cpu(): - The generic iommu dma-api code in drivers/iommu/dma-iommu.c. We can catch that with sg_dma_is_swiotlb() reliably. - The generic direct dma code in kernel/dma/direct.c. We can mostly catch that with looking for a NULL dma_ops, except for some powerpc special cases. - Xen, which I don't bother to catch here. Implement these checks in dma_buf_map_attachment when CONFIG_DMA_API_DEBUG is enabled. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> 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 Cc: Paul Cercueil <paul(a)crapouillou.net> --- Entirely untested, but since I sent the mail with the idea I figured I might as well type it up after I realized there's a lot fewer cases to check. That is, if I haven't completely misread the dma-api and swiotlb code. -Sima --- drivers/dma-buf/dma-buf.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d1e7f823fbdb..d6f95523f995 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -28,6 +28,12 @@ #include <linux/mount.h> #include <linux/pseudo_fs.h> +#ifdef CONFIG_DMA_API_DEBUG +#include <linux/dma-direct.h> +#include <linux/dma-map-ops.h> +#include <linux/swiotlb.h> +#endif + #include <uapi/linux/dma-buf.h> #include <uapi/linux/magic.h> @@ -1149,10 +1155,13 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, #ifdef CONFIG_DMA_API_DEBUG if (!IS_ERR(sg_table)) { struct scatterlist *sg; + struct device *dev = attach->dev; u64 addr; int len; int i; + bool is_direct_dma = !get_dma_ops(dev); + for_each_sgtable_dma_sg(sg_table, sg, i) { addr = sg_dma_address(sg); len = sg_dma_len(sg); @@ -1160,7 +1169,15 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, pr_debug("%s: addr %llx or len %x is not page aligned!\n", __func__, addr, len); } + + if (is_direct_dma) { + phys_addr_t paddr = dma_to_phys(dev, addr); + + WARN_ON_ONCE(is_swiotlb_buffer(dev, paddr)); + } } + + WARN_ON_ONCE(sg_dma_is_swiotlb(sg)); } #endif /* CONFIG_DMA_API_DEBUG */ return sg_table; -- 2.43.0

1 year, 4 months

[PATCH v5 0/6] usb: gadget: functionfs: DMABUF import interface

by Paul Cercueil

Hi, This is the v5 of my patchset that adds a new DMABUF import interface to FunctionFS. Daniel / Sima suggested that I should cache the dma_buf_attachment while the DMABUF is attached to the interface, instead of mapping/unmapping the DMABUF for every transfer (also because unmapping is not possible in the dma_fence's critical section). This meant having to add new dma_buf_begin_access() / dma_buf_end_access() functions that the driver can call to ensure cache coherency. These two functions are provided by the new patch [1/6], and an implementation for udmabuf was added in [2/6] - see the changelog below. This patchset was successfully tested with CONFIG_LOCKDEP, no errors were reported in dmesg while using the interface. This interface is being used at Analog Devices, to transfer data from high-speed transceivers to USB in a zero-copy fashion, using also the DMABUF import interface to the IIO subsystem which is being upstreamed in parallel [1]. The two are used by the Libiio software [2]. On a ZCU102 board with a FMComms3 daughter board, using the combination of these two new interfaces yields a drastic improvement of the throughput, from about 127 MiB/s using IIO's buffer read/write interface + read/write to the FunctionFS endpoints, to about 274 MiB/s when passing around DMABUFs, for a lower CPU usage (0.85 load avg. before, vs. 0.65 after). Right now, *technically* there are no users of this interface, as Analog Devices wants to wait until both interfaces are accepted upstream to merge the DMABUF code in Libiio into the main branch, and Jonathan wants to wait and see if this patchset is accepted to greenlight the DMABUF interface in IIO as well. I think this isn't really a problem; once everybody is happy with its part of the cake, we can merge them all at once. This is obviously for 5.9, and based on next-20240119. Changelog: - [1/6]: New patch - [2/6]: New patch - [5/6]: - Cache the dma_buf_attachment while the DMABUF is attached. - Use dma_buf_begin/end_access() to ensure that the DMABUF data will be coherent to the hardware. - Remove comment about cache-management and dma_buf_unmap_attachment(), since we now use dma_buf_begin/end_access(). - Select DMA_SHARED_BUFFER in Kconfig entry - Add Christian's ACK Cheers, -Paul [1] https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.… [2] https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api Paul Cercueil (6): dma-buf: Add dma_buf_{begin,end}_access() dma-buf: udmabuf: Implement .{begin,end}_access usb: gadget: Support already-mapped DMA SGs usb: gadget: functionfs: Factorize wait-for-endpoint code usb: gadget: functionfs: Add DMABUF import interface Documentation: usb: Document FunctionFS DMABUF API Documentation/usb/functionfs.rst | 36 ++ drivers/dma-buf/dma-buf.c | 66 ++++ drivers/dma-buf/udmabuf.c | 27 ++ drivers/usb/gadget/Kconfig | 1 + drivers/usb/gadget/function/f_fs.c | 502 ++++++++++++++++++++++++++-- drivers/usb/gadget/udc/core.c | 7 +- include/linux/dma-buf.h | 37 ++ include/linux/usb/gadget.h | 2 + include/uapi/linux/usb/functionfs.h | 41 +++ 9 files changed, 698 insertions(+), 21 deletions(-) -- 2.43.0

1 year, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig