Linaro-mm-sig December 2023

linaro-mm-sig@lists.linaro.org

16 participants
12 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

[PATCH v3 00/11] Add mediate-drm secure flow for SVP

by Jason-JH.Lin

From: Jason-jh Lin <jason-jh.lin(a)mediatek.corp-partner.google.com> Memory Definitions: secure memory - Memory allocated in the TEE (Trusted Execution Environment) which is inaccessible in the REE (Rich Execution Environment, i.e. linux kernel/userspace). secure handle - Integer value which acts as reference to 'secure memory'. Used in communication between TEE and REE to reference 'secure memory'. secure buffer - 'secure memory' that is used to store decrypted, compressed video or for other general purposes in the TEE. secure surface - 'secure memory' that is used to store graphic buffers. Memory Usage in SVP: The overall flow of SVP starts with encrypted video coming in from an outside source into the REE. The REE will then allocate a 'secure buffer' and send the corresponding 'secure handle' along with the encrypted, compressed video data to the TEE. The TEE will then decrypt the video and store the result in the 'secure buffer'. The REE will then allocate a 'secure surface'. The REE will pass the 'secure handles' for both the 'secure buffer' and 'secure surface' into the TEE for video decoding. The video decoder HW will then decode the contents of the 'secure buffer' and place the result in the 'secure surface'. The REE will then attach the 'secure surface' to the overlay plane for rendering of the video. Everything relating to ensuring security of the actual contents of the 'secure buffer' and 'secure surface' is out of scope for the REE and is the responsibility of the TEE. DRM driver handles allocation of gem objects that are backed by a 'secure surface' and for displaying a 'secure surface' on the overlay plane. This introduces a new flag for object creation called DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure surface'. All changes here are in MediaTek specific code. --- TODO: 1) Remove get sec larb port interface in ddp_comp, ovl and ovl_adaptor. 2) Verify instruction for enabling/disabling dapc and larb port in TEE drop the sec_engine flags in normal world and. 3) Move DISP_REG_OVL_SECURE setting to secure world for mtk_disp_ovl.c. 4) Change the parameter register address in mtk_ddp_sec_write() from "u32 addr" to "struct cmdq_client_reg *cmdq_reg". 5) Implement setting mmsys routing table in the secure world series. --- Based on 5 series and 1 patch: [1] v3 dma-buf: heaps: Add MediaTek secure heap - https://patchwork.kernel.org/project/linux-mediatek/list/?series=809023 [2] v3 add driver to support secure video decoder - https://patchwork.kernel.org/project/linux-mediatek/list/?series=807308 [3] v4 soc: mediatek: Add register definitions for GCE - https://patchwork.kernel.org/project/linux-mediatek/patch/20231212121957.19… [4] v2 Add CMDQ driver support for mt8188 - https://patchwork.kernel.org/project/linux-mediatek/list/?series=810302 [5] Add mediatek,gce-events definition to mediatek,gce-mailbox bindings - https://patchwork.kernel.org/project/linux-mediatek/list/?series=810938 [6] v3 Add CMDQ secure driver for SVP - https://patchwork.kernel.org/project/linux-mediatek/list/?series=812379 --- Change in v3: 1. fix kerneldoc problems 2. fix typo in title and commit message 3. adjust naming for secure variable 4. add the missing part for is_suecure plane implementation 5. use BIT_ULL macro to replace bit shifting 6. move modification of ovl_adaptor part to the correct patch 7. add TODO list in commit message 8. add commit message for using share memory to store execute count Change in v2: 1. remove the DRIVER_RDNDER flag for mtk_drm_ioctl 2. move cmdq_insert_backup_cookie into client driver 3. move secure gce node define from mt8195-cherry.dtsi to mt8195.dtsi --- CK Hu (1): drm/mediatek: Add interface to allocate MediaTek GEM buffer. Jason-JH.Lin (10): drm/mediatek/uapi: Add DRM_MTK_GEM_CREATE_ENCRYPTED flag drm/mediatek: Add secure buffer control flow to mtk_drm_gem drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane drm/mediatek: Add mtk_ddp_sec_write to config secure buffer info drm/mediatek: Add get_sec_port interface to mtk_ddp_comp drm/mediatek: Add secure layer config support for ovl drm/mediatek: Add secure layer config support for ovl_adaptor drm/mediatek: Add secure flow support to mediatek-drm drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt finalize arm64: dts: mt8195: Add secure mbox settings for vdosys arch/arm64/boot/dts/mediatek/mt8195.dtsi | 6 +- drivers/gpu/drm/mediatek/mtk_disp_drv.h | 3 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 31 +- .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 15 + drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 274 +++++++++++++++++- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 30 ++ drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 14 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 13 + drivers/gpu/drm/mediatek/mtk_drm_gem.c | 122 ++++++++ drivers/gpu/drm/mediatek/mtk_drm_gem.h | 16 + drivers/gpu/drm/mediatek/mtk_drm_plane.c | 26 ++ drivers/gpu/drm/mediatek/mtk_drm_plane.h | 2 + drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 11 +- drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 2 + include/uapi/drm/mediatek_drm.h | 59 ++++ 16 files changed, 607 insertions(+), 18 deletions(-) create mode 100644 include/uapi/drm/mediatek_drm.h -- 2.18.0

8 months, 2 weeks

[PATCH v5 0/8] iio: new DMABUF based API, v5

by Paul Cercueil

[V4 was: "iio: Add buffer write() support"][1] Hi Jonathan, This is a respin of the V3 of my patchset that introduced a new interface based on DMABUF objects [2]. The V4 was a split of the patchset, to attempt to upstream buffer write() support first. But since there is no current user upstream, it was not merged. This V5 is about doing the opposite, and contains the new DMABUF interface, without adding the buffer write() support. It can already be used with the upstream adi-axi-adc driver. In user-space, Libiio uses it to transfer back and forth blocks of samples between the hardware and the applications, without having to copy the data. On a ZCU102 with a FMComms3 daughter board, running Libiio from the pcercuei/dev-new-dmabuf-api branch [3], compiled with WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio): sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc Throughput: 116 MiB/s Same hardware, with the DMABUF API (WITH_LOCAL_DMABUF_API=ON): sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc Throughput: 475 MiB/s This benchmark only measures the speed at which the data can be fetched to iio_rwdev's internal buffers, and does not actually try to read the data (e.g. to pipe it to stdout). It shows that fetching the data is more than 4x faster using the new interface. When actually reading the data, the performance difference isn't that impressive (maybe because in case of DMABUF the data is not in cache): WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio): sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero status=progress 2446422528 bytes (2.4 GB, 2.3 GiB) copied, 22 s, 111 MB/s WITH_LOCAL_DMABUF_API=ON: sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero status=progress 2334388736 bytes (2.3 GB, 2.2 GiB) copied, 21 s, 114 MB/s One interesting thing to note is that fileio is (currently) actually faster than the DMABUF interface if you increase a lot the buffer size. My explanation is that the cache invalidation routine takes more and more time the bigger the DMABUF gets. This is because the DMABUF is backed by small-size pages, so a (e.g.) 64 MiB DMABUF is backed by up to 16 thousands pages, that have to be invalidated one by one. This can be addressed by using huge pages, but the udmabuf driver does not (yet) support creating DMABUFs backed by huge pages. Anyway, the real benefits happen when the DMABUFs are either shared between IIO devices, or between the IIO subsystem and another filesystem. In that case, the DMABUFs are simply passed around drivers, without the data being copied at any moment. We use that feature to transfer samples from our transceivers to USB, using a DMABUF interface to FunctionFS [4]. This drastically increases the throughput, to about 274 MiB/s over a USB3 link, vs. 127 MiB/s using IIO's fileio interface + write() to the FunctionFS endpoints, for a lower CPU usage (0.85 vs. 0.65 load avg.). Based on linux-next/next-20231219. Cheers, -Paul [1] https://lore.kernel.org/all/20230807112113.47157-1-paul@crapouillou.net/ [2] https://lore.kernel.org/all/20230403154800.215924-1-paul@crapouillou.net/ [3] https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api [4] https://lore.kernel.org/all/20230322092118.9213-1-paul@crapouillou.net/ --- Changelog: - [3/8]: Replace V3's dmaengine_prep_slave_dma_array() with a new dmaengine_prep_slave_dma_vec(), which uses a new 'dma_vec' struct. Note that at some point we will need to support cyclic transfers using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags" parameter to the function? - [4/8]: Implement .device_prep_slave_dma_vec() instead of V3's .device_prep_slave_dma_array(). @Vinod: this patch will cause a small conflict with my other patchset adding scatter-gather support to the axi-dmac driver. This patch adds a call to axi_dmac_alloc_desc(num_sgs), but the prototype of this function changed in my other patchset - it would have to be passed the "chan" variable. I don't know how you prefer it to be resolved. Worst case scenario (and if @Jonathan is okay with that) this one patch can be re-sent later, but it would make this patchset less "atomic". - [5/8]: - Use dev_err() instead of pr_err() - Inline to_iio_dma_fence() - Add comment to explain why we unref twice when detaching dmabuf - Remove TODO comment. It is actually safe to free the file's private data even when transfers are still pending because it won't be accessed. - Fix documentation of new fields in struct iio_buffer_access_funcs - iio_dma_resv_lock() does not need to be exported, make it static - [7/8]: - Use the new dmaengine_prep_slave_dma_vec(). - Restrict to input buffers, since output buffers are not yet supported by IIO buffers. - [8/8]: Use description lists for the documentation of the three new IOCTLs instead of abusing subsections. --- Alexandru Ardelean (1): iio: buffer-dma: split iio_dma_buffer_fileio_free() function Paul Cercueil (7): iio: buffer-dma: Get rid of outgoing queue dmaengine: Add API function dmaengine_prep_slave_dma_vec() dmaengine: dma-axi-dmac: Implement device_prep_slave_dma_vec iio: core: Add new DMABUF interface infrastructure iio: buffer-dma: Enable support for DMABUFs iio: buffer-dmaengine: Support new DMABUF based userspace API Documentation: iio: Document high-speed DMABUF based API Documentation/iio/dmabuf_api.rst | 54 +++ Documentation/iio/index.rst | 2 + drivers/dma/dma-axi-dmac.c | 40 ++ drivers/iio/buffer/industrialio-buffer-dma.c | 242 ++++++++--- .../buffer/industrialio-buffer-dmaengine.c | 52 ++- drivers/iio/industrialio-buffer.c | 402 ++++++++++++++++++ include/linux/dmaengine.h | 25 ++ include/linux/iio/buffer-dma.h | 33 +- include/linux/iio/buffer_impl.h | 26 ++ include/uapi/linux/iio/buffer.h | 22 + 10 files changed, 836 insertions(+), 62 deletions(-) create mode 100644 Documentation/iio/dmabuf_api.rst -- 2.43.0

8 months, 3 weeks

[PATCH v3 0/7] dma-buf: heaps: Add secure heap

by Yong Wu

This patchset is for secure video playback and enables other potential uses in the future. The 'secure dma-heap' will be used to allocate dma_buf objects that reference memory in the secure world that is inaccessible/ unmappable by the non-secure (i.e.kernel/userspace) world. That memory will be used by the secure world to store secure information (i.e. decrypted media content). The dma_bufs allocated from the kernel will be passed to V4L2 for video decoding (as input and output). They will also be used by the drm system for rendering of the content. This patchset adds two secure heaps and they will be used v4l2[1] and drm[2]. 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path). The buffer is reserved for the secure world after bootup and it is used for vcodec's ES/working buffer; 2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is dynamically reserved for the secure world and will be got when we start playing secure videos, Once the security video playing is complete, the CMA will be released. This heap is used for the vcodec's frame buffer. [1] https://lore.kernel.org/linux-mediatek/20231206081538.17056-1-yunfei.dong@m… [2] https://lore.kernel.org/linux-mediatek/20231023044549.21412-1-jason-jh.lin@… Change note: v3: Base on v6.7-rc1. 1) Separate the secure heap into a common file(secure_heap.c) and a mtk special file (secure_heap_mtk.c), and put all tee related code into our special file. 2) About dt-binding, a) Add "mediatek," prefix since this is Mediatek TEE firmware definition. b) Mute dt-binding check waring. 3) Remove the normal CMA heap which is a draft for qcom. v2: https://lore.kernel.org/linux-mediatek/20231111111559.8218-1-yong.wu@mediat… 1) Move John's patches into the vcodec patchset since they use the new dma heap interface directly. https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.dong@m… 2) Reword the dt-binding description. 3) Rename the heap name from mtk_svp to secure_mtk_cm. This means the current vcodec/DRM upstream code doesn't match this. 4) Add a normal CMA heap. currently it should be a draft version. 5) Regarding the UUID, I still use hard code, but put it in a private data which allow the others could set their own UUID. What's more, UUID is necessary for the session with TEE. If we don't have it, we can't communicate with the TEE, including the get_uuid interface, which tries to make uuid more generic, not working. If there is other way to make UUID more general, please free to tell me. v1: https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu@media… Base on v6.6-rc1. Yong Wu (7): dt-bindings: reserved-memory: Add mediatek,dynamic-secure-region dma-buf: heaps: Initialize a secure heap dma-buf: heaps: secure_heap: Add private heap ops dma-buf: heaps: secure_heap: Add dma_ops dma-buf: heaps: secure_heap: Add MediaTek secure heap and heap_init dma-buf: heaps: secure_heap_mtk: Add tee memory service call dma_buf: heaps: secure_heap_mtk: Add a new CMA heap .../mediatek,dynamic-secure-region.yaml | 43 +++ drivers/dma-buf/heaps/Kconfig | 13 + drivers/dma-buf/heaps/Makefile | 2 + drivers/dma-buf/heaps/secure_heap.c | 234 +++++++++++++ drivers/dma-buf/heaps/secure_heap.h | 43 +++ drivers/dma-buf/heaps/secure_heap_mtk.c | 321 ++++++++++++++++++ 6 files changed, 656 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml create mode 100644 drivers/dma-buf/heaps/secure_heap.c create mode 100644 drivers/dma-buf/heaps/secure_heap.h create mode 100644 drivers/dma-buf/heaps/secure_heap_mtk.c -- 2.18.0

9 months, 1 week

[PATCH] drm/scheduler: Unwrap job dependencies

by Rob Clark

10 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

Re: [PATCH] media: medkatek: vcodec: support tee decoder

by kernel test robot

Hi Yunfei, kernel test robot noticed the following build errors: [auto build test ERROR on media-tree/master] [also build test ERROR on linus/master v6.7-rc4 next-20231206] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Yunfei-Dong/media-medkatek-v… base: git://linuxtv.org/media_tree.git master patch link: https://lore.kernel.org/r/20231206081538.17056-21-yunfei.dong%40mediatek.com patch subject: [PATCH] media: medkatek: vcodec: support tee decoder config: powerpc-allmodconfig (https://download.01.org/0day-ci/archive/20231207/202312070723.APrpMLj9-lkp@…) compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231207/202312070723.APrpMLj9-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202312070723.APrpMLj9-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:313:11: error: no member named 'is_secure_playback' in 'struct mtk_vcodec_dec_ctx' 313 | if (ctx->is_secure_playback) | ~~~ ^ >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:3: error: call to undeclared function 'mtk_vcodec_dec_optee_release'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 314 | mtk_vcodec_dec_optee_release(dev->optee_private); | ^ drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:3: note: did you mean 'mtk_vcodec_dec_release'? drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.h:88:6: note: 'mtk_vcodec_dec_release' declared here 88 | void mtk_vcodec_dec_release(struct mtk_vcodec_dec_ctx *ctx); | ^ >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:37: error: no member named 'optee_private' in 'struct mtk_vcodec_dec_dev' 314 | mtk_vcodec_dec_optee_release(dev->optee_private); | ~~~ ^ >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:472:8: error: call to undeclared function 'mtk_vcodec_dec_optee_private_init'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 472 | ret = mtk_vcodec_dec_optee_private_init(dev); | ^ drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:472:8: note: did you mean 'mtk_vcodec_dec_queue_init'? drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.h:85:5: note: 'mtk_vcodec_dec_queue_init' declared here 85 | int mtk_vcodec_dec_queue_init(void *priv, struct vb2_queue *src_vq, | ^ 4 errors generated. vim +313 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c 291 292 static int fops_vcodec_release(struct file *file) 293 { 294 struct mtk_vcodec_dec_dev *dev = video_drvdata(file); 295 struct mtk_vcodec_dec_ctx *ctx = fh_to_dec_ctx(file->private_data); 296 297 mtk_v4l2_vdec_dbg(0, ctx, "[%d] decoder", ctx->id); 298 mutex_lock(&dev->dev_mutex); 299 300 /* 301 * Call v4l2_m2m_ctx_release before mtk_vcodec_dec_release. First, it 302 * makes sure the worker thread is not running after vdec_if_deinit. 303 * Second, the decoder will be flushed and all the buffers will be 304 * returned in stop_streaming. 305 */ 306 v4l2_m2m_ctx_release(ctx->m2m_ctx); 307 mtk_vcodec_dec_release(ctx); 308 309 v4l2_fh_del(&ctx->fh); 310 v4l2_fh_exit(&ctx->fh); 311 v4l2_ctrl_handler_free(&ctx->ctrl_hdl); 312 > 313 if (ctx->is_secure_playback) > 314 mtk_vcodec_dec_optee_release(dev->optee_private); 315 316 mtk_vcodec_dbgfs_remove(dev, ctx->id); 317 list_del_init(&ctx->list); 318 kfree(ctx); 319 mutex_unlock(&dev->dev_mutex); 320 return 0; 321 } 322 323 static const struct v4l2_file_operations mtk_vcodec_fops = { 324 .owner = THIS_MODULE, 325 .open = fops_vcodec_open, 326 .release = fops_vcodec_release, 327 .poll = v4l2_m2m_fop_poll, 328 .unlocked_ioctl = video_ioctl2, 329 .mmap = v4l2_m2m_fop_mmap, 330 }; 331 332 static void mtk_vcodec_dec_get_chip_name(struct mtk_vcodec_dec_dev *vdec_dev) 333 { 334 struct device *dev = &vdec_dev->plat_dev->dev; 335 336 if (of_device_is_compatible(dev->of_node, "mediatek,mt8173-vcodec-dec")) 337 vdec_dev->chip_name = MTK_VDEC_MT8173; 338 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8183-vcodec-dec")) 339 vdec_dev->chip_name = MTK_VDEC_MT8183; 340 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-dec")) 341 vdec_dev->chip_name = MTK_VDEC_MT8192; 342 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-dec")) 343 vdec_dev->chip_name = MTK_VDEC_MT8195; 344 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8186-vcodec-dec")) 345 vdec_dev->chip_name = MTK_VDEC_MT8186; 346 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8188-vcodec-dec")) 347 vdec_dev->chip_name = MTK_VDEC_MT8188; 348 else 349 vdec_dev->chip_name = MTK_VDEC_INVAL; 350 } 351 352 static int mtk_vcodec_probe(struct platform_device *pdev) 353 { 354 struct mtk_vcodec_dec_dev *dev; 355 struct video_device *vfd_dec; 356 phandle rproc_phandle; 357 enum mtk_vcodec_fw_type fw_type; 358 int i, ret; 359 360 dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); 361 if (!dev) 362 return -ENOMEM; 363 364 INIT_LIST_HEAD(&dev->ctx_list); 365 dev->plat_dev = pdev; 366 367 mtk_vcodec_dec_get_chip_name(dev); 368 if (dev->chip_name == MTK_VDEC_INVAL) { 369 dev_err(&pdev->dev, "Failed to get decoder chip name"); 370 return -EINVAL; 371 } 372 373 dev->vdec_pdata = of_device_get_match_data(&pdev->dev); 374 if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vpu", 375 &rproc_phandle)) { 376 fw_type = VPU; 377 } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp", 378 &rproc_phandle)) { 379 fw_type = SCP; 380 } else { 381 dev_dbg(&pdev->dev, "Could not get vdec IPI device"); 382 return -ENODEV; 383 } 384 dma_set_max_seg_size(&pdev->dev, UINT_MAX); 385 386 dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, DECODER); 387 if (IS_ERR(dev->fw_handler)) 388 return PTR_ERR(dev->fw_handler); 389 390 ret = mtk_vcodec_init_dec_resources(dev); 391 if (ret) { 392 dev_err(&pdev->dev, "Failed to init dec resources"); 393 goto err_dec_pm; 394 } 395 396 if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) { 397 dev->core_workqueue = 398 alloc_ordered_workqueue("core-decoder", 399 WQ_MEM_RECLAIM | WQ_FREEZABLE); 400 if (!dev->core_workqueue) { 401 dev_dbg(&pdev->dev, "Failed to create core workqueue"); 402 ret = -EINVAL; 403 goto err_res; 404 } 405 } 406 407 for (i = 0; i < MTK_VDEC_HW_MAX; i++) 408 mutex_init(&dev->dec_mutex[i]); 409 mutex_init(&dev->dev_mutex); 410 spin_lock_init(&dev->irqlock); 411 412 snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name), "%s", 413 "[/MTK_V4L2_VDEC]"); 414 415 ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev); 416 if (ret) { 417 dev_err(&pdev->dev, "v4l2_device_register err=%d", ret); 418 goto err_core_workq; 419 } 420 421 vfd_dec = video_device_alloc(); 422 if (!vfd_dec) { 423 dev_err(&pdev->dev, "Failed to allocate video device"); 424 ret = -ENOMEM; 425 goto err_dec_alloc; 426 } 427 vfd_dec->fops = &mtk_vcodec_fops; 428 vfd_dec->ioctl_ops = &mtk_vdec_ioctl_ops; 429 vfd_dec->release = video_device_release; 430 vfd_dec->lock = &dev->dev_mutex; 431 vfd_dec->v4l2_dev = &dev->v4l2_dev; 432 vfd_dec->vfl_dir = VFL_DIR_M2M; 433 vfd_dec->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | 434 V4L2_CAP_STREAMING; 435 436 snprintf(vfd_dec->name, sizeof(vfd_dec->name), "%s", 437 MTK_VCODEC_DEC_NAME); 438 video_set_drvdata(vfd_dec, dev); 439 dev->vfd_dec = vfd_dec; 440 platform_set_drvdata(pdev, dev); 441 442 dev->m2m_dev_dec = v4l2_m2m_init(&mtk_vdec_m2m_ops); 443 if (IS_ERR((__force void *)dev->m2m_dev_dec)) { 444 dev_err(&pdev->dev, "Failed to init mem2mem dec device"); 445 ret = PTR_ERR((__force void *)dev->m2m_dev_dec); 446 goto err_dec_alloc; 447 } 448 449 dev->decode_workqueue = 450 alloc_ordered_workqueue(MTK_VCODEC_DEC_NAME, 451 WQ_MEM_RECLAIM | WQ_FREEZABLE); 452 if (!dev->decode_workqueue) { 453 dev_err(&pdev->dev, "Failed to create decode workqueue"); 454 ret = -EINVAL; 455 goto err_event_workq; 456 } 457 458 if (dev->vdec_pdata->is_subdev_supported) { 459 ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, 460 &pdev->dev); 461 if (ret) { 462 dev_err(&pdev->dev, "Main device of_platform_populate failed."); 463 goto err_reg_cont; 464 } 465 } else { 466 set_bit(MTK_VDEC_CORE, dev->subdev_bitmap); 467 } 468 469 atomic_set(&dev->dec_active_cnt, 0); 470 memset(dev->vdec_racing_info, 0, sizeof(dev->vdec_racing_info)); 471 mutex_init(&dev->dec_racing_info_mutex); > 472 ret = mtk_vcodec_dec_optee_private_init(dev); 473 if (ret) { 474 dev_err(&pdev->dev, "Failed to init svp private."); 475 goto err_reg_cont; 476 } 477 478 ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, -1); 479 if (ret) { 480 dev_err(&pdev->dev, "Failed to register video device"); 481 goto err_reg_cont; 482 } 483 484 if (dev->vdec_pdata->uses_stateless_api) { 485 v4l2_disable_ioctl(vfd_dec, VIDIOC_DECODER_CMD); 486 v4l2_disable_ioctl(vfd_dec, VIDIOC_TRY_DECODER_CMD); 487 488 dev->mdev_dec.dev = &pdev->dev; 489 strscpy(dev->mdev_dec.model, MTK_VCODEC_DEC_NAME, 490 sizeof(dev->mdev_dec.model)); 491 492 media_device_init(&dev->mdev_dec); 493 dev->mdev_dec.ops = &mtk_vcodec_media_ops; 494 dev->v4l2_dev.mdev = &dev->mdev_dec; 495 496 ret = v4l2_m2m_register_media_controller(dev->m2m_dev_dec, dev->vfd_dec, 497 MEDIA_ENT_F_PROC_VIDEO_DECODER); 498 if (ret) { 499 dev_err(&pdev->dev, "Failed to register media controller"); 500 goto err_dec_mem_init; 501 } 502 503 ret = media_device_register(&dev->mdev_dec); 504 if (ret) { 505 dev_err(&pdev->dev, "Failed to register media device"); 506 goto err_media_reg; 507 } 508 509 dev_dbg(&pdev->dev, "media registered as /dev/media%d", vfd_dec->minor); 510 } 511 512 mtk_vcodec_dbgfs_init(dev, false); 513 dev_dbg(&pdev->dev, "decoder registered as /dev/video%d", vfd_dec->minor); 514 515 return 0; 516 517 err_media_reg: 518 v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec); 519 err_dec_mem_init: 520 video_unregister_device(vfd_dec); 521 err_reg_cont: 522 if (dev->vdec_pdata->uses_stateless_api) 523 media_device_cleanup(&dev->mdev_dec); 524 destroy_workqueue(dev->decode_workqueue); 525 err_event_workq: 526 v4l2_m2m_release(dev->m2m_dev_dec); 527 err_dec_alloc: 528 v4l2_device_unregister(&dev->v4l2_dev); 529 err_core_workq: 530 if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) 531 destroy_workqueue(dev->core_workqueue); 532 err_res: 533 if (!dev->vdec_pdata->is_subdev_supported) 534 pm_runtime_disable(dev->pm.dev); 535 err_dec_pm: 536 mtk_vcodec_fw_release(dev->fw_handler); 537 return ret; 538 } 539 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

10 months, 2 weeks

Re: [PATCH] media: medkatek: vcodec: support tee decoder

by kernel test robot

Hi Yunfei, kernel test robot noticed the following build errors: [auto build test ERROR on media-tree/master] [also build test ERROR on linus/master v6.7-rc4 next-20231206] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Yunfei-Dong/media-medkatek-v… base: git://linuxtv.org/media_tree.git master patch link: https://lore.kernel.org/r/20231206081538.17056-21-yunfei.dong%40mediatek.com patch subject: [PATCH] media: medkatek: vcodec: support tee decoder config: arm64-defconfig (https://download.01.org/0day-ci/archive/20231207/202312070717.a86rODYn-lkp@…) compiler: aarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231207/202312070717.a86rODYn-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202312070717.a86rODYn-lkp@intel.com/ All errors (new ones prefixed by >>): drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c: In function 'fops_vcodec_release': >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:313:16: error: 'struct mtk_vcodec_dec_ctx' has no member named 'is_secure_playback' 313 | if (ctx->is_secure_playback) | ^~ >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:17: error: implicit declaration of function 'mtk_vcodec_dec_optee_release'; did you mean 'mtk_vcodec_dec_release'? [-Werror=implicit-function-declaration] 314 | mtk_vcodec_dec_optee_release(dev->optee_private); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | mtk_vcodec_dec_release >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:314:49: error: 'struct mtk_vcodec_dec_dev' has no member named 'optee_private' 314 | mtk_vcodec_dec_optee_release(dev->optee_private); | ^~ drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c: In function 'mtk_vcodec_probe': >> drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c:472:15: error: implicit declaration of function 'mtk_vcodec_dec_optee_private_init'; did you mean 'mtk_vcodec_dec_queue_init'? [-Werror=implicit-function-declaration] 472 | ret = mtk_vcodec_dec_optee_private_init(dev); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | mtk_vcodec_dec_queue_init cc1: some warnings being treated as errors vim +313 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c 291 292 static int fops_vcodec_release(struct file *file) 293 { 294 struct mtk_vcodec_dec_dev *dev = video_drvdata(file); 295 struct mtk_vcodec_dec_ctx *ctx = fh_to_dec_ctx(file->private_data); 296 297 mtk_v4l2_vdec_dbg(0, ctx, "[%d] decoder", ctx->id); 298 mutex_lock(&dev->dev_mutex); 299 300 /* 301 * Call v4l2_m2m_ctx_release before mtk_vcodec_dec_release. First, it 302 * makes sure the worker thread is not running after vdec_if_deinit. 303 * Second, the decoder will be flushed and all the buffers will be 304 * returned in stop_streaming. 305 */ 306 v4l2_m2m_ctx_release(ctx->m2m_ctx); 307 mtk_vcodec_dec_release(ctx); 308 309 v4l2_fh_del(&ctx->fh); 310 v4l2_fh_exit(&ctx->fh); 311 v4l2_ctrl_handler_free(&ctx->ctrl_hdl); 312 > 313 if (ctx->is_secure_playback) > 314 mtk_vcodec_dec_optee_release(dev->optee_private); 315 316 mtk_vcodec_dbgfs_remove(dev, ctx->id); 317 list_del_init(&ctx->list); 318 kfree(ctx); 319 mutex_unlock(&dev->dev_mutex); 320 return 0; 321 } 322 323 static const struct v4l2_file_operations mtk_vcodec_fops = { 324 .owner = THIS_MODULE, 325 .open = fops_vcodec_open, 326 .release = fops_vcodec_release, 327 .poll = v4l2_m2m_fop_poll, 328 .unlocked_ioctl = video_ioctl2, 329 .mmap = v4l2_m2m_fop_mmap, 330 }; 331 332 static void mtk_vcodec_dec_get_chip_name(struct mtk_vcodec_dec_dev *vdec_dev) 333 { 334 struct device *dev = &vdec_dev->plat_dev->dev; 335 336 if (of_device_is_compatible(dev->of_node, "mediatek,mt8173-vcodec-dec")) 337 vdec_dev->chip_name = MTK_VDEC_MT8173; 338 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8183-vcodec-dec")) 339 vdec_dev->chip_name = MTK_VDEC_MT8183; 340 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8192-vcodec-dec")) 341 vdec_dev->chip_name = MTK_VDEC_MT8192; 342 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8195-vcodec-dec")) 343 vdec_dev->chip_name = MTK_VDEC_MT8195; 344 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8186-vcodec-dec")) 345 vdec_dev->chip_name = MTK_VDEC_MT8186; 346 else if (of_device_is_compatible(dev->of_node, "mediatek,mt8188-vcodec-dec")) 347 vdec_dev->chip_name = MTK_VDEC_MT8188; 348 else 349 vdec_dev->chip_name = MTK_VDEC_INVAL; 350 } 351 352 static int mtk_vcodec_probe(struct platform_device *pdev) 353 { 354 struct mtk_vcodec_dec_dev *dev; 355 struct video_device *vfd_dec; 356 phandle rproc_phandle; 357 enum mtk_vcodec_fw_type fw_type; 358 int i, ret; 359 360 dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); 361 if (!dev) 362 return -ENOMEM; 363 364 INIT_LIST_HEAD(&dev->ctx_list); 365 dev->plat_dev = pdev; 366 367 mtk_vcodec_dec_get_chip_name(dev); 368 if (dev->chip_name == MTK_VDEC_INVAL) { 369 dev_err(&pdev->dev, "Failed to get decoder chip name"); 370 return -EINVAL; 371 } 372 373 dev->vdec_pdata = of_device_get_match_data(&pdev->dev); 374 if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vpu", 375 &rproc_phandle)) { 376 fw_type = VPU; 377 } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp", 378 &rproc_phandle)) { 379 fw_type = SCP; 380 } else { 381 dev_dbg(&pdev->dev, "Could not get vdec IPI device"); 382 return -ENODEV; 383 } 384 dma_set_max_seg_size(&pdev->dev, UINT_MAX); 385 386 dev->fw_handler = mtk_vcodec_fw_select(dev, fw_type, DECODER); 387 if (IS_ERR(dev->fw_handler)) 388 return PTR_ERR(dev->fw_handler); 389 390 ret = mtk_vcodec_init_dec_resources(dev); 391 if (ret) { 392 dev_err(&pdev->dev, "Failed to init dec resources"); 393 goto err_dec_pm; 394 } 395 396 if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) { 397 dev->core_workqueue = 398 alloc_ordered_workqueue("core-decoder", 399 WQ_MEM_RECLAIM | WQ_FREEZABLE); 400 if (!dev->core_workqueue) { 401 dev_dbg(&pdev->dev, "Failed to create core workqueue"); 402 ret = -EINVAL; 403 goto err_res; 404 } 405 } 406 407 for (i = 0; i < MTK_VDEC_HW_MAX; i++) 408 mutex_init(&dev->dec_mutex[i]); 409 mutex_init(&dev->dev_mutex); 410 spin_lock_init(&dev->irqlock); 411 412 snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name), "%s", 413 "[/MTK_V4L2_VDEC]"); 414 415 ret = v4l2_device_register(&pdev->dev, &dev->v4l2_dev); 416 if (ret) { 417 dev_err(&pdev->dev, "v4l2_device_register err=%d", ret); 418 goto err_core_workq; 419 } 420 421 vfd_dec = video_device_alloc(); 422 if (!vfd_dec) { 423 dev_err(&pdev->dev, "Failed to allocate video device"); 424 ret = -ENOMEM; 425 goto err_dec_alloc; 426 } 427 vfd_dec->fops = &mtk_vcodec_fops; 428 vfd_dec->ioctl_ops = &mtk_vdec_ioctl_ops; 429 vfd_dec->release = video_device_release; 430 vfd_dec->lock = &dev->dev_mutex; 431 vfd_dec->v4l2_dev = &dev->v4l2_dev; 432 vfd_dec->vfl_dir = VFL_DIR_M2M; 433 vfd_dec->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | 434 V4L2_CAP_STREAMING; 435 436 snprintf(vfd_dec->name, sizeof(vfd_dec->name), "%s", 437 MTK_VCODEC_DEC_NAME); 438 video_set_drvdata(vfd_dec, dev); 439 dev->vfd_dec = vfd_dec; 440 platform_set_drvdata(pdev, dev); 441 442 dev->m2m_dev_dec = v4l2_m2m_init(&mtk_vdec_m2m_ops); 443 if (IS_ERR((__force void *)dev->m2m_dev_dec)) { 444 dev_err(&pdev->dev, "Failed to init mem2mem dec device"); 445 ret = PTR_ERR((__force void *)dev->m2m_dev_dec); 446 goto err_dec_alloc; 447 } 448 449 dev->decode_workqueue = 450 alloc_ordered_workqueue(MTK_VCODEC_DEC_NAME, 451 WQ_MEM_RECLAIM | WQ_FREEZABLE); 452 if (!dev->decode_workqueue) { 453 dev_err(&pdev->dev, "Failed to create decode workqueue"); 454 ret = -EINVAL; 455 goto err_event_workq; 456 } 457 458 if (dev->vdec_pdata->is_subdev_supported) { 459 ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, 460 &pdev->dev); 461 if (ret) { 462 dev_err(&pdev->dev, "Main device of_platform_populate failed."); 463 goto err_reg_cont; 464 } 465 } else { 466 set_bit(MTK_VDEC_CORE, dev->subdev_bitmap); 467 } 468 469 atomic_set(&dev->dec_active_cnt, 0); 470 memset(dev->vdec_racing_info, 0, sizeof(dev->vdec_racing_info)); 471 mutex_init(&dev->dec_racing_info_mutex); > 472 ret = mtk_vcodec_dec_optee_private_init(dev); 473 if (ret) { 474 dev_err(&pdev->dev, "Failed to init svp private."); 475 goto err_reg_cont; 476 } 477 478 ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, -1); 479 if (ret) { 480 dev_err(&pdev->dev, "Failed to register video device"); 481 goto err_reg_cont; 482 } 483 484 if (dev->vdec_pdata->uses_stateless_api) { 485 v4l2_disable_ioctl(vfd_dec, VIDIOC_DECODER_CMD); 486 v4l2_disable_ioctl(vfd_dec, VIDIOC_TRY_DECODER_CMD); 487 488 dev->mdev_dec.dev = &pdev->dev; 489 strscpy(dev->mdev_dec.model, MTK_VCODEC_DEC_NAME, 490 sizeof(dev->mdev_dec.model)); 491 492 media_device_init(&dev->mdev_dec); 493 dev->mdev_dec.ops = &mtk_vcodec_media_ops; 494 dev->v4l2_dev.mdev = &dev->mdev_dec; 495 496 ret = v4l2_m2m_register_media_controller(dev->m2m_dev_dec, dev->vfd_dec, 497 MEDIA_ENT_F_PROC_VIDEO_DECODER); 498 if (ret) { 499 dev_err(&pdev->dev, "Failed to register media controller"); 500 goto err_dec_mem_init; 501 } 502 503 ret = media_device_register(&dev->mdev_dec); 504 if (ret) { 505 dev_err(&pdev->dev, "Failed to register media device"); 506 goto err_media_reg; 507 } 508 509 dev_dbg(&pdev->dev, "media registered as /dev/media%d", vfd_dec->minor); 510 } 511 512 mtk_vcodec_dbgfs_init(dev, false); 513 dev_dbg(&pdev->dev, "decoder registered as /dev/video%d", vfd_dec->minor); 514 515 return 0; 516 517 err_media_reg: 518 v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec); 519 err_dec_mem_init: 520 video_unregister_device(vfd_dec); 521 err_reg_cont: 522 if (dev->vdec_pdata->uses_stateless_api) 523 media_device_cleanup(&dev->mdev_dec); 524 destroy_workqueue(dev->decode_workqueue); 525 err_event_workq: 526 v4l2_m2m_release(dev->m2m_dev_dec); 527 err_dec_alloc: 528 v4l2_device_unregister(&dev->v4l2_dev); 529 err_core_workq: 530 if (IS_VDEC_LAT_ARCH(dev->vdec_pdata->hw_arch)) 531 destroy_workqueue(dev->core_workqueue); 532 err_res: 533 if (!dev->vdec_pdata->is_subdev_supported) 534 pm_runtime_disable(dev->pm.dev); 535 err_dec_pm: 536 mtk_vcodec_fw_release(dev->fw_handler); 537 return ret; 538 } 539 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig December 2023