- Linaro-mm-sig - lists.linaro.org

Re: [PATCH v6 02/15] net: generalise net_iov chunk owners

by Christoph Hellwig

On Tue, Oct 29, 2024 at 04:35:16PM +0000, Pavel Begunkov wrote: > I see, the reply is about your phrase about additional memory > abstractions: > > "... don't really need to build memory buffer abstraction over > memory buffer abstraction." Yes, over the exsting memory buffer abstraction (dma_buf). > If you mean internals, making up a dmabuf that has never existed in the > picture in the first place is not cleaner or easier in any way. If that > changes, e.g. there is more code to reuse in the future, we can unify it > then. I'm not sure what "making up" means here, they are all made up :) > > with pre-registering the memry with the iommu to get good performance > > in IOMMU-enabled setups. > > The page pool already does that just like it handles the normal > path without providers. In which case is basically is a dma-buf. If you'd expose it as such we could actually use to communicate between subsystems in the kernel.

1 year, 3 months

1
0
0 0

Re: [PATCH 1/3] dma-buf/dma-fence_array: use kvzalloc

by Christian König

Am 25.10.24 um 08:52 schrieb Friedrich Vock: > On 24.10.24 22:29, Matthew Brost wrote: >> On Thu, Oct 24, 2024 at 02:41:57PM +0200, Christian König wrote: >>> Reports indicates that some userspace applications try to merge more >>> than >>> 80k of fences into a single dma_fence_array leading to a warning from >> >> Really, yikes. > > Not really IME. Unless Christian means some reports I don't have access > to, the cases where userspace applications tried to do that were really > just cases where the fence count exploded exponentially because > dma_fence_unwrap_merge failed to actually merge identical fences (see > patch 2). At no point have I actually seen apps trying to merge 80k+ > unique fences. While working on it I've modified our stress test tool to send the same 1GiB SDMA copy to 100k different contexts. Turned out it's perfectly possible to create so many fences, there is nothing blocking userspace to do it. While this isn't a realistic use case the kernel should at least not crash or spill a warning, but either handle or reject it gracefully. Friedrich can you confirm that patch two in this series fixes the problem? I would really like to get it into drm-misc-fixes before 6.12 comes out. Thanks, Christian. > > Regards, > Friedrich > >> >>> kzalloc() that the requested size becomes to big. >>> >>> While that is clearly an userspace bug we should probably handle >>> that case >>> gracefully in the kernel. >>> >>> So we can either reject requests to merge more than a reasonable >>> amount of >>> fences (64k maybe?) or we can start to use kvzalloc() instead of >>> kzalloc(). >>> This patch here does the later. >>> >> >> This patch seems reasonable to me if the above use is in fact valid. >> >>> Signed-off-by: Christian König <christian.koenig(a)amd.com> >>> CC: stable(a)vger.kernel.org >> >> Fixes tag? >> >> Patch itself LGTM: >> Reviewed-by: Matthew Brost <matthew.brost(a)intel.com> >> >>> --- >>> drivers/dma-buf/dma-fence-array.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/dma-buf/dma-fence-array.c >>> b/drivers/dma-buf/dma-fence-array.c >>> index 8a08ffde31e7..46ac42bcfac0 100644 >>> --- a/drivers/dma-buf/dma-fence-array.c >>> +++ b/drivers/dma-buf/dma-fence-array.c >>> @@ -119,8 +119,8 @@ static void dma_fence_array_release(struct >>> dma_fence *fence) >>> for (i = 0; i < array->num_fences; ++i) >>> dma_fence_put(array->fences[i]); >>> >>> - kfree(array->fences); >>> - dma_fence_free(fence); >>> + kvfree(array->fences); >>> + kvfree_rcu(fence, rcu); >>> } >>> >>> static void dma_fence_array_set_deadline(struct dma_fence *fence, >>> @@ -153,7 +153,7 @@ struct dma_fence_array >>> *dma_fence_array_alloc(int num_fences) >>> { >>> struct dma_fence_array *array; >>> >>> - return kzalloc(struct_size(array, callbacks, num_fences), >>> GFP_KERNEL); >>> + return kvzalloc(struct_size(array, callbacks, num_fences), >>> GFP_KERNEL); >>> } >>> EXPORT_SYMBOL(dma_fence_array_alloc); >>> >>> -- >>> 2.34.1 >>> >

1 year, 3 months

1
0
0 0

Re: [PATCH v6 02/15] net: generalise net_iov chunk owners

by Christoph Hellwig

On Thu, Oct 24, 2024 at 05:40:02PM +0100, Pavel Begunkov wrote: > On 10/24/24 17:06, Christoph Hellwig wrote: > > On Thu, Oct 24, 2024 at 03:23:06PM +0100, Pavel Begunkov wrote: > > > > That's not what this series does. It adds the new memory_provider_ops > > > > set of hooks, with once implementation for dmabufs, and one for > > > > io_uring zero copy. > > > > > > First, it's not a _new_ abstraction over a buffer as you called it > > > before, the abstraction (net_iov) is already merged. > > > > Umm, it is a new ops vector. > > I don't understand what you mean. Callback? struct memory_provider_ops. It's a method table or ops vetor, no callbacks involved. > Then please go ahead and take a look at the patchset in question > and see how much of dmabuf handling is there comparing to pure > networking changes. The point that it's a new set of API and lots > of changes not related directly to dmabufs stand. dmabufs is useful > there as an abstraction there, but it's a very long stretch saying > that the series is all about it. I did take a look, that's why I replied. > > > on an existing network specific abstraction, which are not restricted to > > > pages or anything specific in the long run, but the flow of which from > > > net stack to user and back is controlled by io_uring. If you worry about > > > abuse, io_uring can't even sanely initialise those buffers itself and > > > therefore asking the page pool code to do that. > > > > No, I worry about trying to io_uring for not good reason. This > > It sounds that the argument is that you just don't want any > io_uring APIs, I don't think you'd be able to help you with > that. No, that's complete misinterpreting what I'm saying. Of course an io_uring API is fine. But tying low-level implementation details to to is not. > > pre-cludes in-kernel uses which would be extremly useful for > > Uses of what? devmem TCP is merged, I'm not removing it, > and the net_iov abstraction is in there, which can be potentially > be reused by other in-kernel users if that'd even make sense. How when you are hardcoding io uring memory registrations instead of making them a generic dmabuf? Which btw would also really help with pre-registering the memry with the iommu to get good performance in IOMMU-enabled setups.

1 year, 3 months

1
0
0 0

Important Message: Incoming mails have been suspended in your email server !!!

by Server Administrator lists.linaro.org

1 year, 3 months

1
0
0 0

Re: [PATCH 1/3] dma-buf/dma-fence_array: use kvzalloc

by Christian König

Am 25.10.24 um 11:05 schrieb Tvrtko Ursulin: > > On 25/10/2024 09:59, Tvrtko Ursulin wrote: >> >> On 24/10/2024 13:41, Christian König wrote: >>> Reports indicates that some userspace applications try to merge more >>> than >>> 80k of fences into a single dma_fence_array leading to a warning from >>> kzalloc() that the requested size becomes to big. >>> >>> While that is clearly an userspace bug we should probably handle >>> that case >>> gracefully in the kernel. >>> >>> So we can either reject requests to merge more than a reasonable >>> amount of >>> fences (64k maybe?) or we can start to use kvzalloc() instead of >>> kzalloc(). >>> This patch here does the later. >> >> Rejecting would potentially be safer, otherwise there is a path for >> userspace to trigger a warn in kvmalloc_node (see 0829b5bcdd3b >> ("drm/i915: 2 GiB of relocations ought to be enough for anybody*")) >> and spam dmesg at will. > > Actually that is a WARN_ON_*ONCE* there so maybe not so critical to > invent a limit. Up for discussion I suppose. > > Regards, > > Tvrtko > >> >> Question is what limit to set... That's one of the reasons why I opted for kvzalloc() initially. I mean we could use some nice round number like 65536, but that would be totally arbitrary. Any comments on the other two patches? I need to get them upstream. Thanks, Christian. >> >> Regards, >> >> Tvrtko >> >>> Signed-off-by: Christian König <christian.koenig(a)amd.com> >>> CC: stable(a)vger.kernel.org >>> --- >>> drivers/dma-buf/dma-fence-array.c | 6 +++--- >>> 1 file changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/drivers/dma-buf/dma-fence-array.c >>> b/drivers/dma-buf/dma-fence-array.c >>> index 8a08ffde31e7..46ac42bcfac0 100644 >>> --- a/drivers/dma-buf/dma-fence-array.c >>> +++ b/drivers/dma-buf/dma-fence-array.c >>> @@ -119,8 +119,8 @@ static void dma_fence_array_release(struct >>> dma_fence *fence) >>> for (i = 0; i < array->num_fences; ++i) >>> dma_fence_put(array->fences[i]); >>> - kfree(array->fences); >>> - dma_fence_free(fence); >>> + kvfree(array->fences); >>> + kvfree_rcu(fence, rcu); >>> } >>> static void dma_fence_array_set_deadline(struct dma_fence *fence, >>> @@ -153,7 +153,7 @@ struct dma_fence_array >>> *dma_fence_array_alloc(int num_fences) >>> { >>> struct dma_fence_array *array; >>> - return kzalloc(struct_size(array, callbacks, num_fences), >>> GFP_KERNEL); >>> + return kvzalloc(struct_size(array, callbacks, num_fences), >>> GFP_KERNEL); >>> } >>> EXPORT_SYMBOL(dma_fence_array_alloc);

1 year, 3 months

1
0
0 0

Re: [PATCH v6 02/15] net: generalise net_iov chunk owners

by Christoph Hellwig

On Thu, Oct 24, 2024 at 03:23:06PM +0100, Pavel Begunkov wrote: > > That's not what this series does. It adds the new memory_provider_ops > > set of hooks, with once implementation for dmabufs, and one for > > io_uring zero copy. > > First, it's not a _new_ abstraction over a buffer as you called it > before, the abstraction (net_iov) is already merged. Umm, it is a new ops vector. > Second, you mention devmem TCP, and it's not just a page pool with > "dmabufs", it's a user API to use it and other memory agnostic > allocation logic. And yes, dmabufs there is the least technically > important part. Just having a dmabuf handle solves absolutely nothing. It solves a lot, becaue it provides a proper abstraction. > > So you are precluding zero copy RX into anything but your magic > > io_uring buffers, and using an odd abstraction for that. > > Right io_uring zero copy RX API expects transfer to happen into io_uring > controlled buffers, and that's the entire idea. Buffers that are based > on an existing network specific abstraction, which are not restricted to > pages or anything specific in the long run, but the flow of which from > net stack to user and back is controlled by io_uring. If you worry about > abuse, io_uring can't even sanely initialise those buffers itself and > therefore asking the page pool code to do that. No, I worry about trying to io_uring for not good reason. This pre-cludes in-kernel uses which would be extremly useful for network storage drivers, and it precludes device memory of all kinds. > I'm even more confused how that would help. The user API has to > be implemented and adding a new dmabuf gives nothing, not even > mentioning it's not clear what semantics of that beast is > supposed to be. > The dma-buf maintainers already explained to you last time that there is absolutely no need to use the dmabuf UAPI, you can use dma-bufs through in-kernel interfaces just fine.

1 year, 3 months

1
0
0 0

Fix Fix fence merge handling

by Christian König

Hi guys, turned out that userspace can also merge dma_fence_chain contains which can result in really huge arrays. Fix those merges to sort the arrays and remove the duplicates. Additional to that start to use kvzalloc() for dma_fence_array containers so that can handle much larger arrays if necessary. Please review and comment, Christian.

1 year, 3 months

1
3
0 0

Re: [PATCH v6 02/15] net: generalise net_iov chunk owners

by Christoph Hellwig

On Wed, Oct 23, 2024 at 03:34:53PM +0100, Pavel Begunkov wrote: > It doesn't care much what kind of memory it is, nor it's important > for internals how it's imported, it's user addresses -> pages for > user convenience sake. All the net_iov setup code is in the page pool > core code. What it does, however, is implementing the user API, so That's not what this series does. It adds the new memory_provider_ops set of hooks, with once implementation for dmabufs, and one for io_uring zero copy. So you are precluding zero copy RX into anything but your magic io_uring buffers, and using an odd abstraction for that. The right way would be to support zero copy RX into every designated dmabuf, and make io_uring work with udmabuf or if absolutely needed it's own kind of dmabuf. Instead we create a maze of incompatible abstractions here. The use case of e.g. doing zero copy receive into a NVMe CMB using PCIe P2P transactions is every but made up, so this does create a problem.

1 year, 3 months

1
0
0 0

[PATCH] Documentation: dma-buf: heaps: Add heap name definitions

by Maxime Ripard

Following a recent discussion at last Plumbers, John Stultz, Sumit Sewal, TJ Mercier and I came to an agreement that we should document what the dma-buf heaps names are expected to be, and what the buffers attributes you'll get should be documented. Let's create that doc to make sure those attributes and names are guaranteed going forward. Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- To: Jonathan Corbet <corbet(a)lwn.net> To: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Benjamin Gaignard <benjamin.gaignard(a)collabora.com> Cc: Brian Starkey <Brian.Starkey(a)arm.com> Cc: John Stultz <jstultz(a)google.com> Cc: "T.J. Mercier" <tjmercier(a)google.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-media(a)vger.kernel.org Cc: linux-doc(a)vger.kernel.org --- Documentation/userspace-api/dma-buf-heaps.rst | 71 +++++++++++++++++++ Documentation/userspace-api/index.rst | 1 + 2 files changed, 72 insertions(+) create mode 100644 Documentation/userspace-api/dma-buf-heaps.rst diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst new file mode 100644 index 000000000000..00436227b542 --- /dev/null +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -0,0 +1,71 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== +Allocating dma-buf using heaps +============================== + +Dma-buf Heaps are a way for userspace to allocate dma-buf objects. They are +typically used to allocate buffers from a specific allocation pool, or to share +buffers across frameworks. + +Heaps +===== + +A heap represent a specific allocator. The Linux kernel currently supports the +following heaps: + + - The ``system`` heap allocates virtually contiguous, cacheable, buffers + + - The ``reserved`` heap allocates physically contiguous, cacheable, buffers. + Depending on the platform, it might be called differently: + + - Acer Iconia Tab A500: ``linux,cma`` + - Allwinner sun4i, sun5i and sun7i families: ``default-pool`` + - Amlogic A1: ``linux,cma`` + - Amlogic G12A/G12B/SM1: ``linux,cma`` + - Amlogic GXBB/GXL: ``linux,cma`` + - ASUS EeePad Transformer TF101: ``linux,cma`` + - ASUS Google Nexus 7 (Project Bach / ME370TG) E1565: ``linux,cma`` + - ASUS Google Nexus 7 (Project Nakasi / ME370T) E1565: ``linux,cma`` + - ASUS Google Nexus 7 (Project Nakasi / ME370T) PM269: ``linux,cma`` + - Asus Transformer Infinity TF700T: ``linux,cma`` + - Asus Transformer Pad 3G TF300TG: ``linux,cma`` + - Asus Transformer Pad TF300T: ``linux,cma`` + - Asus Transformer Pad TF701T: ``linux,cma`` + - Asus Transformer Prime TF201: ``linux,cma`` + - ASUS Vivobook S 15: ``linux,cma`` + - Cadence KC705: ``linux,cma`` + - Digi International ConnectCore 6UL: ``linux,cma`` + - Freescale i.MX8DXL EVK: ``linux,cma`` + - Freescale TQMa8Xx: ``linux,cma`` + - Hisilicon Hikey: ``linux,cma`` + - Lenovo ThinkPad T14s Gen 6: ``linux,cma`` + - Lenovo ThinkPad X13s: ``linux,cma`` + - Lenovo Yoga Slim 7x: ``linux,cma`` + - LG Optimus 4X HD P880: ``linux,cma`` + - LG Optimus Vu P895: ``linux,cma`` + - Loongson 2k0500, 2k1000 and 2k2000: ``linux,cma`` + - Microsoft Romulus: ``linux,cma`` + - NXP i.MX8ULP EVK: ``linux,cma`` + - NXP i.MX93 9x9 QSB: ``linux,cma`` + - NXP i.MX93 11X11 EVK: ``linux,cma`` + - NXP i.MX93 14X14 EVK: ``linux,cma`` + - NXP i.MX95 19X19 EVK: ``linux,cma`` + - Ouya Game Console: ``linux,cma`` + - Pegatron Chagall: ``linux,cma`` + - PHYTEC phyCORE-AM62A SOM: ``linux,cma`` + - PHYTEC phyCORE-i.MX93 SOM: ``linux,cma`` + - Qualcomm SC8280XP CRD: ``linux,cma`` + - Qualcomm X1E80100 CRD: ``linux,cma`` + - Qualcomm X1E80100 QCP: ``linux,cma`` + - RaspberryPi: ``linux,cma`` + - Texas Instruments AM62x SK board family: ``linux,cma`` + - Texas Instruments AM62A7 SK: ``linux,cma`` + - Toradex Apalis iMX8: ``linux,cma`` + - TQ-Systems i.MX8MM TQMa8MxML: ``linux,cma`` + - TQ-Systems i.MX8MN TQMa8MxNL: ``linux,cma`` + - TQ-Systems i.MX8MPlus TQMa8MPxL: ``linux,cma`` + - TQ-Systems i.MX8MQ TQMa8MQ: ``linux,cma`` + - TQ-Systems i.MX93 TQMa93xxLA/TQMa93xxCA SOM: ``linux,cma`` + - TQ-Systems MBA6ULx Baseboard: ``linux,cma`` + diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index 274cc7546efc..4901ce7c6cb7 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -41,10 +41,11 @@ Devices and I/O .. toctree:: :maxdepth: 1 accelerators/ocxl + dma-buf-heaps dma-buf-alloc-exchange gpio/index iommufd media/index dcdbas -- 2.46.1

1 year, 3 months

2
3
0 0

Re: [PATCH v6 02/15] net: generalise net_iov chunk owners

by Christoph Hellwig

On Wed, Oct 16, 2024 at 11:52:39AM -0700, David Wei wrote: > From: Pavel Begunkov <asml.silence(a)gmail.com> > > Currently net_iov stores a pointer to struct dmabuf_genpool_chunk_owner, > which serves as a useful abstraction to share data and provide a > context. However, it's too devmem specific, and we want to reuse it for > other memory providers, and for that we need to decouple net_iov from > devmem. Make net_iov to point to a new base structure called > net_iov_area, which dmabuf_genpool_chunk_owner extends. We've been there before. Instead of reinventing your own memory provider please enhance dmabufs for your use case. We don't really need to build memory buffer abstraction over memory buffer abstraction.

1 year, 3 months

1
0
0 0

Re: Requirements to merge new heaps in the kernel

by John Stultz

On Tue, Oct 22, 2024 at 1:38 AM Maxime Ripard <mripard(a)redhat.com> wrote: > > I wanted to follow-up on the discussion we had at Plumbers with John and > T.J. about (among other things) adding new heaps to the kernel. > > I'm still interested in merging a carve-out driver[1], since it seems to be > in every vendor BSP and got asked again last week. > > I remember from our discussion that for new heap types to be merged, we > needed a kernel use-case. Looking back, I'm not entirely sure how one > can provide that given that heaps are essentially facilities for > user-space. > > Am I misremembering or missing something? What are the requirements for > you to consider adding a new heap driver? It's basically the same as the DRM subsystem rules. https://docs.kernel.org/gpu/drm-uapi.html#open-source-userspace-requirements ie: There has to be opensource user for it, and the user has to be more significant than a "toy" implementation (which can be a bit subjective and contentious when trying to get out of a chicken and egg loop). thanks -john

1 year, 3 months

2
1
0 0

Re: [PATCH v1 05/10] media: platform: mediatek: add isp_7x camsys unit

by Krzysztof Kozlowski

On 09/10/2024 13:15, Shu-hsiang Yang wrote: > Introduces the top media device driver for the MediaTek ISP7X CAMSYS. > The driver maintains the camera system, including sub-device management, > DMA operations, and integration with the V4L2 framework. It handles > request stream data, buffer management, and MediaTek-specific features, > and pipeline management, streaming control, error handling mechanism. > Additionally, it aggregates sub-drivers for the camera interface, raw > and yuv pipelines. > > Signed-off-by: Shu-hsiang Yang <Shu-hsiang.Yang(a)mediatek.com> ... > + > +static int mtk_cam_probe(struct platform_device *pdev) > +{ > + struct mtk_cam_device *cam_dev; > + struct device *dev = &pdev->dev; > + struct resource *res; > + int ret; > + unsigned int i; > + > + dev_dbg(dev, "camsys | start %s\n", __func__); NAK. Same issues. > + > + /* initialize structure */ > + cam_dev = devm_kzalloc(dev, sizeof(*cam_dev), GFP_KERNEL); > + if (!cam_dev) > + return -ENOMEM; > + > + if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(34))) { > + dev_err(dev, "%s: No suitable DMA available\n", __func__); > + return -EIO; > + } > + > + if (!dev->dma_parms) { > + dev->dma_parms = > + devm_kzalloc(dev, sizeof(*dev->dma_parms), GFP_KERNEL); > + if (!dev->dma_parms) > + return -ENOMEM; > + } > + > + dma_set_max_seg_size(dev, UINT_MAX); > + > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!res) { > + dev_err(dev, "failed to get mem\n"); > + return -ENODEV; > + } > + > + cam_dev->base = devm_ioremap_resource(dev, res); > + if (IS_ERR(cam_dev->base)) { > + dev_err(dev, "failed to map register base\n"); > + return PTR_ERR(cam_dev->base); > + } > + > + cam_dev->dev = dev; > + dev_set_drvdata(dev, cam_dev); > + > + cam_dev->composer_cnt = 0; > + cam_dev->num_seninf_devices = 0; > + > + cam_dev->max_stream_num = MTKCAM_SUBDEV_MAX; > + cam_dev->ctxs = devm_kcalloc(dev, cam_dev->max_stream_num, > + sizeof(*cam_dev->ctxs), GFP_KERNEL); > + if (!cam_dev->ctxs) > + return -ENOMEM; > + > + cam_dev->streaming_ctx = 0; > + for (i = 0; i < cam_dev->max_stream_num; i++) > + mtk_cam_ctx_init(cam_dev->ctxs + i, cam_dev, i); > + > + cam_dev->running_job_count = 0; > + spin_lock_init(&cam_dev->pending_job_lock); > + spin_lock_init(&cam_dev->running_job_lock); > + INIT_LIST_HEAD(&cam_dev->pending_job_list); > + INIT_LIST_HEAD(&cam_dev->running_job_list); > + > + cam_dev->dma_processing_count = 0; > + spin_lock_init(&cam_dev->dma_pending_lock); > + spin_lock_init(&cam_dev->dma_processing_lock); > + INIT_LIST_HEAD(&cam_dev->dma_pending); > + INIT_LIST_HEAD(&cam_dev->dma_processing); > + > + mutex_init(&cam_dev->queue_lock); > + > + pm_runtime_enable(dev); > + > + ret = mtk_cam_of_rproc(cam_dev, pdev); > + if (ret) > + goto fail_destroy_mutex; > + > + ret = register_sub_drivers(dev); > + if (ret) { > + dev_err(dev, "fail to register_sub_drivers\n"); > + goto fail_destroy_mutex; > + } > + > + /* register mtk_cam as all isp subdev async parent */ > + cam_dev->notifier.ops = &mtk_cam_async_nf_ops; > + v4l2_async_nf_init(&cam_dev->notifier, &cam_dev->v4l2_dev); > + ret = mtk_cam_async_subdev_add(dev); /* wait all isp sub drivers */ > + if (ret) { > + dev_err(dev, "%s failed mtk_cam_async_subdev_add\n", __func__); > + goto fail_unregister_sub_drivers; > + } > + > + ret = v4l2_async_nf_register(&cam_dev->notifier); > + if (ret) { > + dev_err(dev, "%s async_nf_register ret:%d\n", __func__, ret); > + v4l2_async_nf_cleanup(&cam_dev->notifier); > + goto fail_unregister_sub_drivers; > + } > + > + ret = mtk_cam_debug_fs_init(cam_dev); > + if (ret < 0) > + goto fail_unregister_async_nf; > + > + dev_info(dev, "camsys | [%s] success\n", __func__); NAK. Same issues. > + > + return 0; > + > +fail_unregister_async_nf: > + v4l2_async_nf_unregister(&cam_dev->notifier); > + > +fail_unregister_sub_drivers: > + unregister_sub_drivers(dev); > + > +fail_destroy_mutex: > + mutex_destroy(&cam_dev->queue_lock); > + > + return ret; > +} > + > +static void mtk_cam_remove(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct mtk_cam_device *cam_dev = dev_get_drvdata(dev); > + > + pm_runtime_disable(dev); > + > + mtk_cam_debug_fs_deinit(cam_dev); > + > + v4l2_async_nf_unregister(&cam_dev->notifier); > + > + unregister_sub_drivers(dev); > + > + mutex_destroy(&cam_dev->queue_lock); > +} > + > +static const struct dev_pm_ops mtk_cam_pm_ops = { > + SET_RUNTIME_PM_OPS(mtk_cam_runtime_suspend, mtk_cam_runtime_resume, > + NULL) > +}; > + > +static struct platform_driver mtk_cam_driver = { > + .probe = mtk_cam_probe, > + .remove = mtk_cam_remove, > + .driver = { > + .name = "mtk-cam", > + .of_match_table = of_match_ptr(mtk_cam_of_ids), Same issues as in previous patch. All my comments apply to all your patches in this thread. > + .pm = &mtk_cam_pm_ops, > + } > +}; Best regards, Krzysztof

1 year, 3 months

1
0
0 0

Re: [PATCH v1 04/10] media: platform: mediatek: add isp_7x cam-raw unit

by Krzysztof Kozlowski

On 09/10/2024 13:15, Shu-hsiang Yang wrote: > Introduces the ISP pipeline driver for the MediaTek ISP raw and yuv > modules. Key functionalities include data processing, V4L2 integration, > resource management, debug support, and various control operations. > Additionally, IRQ handling, platform device management, and MediaTek > ISP DMA format support are also included. > > Signed-off-by: Shu-hsiang Yang <Shu-hsiang.Yang(a)mediatek.com> ... > + > +static int mtk_yuv_of_probe(struct platform_device *pdev, > + struct mtk_yuv_device *drvdata) > +{ > + struct device *dev = &pdev->dev; > + struct resource *res; > + int irq, ret; > + int n_clks; > + > + ret = of_property_read_u32(dev->of_node, "mediatek,cam-id", > + &drvdata->id); > + if (ret) { > + dev_dbg(dev, "missing camid property\n"); Debug? Or error? > + return ret; > + } > + > + if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(34))) { > + dev_err(dev, "%s: No suitable DMA available\n", __func__); > + return -EIO; > + } > + > + if (!dev->dma_parms) { > + dev->dma_parms = > + devm_kzalloc(dev, sizeof(*dev->dma_parms), GFP_KERNEL); > + if (!dev->dma_parms) > + return -ENOMEM; > + } > + > + dma_set_max_seg_size(dev, UINT_MAX); > + > + /* base outer register */ > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "base"); > + if (!res) { > + dev_err(dev, "failed to get mem\n"); > + return -ENODEV; > + } > + > + drvdata->base = devm_ioremap_resource(dev, res); > + if (IS_ERR(drvdata->base)) { > + dev_dbg(dev, "failed to map register base\n"); Dbg? What? > + return PTR_ERR(drvdata->base); > + } > + > + irq = platform_get_irq(pdev, 0); > + if (irq < 0) { > + dev_err(dev, "failed to get irq\n"); > + return -ENODEV; > + } > + > + ret = devm_request_irq(dev, irq, mtk_irq_yuv, 0, > + dev_name(dev), drvdata); > + if (ret) { > + dev_err(dev, "failed to request irq=%d\n", irq); > + return ret; > + } > + dev_dbg(dev, "registered irq=%d\n", irq); Drop > + > + n_clks = devm_clk_bulk_get_all(dev, &drvdata->clk_b); > + if (n_clks < 0) { > + dev_err(dev, "failed to devm_clk_bulk_get_all=%d\n", n_clks); Syntax is: return dev_err_probe() > + return n_clks; > + } > + > + drvdata->num_clks = n_clks; > + dev_info(dev, "clk_num:%d\n", drvdata->num_clks); Drop > + > +#ifdef CONFIG_PM_SLEEP > + drvdata->pm_notifier.notifier_call = yuv_pm_notifier; > + ret = register_pm_notifier(&drvdata->pm_notifier); > + if (ret) { > + dev_err(dev, "failed to register notifier block.\n"); > + return ret; > + } > +#endif > + > + return 0; > +} > + > +static int mtk_yuv_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct mtk_yuv_device *drvdata; > + struct v4l2_subdev *sd; > + int ret; > + > + dev_dbg(dev, "camsys | start %s\n", __func__); NAK > + > + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL); > + if (!drvdata) > + return -ENOMEM; > + > + drvdata->dev = dev; > + dev_set_drvdata(dev, drvdata); > + > + ret = mtk_yuv_of_probe(pdev, drvdata); > + if (ret) { > + dev_info(dev, "mtk_yuv_of_probe failed\n"); NAK. Neither info nor proper for memory allocation errors. Drop. > + return ret; > + } > + > + /* register yuv as mtk_cam async child */ > + sd = &drvdata->subdev; > + v4l2_subdev_init(sd, &mtk_raw_subdev_ops); > + sd->internal_ops = &mtk_raw_subdev_internal_ops; > + snprintf(sd->name, sizeof(sd->name), "%s", > + of_node_full_name(dev->of_node)); > + sd->dev = dev; > + sd->owner = THIS_MODULE; > + > + ret = v4l2_async_register_subdev(sd); > + if (ret) { > + dev_err(dev, "%s failed on async_register_subdev\n", __func__); > + return ret; > + } > + > + pm_runtime_enable(dev); > + > + dev_info(dev, "camsys | [%s] success\n", __func__); NAK > + > + return 0; > +} > + > +static void mtk_yuv_remove(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct mtk_yuv_device *yuv_dev = dev_get_drvdata(dev); > + struct v4l2_subdev *sd = &yuv_dev->subdev; > + > + dev_dbg(dev, "camsys | start %s\n", __func__); NAK > + > + unregister_pm_notifier(&yuv_dev->pm_notifier); > + > + pm_runtime_disable(dev); > + > + v4l2_async_unregister_subdev(sd); > +} > + > +/* driver for yuv part */ > +static int mtk_yuv_runtime_suspend(struct device *dev) > +{ > + struct mtk_yuv_device *drvdata = dev_get_drvdata(dev); > + > + dev_info(dev, "%s:disable clock\n", __func__); NAK > + > + clk_bulk_disable_unprepare(drvdata->num_clks, drvdata->clk_b); > + > + return 0; > +} > + > +static int mtk_yuv_runtime_resume(struct device *dev) > +{ > + struct mtk_yuv_device *drvdata = dev_get_drvdata(dev); > + int ret; > + > + dev_info(dev, "%s:enable clock\n", __func__); NAK. Not even dev_dbg. Please don't ever post such code. > + > + ret = clk_bulk_prepare_enable(drvdata->num_clks, drvdata->clk_b); > + if (ret) { > + dev_info(dev, "failed at clk_bulk_prepare_enable, ret = %d\n", ret); > + clk_bulk_disable_unprepare(drvdata->num_clks, drvdata->clk_b); > + return ret; > + } > + > + return 0; > +} > + > +static const struct dev_pm_ops mtk_yuv_pm_ops = { > + SET_RUNTIME_PM_OPS(mtk_yuv_runtime_suspend, mtk_yuv_runtime_resume, > + NULL) > +}; > + > +static const struct of_device_id mtk_yuv_of_ids[] = { > + {.compatible = "mediatek,cam-yuv",}, > + {} > +}; > +MODULE_DEVICE_TABLE(of, mtk_yuv_of_ids); > + > +struct platform_driver mtk_cam_yuv_driver = { > + .probe = mtk_yuv_probe, > + .remove = mtk_yuv_remove, > + .driver = { > + .name = "mtk-cam yuv", > + .of_match_table = of_match_ptr(mtk_yuv_of_ids), Drop of_match_ptr(), you will have here warnings. > + .pm = &mtk_yuv_pm_ops, > + } > +}; ... > diff --git a/drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_camera-v4l2-controls.h b/drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_camera-v4l2-controls.h > new file mode 100644 > index 000000000000..b775e6c30aa1 > --- /dev/null > +++ b/drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_camera-v4l2-controls.h > @@ -0,0 +1,65 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (c) 2022 MediaTek Inc. > + */ > + > +#ifndef __MTK_CAMERA_V4l2_CONTROLS_H > +#define __MTK_CAMERA_V4l2_CONTROLS_H > + > +#include <linux/videodev2.h> > +#include <linux/v4l2-controls.h> > +#include <linux/mtkisp_camsys.h> How these headers are used here? I don't see. Don't include unrelated stuff in your files. > + > +/* Allowed value of V4L2_CID_MTK_CAM_RAW_PATH_SELECT */ > +#define V4L2_MTK_CAM_RAW_PATH_SELECT_BPC 1 > +#define V4L2_MTK_CAM_RAW_PATH_SELECT_FUS 3 > +#define V4L2_MTK_CAM_RAW_PATH_SELECT_DGN 4 > +#define V4L2_MTK_CAM_RAW_PATH_SELECT_LSC 5 > +#define V4L2_MTK_CAM_RAW_PATH_SELECT_LTM 7 > + > +#define V4L2_MBUS_FRAMEFMT_PAD_ENABLE BIT(1) Best regards, Krzysztof

1 year, 3 months

1
0
0 0

Re: [PATCH v1 01/10] dt-bindings: media: mediatek: add camsys device

by Krzysztof Kozlowski

On 09/10/2024 13:15, Shu-hsiang Yang wrote: > 1. Add camera isp7x module device document > 2. Add camera interface device document > > Signed-off-by: Shu-hsiang Yang <Shu-hsiang.Yang(a)mediatek.com> > --- > .../media/mediatek/mediatek,cam-raw.yaml | 169 ++++++++++++++++++ > .../media/mediatek/mediatek,cam-yuv.yaml | 148 +++++++++++++++ > .../media/mediatek/mediatek,camisp.yaml | 71 ++++++++ > .../media/mediatek/mediatek,seninf-core.yaml | 106 +++++++++++ > .../media/mediatek/mediatek,seninf.yaml | 88 +++++++++ > 5 files changed, 582 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,cam-raw.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,cam-yuv.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,camisp.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,seninf-core.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,seninf.yaml > > diff --git a/Documentation/devicetree/bindings/media/mediatek/mediatek,cam-raw.yaml b/Documentation/devicetree/bindings/media/mediatek/mediatek,cam-raw.yaml > new file mode 100644 > index 000000000000..c709e4bf0a18 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/mediatek/mediatek,cam-raw.yaml > @@ -0,0 +1,169 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +# Copyright (c) 2024 MediaTek Inc. > + Drop blank line > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/mediatek/mediatek,cam-raw.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: The cam-raw unit of MediaTek ISP system > + > +maintainers: > + - Shu-hsiang Yang <shu-hsiang.yang(a)mediatek.com> > + - Shun-yi Wang <shun-yi.wang(a)mediatek.com> > + - Teddy Chen <teddy.chen(a)mediatek.com> > + > +description: > + MediaTek cam-raw is the camera RAW processing unit in MediaTek SoC. > + > +properties: > + compatible: > + const: mediatek,cam-raw SoC specific compatible instead. I see Rob gave you review, so few more points. ... > + > + assigned-clocks: > + maxItems: 1 > + > + assigned-clock-parents: > + maxItems: 1 Drop assigned-clock* > + > + iommus: > + description: > + Points to the respective IOMMU block with master port as argument, see > + Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. > + Ports are according to the HW. > + minItems: 1 > + maxItems: 32 > + > +required: > + - compatible > + - reg > + - reg-names > + - interrupts > + - power-domains > + - clocks > + - clock-names > + - iommus > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + #include <dt-bindings/interrupt-controller/irq.h> > + #include <dt-bindings/power/mediatek,mt8188-power.h> > + #include <dt-bindings/clock/mediatek,mt8188-clk.h> > + #include <dt-bindings/memory/mediatek,mt8188-memory-port.h> > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + cam_raw_a@16030000 { Node names should be generic. See also an explanation and list of examples (not exhaustive) in DT specification: https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetr… e.g. isp Also, underscores are not allowed in node names. Please do not send to us your downstream code. Read DTS coding style and write code maching upstream style. > + compatible = "mediatek,cam-raw"; > + reg = <0 0x16030000 0 0x8000>, > + <0 0x16038000 0 0x8000>; > + reg-names = "base", "inner_base"; > + mediatek,cam-id = <0>; > + mediatek,larbs = <&larb16a>; > + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH 0>; > + #address-cells = <2>; > + #size-cells = <2>; > + dma-ranges = <0x2 0x0 0x0 0x40000000 0x1 0x0>; > + power-domains = <&spm MT8188_POWER_DOMAIN_CAM_SUBA>; > + clocks = <&camsys CLK_CAM_MAIN_CAM2MM0_GALS>, > + <&camsys CLK_CAM_MAIN_CAM2MM1_GALS>, > + <&camsys CLK_CAM_MAIN_CAM2SYS_GALS>, > + <&camsys CLK_CAM_MAIN_CAM>, > + <&camsys CLK_CAM_MAIN_CAMTG>, > + <&camsys_rawa CLK_CAM_RAWA_LARBX>, > + <&camsys_rawa CLK_CAM_RAWA_CAM>, > + <&camsys_rawa CLK_CAM_RAWA_CAMTG>, > + <&topckgen CLK_TOP_CAM>, > + <&topckgen CLK_TOP_CAMTG>, > + <&topckgen CLK_TOP_CAMTM>; Messed alignment. > + clock-names = "camsys_cam2mm0_cgpdn", > + "camsys_cam2mm1_cgpdn", > + "camsys_cam2sys_cgpdn", > + "camsys_cam_cgpdn", > + "camsys_camtg_cgpdn", > + "camsys_rawa_larbx_cgpdn", > + "camsys_rawa_cam_cgpdn", > + "camsys_rawa_camtg_cgpdn", > + "topckgen_top_cam", > + "topckgen_top_camtg", > + "topckgen_top_camtm"; Also misaligned. > + assigned-clocks = <&topckgen CLK_TOP_CAM>; > + assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL_D5>; > + iommus = <&vpp_iommu M4U_PORT_L16A_IMGO_R1>, > + <&vpp_iommu M4U_PORT_L16A_CQI_R1>, Also misaligned. All comments apply to other files as well. Best regards, Krzysztof

1 year, 3 months

1
0
0 0

Re: [PATCH v1 5/5] i2c: i2c-qcom-geni: Add Block event interrupt support

by kernel test robot

Hi Jyothi, kernel test robot noticed the following build errors: [auto build test ERROR on 55bcd2e0d04c1171d382badef1def1fd04ef66c5] url: https://github.com/intel-lab-lkp/linux/commits/Jyothi-Kumar-Seerapu/dt-bind… base: 55bcd2e0d04c1171d382badef1def1fd04ef66c5 patch link: https://lore.kernel.org/r/20241015120750.21217-6-quic_jseerapu%40quicinc.com patch subject: [PATCH v1 5/5] i2c: i2c-qcom-geni: Add Block event interrupt support config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20241019/202410191055.bi1pWTAY-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241019/202410191055.bi1pWTAY-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/202410191055.bi1pWTAY-lkp@intel.com/ All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "gpi_multi_desc_process" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined! Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for GET_FREE_REGION Depends on [n]: SPARSEMEM [=n] Selected by [m]: - RESOURCE_KUNIT_TEST [=m] && RUNTIME_TESTING_MENU [=y] && KUNIT [=m] WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3) Selected by [m]: - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y]) -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 year, 3 months

1
0
0 0

Re: [PATCH v1 5/5] i2c: i2c-qcom-geni: Add Block event interrupt support

by kernel test robot

Hi Jyothi, kernel test robot noticed the following build errors: [auto build test ERROR on 55bcd2e0d04c1171d382badef1def1fd04ef66c5] url: https://github.com/intel-lab-lkp/linux/commits/Jyothi-Kumar-Seerapu/dt-bind… base: 55bcd2e0d04c1171d382badef1def1fd04ef66c5 patch link: https://lore.kernel.org/r/20241015120750.21217-6-quic_jseerapu%40quicinc.com patch subject: [PATCH v1 5/5] i2c: i2c-qcom-geni: Add Block event interrupt support config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20241019/202410190549.hGAfByqg-lkp@…) compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241019/202410190549.hGAfByqg-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/202410190549.hGAfByqg-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/i2c/busses/i2c-qcom-geni.c:562:8: error: incompatible pointer to integer conversion passing 'dma_addr_t *' (aka 'unsigned long long *') to parameter of type 'dma_addr_t' (aka 'unsigned long long'); dereference with * [-Wint-conversion] 562 | tx_multi_xfer->dma_addr[wr_idx], NULL, NULL); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | * drivers/i2c/busses/i2c-qcom-geni.c:519:36: note: passing argument to parameter 'tx_addr' here 519 | void *tx_buf, dma_addr_t tx_addr, | ^ >> drivers/i2c/busses/i2c-qcom-geni.c:562:47: error: incompatible pointer to integer conversion passing 'void *' to parameter of type 'dma_addr_t' (aka 'unsigned long long') [-Wint-conversion] 562 | tx_multi_xfer->dma_addr[wr_idx], NULL, NULL); | ^~~~ include/linux/stddef.h:8:14: note: expanded from macro 'NULL' 8 | #define NULL ((void *)0) | ^~~~~~~~~~~ drivers/i2c/busses/i2c-qcom-geni.c:520:36: note: passing argument to parameter 'rx_addr' here 520 | void *rx_buf, dma_addr_t rx_addr) | ^ >> drivers/i2c/busses/i2c-qcom-geni.c:586:7: error: incompatible pointer to integer conversion assigning to 'dma_addr_t' (aka 'unsigned long long') from 'dma_addr_t *' (aka 'unsigned long long *'); dereference with * [-Wint-conversion] 586 | addr = gi2c_gpi_xfer->dma_addr[gi2c_gpi_xfer->buf_idx]; | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | * 3 errors generated. Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3) Selected by [y]: - TI_K3_M4_REMOTEPROC [=y] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y]) vim +562 drivers/i2c/busses/i2c-qcom-geni.c 532 533 /** 534 * gpi_i2c_multi_desc_unmap() - unmaps the buffers post multi message TX transfers 535 * @dev: pointer to the corresponding dev node 536 * @gi2c: i2c dev handle 537 * @msgs: i2c messages array 538 * @peripheral: pointer to the gpi_i2c_config 539 */ 540 static void gpi_i2c_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], 541 struct gpi_i2c_config *peripheral) 542 { 543 u32 msg_xfer_cnt, wr_idx = 0; 544 struct gpi_multi_xfer *tx_multi_xfer = &peripheral->multi_xfer; 545 546 /* 547 * In error case, need to unmap all messages based on the msg_idx_cnt. 548 * Non-error case unmap all the processed messages. 549 */ 550 if (gi2c->err) 551 msg_xfer_cnt = tx_multi_xfer->msg_idx_cnt; 552 else 553 msg_xfer_cnt = tx_multi_xfer->irq_cnt * NUM_MSGS_PER_IRQ; 554 555 /* Unmap the processed DMA buffers based on the received interrupt count */ 556 for (; tx_multi_xfer->unmap_msg_cnt < msg_xfer_cnt; tx_multi_xfer->unmap_msg_cnt++) { 557 if (tx_multi_xfer->unmap_msg_cnt == gi2c->num_msgs) 558 break; 559 wr_idx = tx_multi_xfer->unmap_msg_cnt % QCOM_GPI_MAX_NUM_MSGS; 560 geni_i2c_gpi_unmap(gi2c, &msgs[tx_multi_xfer->unmap_msg_cnt], 561 tx_multi_xfer->dma_buf[wr_idx], > 562 tx_multi_xfer->dma_addr[wr_idx], NULL, NULL); 563 tx_multi_xfer->freed_msg_cnt++; 564 } 565 } 566 567 static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], int cur_msg_idx, 568 struct dma_slave_config *config, dma_addr_t *dma_addr_p, 569 void **buf, unsigned int op, struct dma_chan *dma_chan) 570 { 571 struct gpi_i2c_config *peripheral; 572 unsigned int flags; 573 void *dma_buf; 574 dma_addr_t addr; 575 enum dma_data_direction map_dirn; 576 enum dma_transfer_direction dma_dirn; 577 struct dma_async_tx_descriptor *desc; 578 int ret; 579 struct gpi_multi_xfer *gi2c_gpi_xfer; 580 dma_cookie_t cookie; 581 582 peripheral = config->peripheral_config; 583 gi2c_gpi_xfer = &peripheral->multi_xfer; 584 gi2c_gpi_xfer->msg_idx_cnt = cur_msg_idx; 585 dma_buf = gi2c_gpi_xfer->dma_buf[gi2c_gpi_xfer->buf_idx]; > 586 addr = gi2c_gpi_xfer->dma_addr[gi2c_gpi_xfer->buf_idx]; 587 588 dma_buf = i2c_get_dma_safe_msg_buf(&msgs[gi2c_gpi_xfer->msg_idx_cnt], 1); 589 if (!dma_buf) { 590 gi2c->err = -ENOMEM; 591 return -ENOMEM; 592 } 593 594 if (op == I2C_WRITE) 595 map_dirn = DMA_TO_DEVICE; 596 else 597 map_dirn = DMA_FROM_DEVICE; 598 599 addr = dma_map_single(gi2c->se.dev->parent, 600 dma_buf, msgs[gi2c_gpi_xfer->msg_idx_cnt].len, 601 map_dirn); 602 if (dma_mapping_error(gi2c->se.dev->parent, addr)) { 603 i2c_put_dma_safe_msg_buf(dma_buf, &msgs[gi2c_gpi_xfer->msg_idx_cnt], 604 false); 605 gi2c->err = -ENOMEM; 606 return -ENOMEM; 607 } 608 609 if (gi2c->is_tx_multi_xfer) { 610 if (((gi2c_gpi_xfer->msg_idx_cnt + 1) % NUM_MSGS_PER_IRQ)) 611 peripheral->flags |= QCOM_GPI_BLOCK_EVENT_IRQ; 612 else 613 peripheral->flags &= ~QCOM_GPI_BLOCK_EVENT_IRQ; 614 615 /* BEI bit to be cleared for last TRE */ 616 if (gi2c_gpi_xfer->msg_idx_cnt == gi2c->num_msgs - 1) 617 peripheral->flags &= ~QCOM_GPI_BLOCK_EVENT_IRQ; 618 } 619 620 /* set the length as message for rx txn */ 621 peripheral->rx_len = msgs[gi2c_gpi_xfer->msg_idx_cnt].len; 622 peripheral->op = op; 623 624 ret = dmaengine_slave_config(dma_chan, config); 625 if (ret) { 626 dev_err(gi2c->se.dev, "dma config error: %d for op:%d\n", ret, op); 627 goto err_config; 628 } 629 630 peripheral->set_config = 0; 631 peripheral->multi_msg = true; 632 flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK; 633 634 if (op == I2C_WRITE) 635 dma_dirn = DMA_MEM_TO_DEV; 636 else 637 dma_dirn = DMA_DEV_TO_MEM; 638 639 desc = dmaengine_prep_slave_single(dma_chan, addr, 640 msgs[gi2c_gpi_xfer->msg_idx_cnt].len, 641 dma_dirn, flags); 642 if (!desc) { 643 dev_err(gi2c->se.dev, "prep_slave_sg failed\n"); 644 gi2c->err = -EIO; 645 goto err_config; 646 } 647 648 desc->callback_result = i2c_gpi_cb_result; 649 desc->callback_param = gi2c; 650 651 if (!((msgs[cur_msg_idx].flags & I2C_M_RD) && op == I2C_WRITE)) { 652 gi2c_gpi_xfer->msg_idx_cnt++; 653 gi2c_gpi_xfer->buf_idx = (cur_msg_idx + 1) % QCOM_GPI_MAX_NUM_MSGS; 654 } 655 cookie = dmaengine_submit(desc); 656 if (dma_submit_error(cookie)) { 657 dev_err(gi2c->se.dev, 658 "%s: dmaengine_submit failed (%d)\n", __func__, cookie); 659 return -EINVAL; 660 } 661 662 if (gi2c->is_tx_multi_xfer) { 663 dma_async_issue_pending(gi2c->tx_c); 664 if ((cur_msg_idx == (gi2c->num_msgs - 1)) || 665 (gi2c_gpi_xfer->msg_idx_cnt >= 666 QCOM_GPI_MAX_NUM_MSGS + gi2c_gpi_xfer->freed_msg_cnt)) { 667 ret = gpi_multi_desc_process(gi2c->se.dev, gi2c_gpi_xfer, 668 gi2c->num_msgs, XFER_TIMEOUT, 669 &gi2c->done); 670 if (ret) { 671 dev_dbg(gi2c->se.dev, 672 "I2C multi write msg transfer timeout: %d\n", 673 ret); 674 gi2c->err = -ETIMEDOUT; 675 goto err_config; 676 } 677 } 678 } else { 679 /* Non multi descriptor message transfer */ 680 *buf = dma_buf; 681 *dma_addr_p = addr; 682 } 683 return 0; 684 685 err_config: 686 dma_unmap_single(gi2c->se.dev->parent, addr, 687 msgs[cur_msg_idx].len, map_dirn); 688 i2c_put_dma_safe_msg_buf(dma_buf, &msgs[cur_msg_idx], false); 689 return ret; 690 } 691 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 year, 3 months

1
0
0 0

[RFC PATCH v2 0/2] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs via the TEE subsystem. This a complete rewrite compared to the previous patch set [1], and other earlier proposals [2] and [3] with a separate restricted heap. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or a future QTEE) which sets up the restrictions for the memory used for the DMA-bufs. I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted DMA-bufs. This new IOCTL reaches the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. TEE_IOC_RSTMEM_ALLOC is quite similar to TEE_IOC_SHM_ALLOC so it's tempting to extend TEE_IOC_SHM_ALLOC with two new flags TEE_IOC_SHM_FLAG_SECURE_VIDEO and TEE_IOC_SHM_FLAG_SECURE_TRUSTED_UI for the same feature. However, it might be a bit confusing since TEE_IOC_SHM_ALLOC only returns an anonymous file descriptor, but TEE_IOC_SHM_FLAG_SECURE_VIDEO and TEE_IOC_SHM_FLAG_SECURE_TRUSTED_UI would return a DMA-buf file descriptor instead. What do others think? This can be tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v2 repo sync -j8 cd build make toolchains -j4 make all -j$(nproc) make run-only # login and at the prompt: xtest --sdp-basic https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens [1] https://lore.kernel.org/lkml/20240830070351.2855919-1-jens.wiklander@linaro… [2] https://lore.kernel.org/dri-devel/20240515112308.10171-1-yong.wu@mediatek.c… [3] https://lore.kernel.org/lkml/20220805135330.970-1-olivier.masse@nxp.com/ Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Jens Wiklander (2): tee: add restricted memory allocation optee: support restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/core.c | 21 ++++ drivers/tee/optee/optee_private.h | 6 + drivers/tee/optee/optee_smc.h | 35 ++++++ drivers/tee/optee/smc_abi.c | 45 ++++++- drivers/tee/tee_core.c | 33 ++++- drivers/tee/tee_private.h | 2 + drivers/tee/tee_rstmem.c | 200 ++++++++++++++++++++++++++++++ drivers/tee/tee_shm.c | 2 + drivers/tee/tee_shm_pool.c | 69 ++++++++++- include/linux/tee_core.h | 6 + include/linux/tee_drv.h | 9 ++ include/uapi/linux/tee.h | 33 ++++- 13 files changed, 455 insertions(+), 7 deletions(-) create mode 100644 drivers/tee/tee_rstmem.c -- 2.43.0

1 year, 3 months

2
6
0 0

[PATCH] dma-buf/dma-fence_array: use kvzalloc

by Christian König

Reports indicates that some userspace applications try to merge more than 80k of fences into a single dma_fence_array leading to a warning from kzalloc() that the requested size becomes to big. While that is clearly an userspace bug we should probably handle that case gracefully in the kernel. So we can either reject requests to merge more than a reasonable amount of fences (64k maybe?) or we can start to use kvzalloc() instead of kzalloc(). This patch here does the later. Signed-off-by: Christian König <christian.koenig(a)amd.com> CC: stable(a)vger.kernel.org --- drivers/dma-buf/dma-fence-array.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index 8a08ffde31e7..46ac42bcfac0 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -119,8 +119,8 @@ static void dma_fence_array_release(struct dma_fence *fence) for (i = 0; i < array->num_fences; ++i) dma_fence_put(array->fences[i]); - kfree(array->fences); - dma_fence_free(fence); + kvfree(array->fences); + kvfree_rcu(fence, rcu); } static void dma_fence_array_set_deadline(struct dma_fence *fence, @@ -153,7 +153,7 @@ struct dma_fence_array *dma_fence_array_alloc(int num_fences) { struct dma_fence_array *array; - return kzalloc(struct_size(array, callbacks, num_fences), GFP_KERNEL); + return kvzalloc(struct_size(array, callbacks, num_fences), GFP_KERNEL); } EXPORT_SYMBOL(dma_fence_array_alloc); -- 2.34.1

1 year, 3 months

1
0
0 0

Re: [PATCH 9/9] drm/panfrost: Explicitly clean up panfrost fence

by Christian König

Am 16.10.24 um 18:43 schrieb Adrián Larumbe: > On 16.10.2024 15:12, Christian König wrote: >> Am 15.10.24 um 01:31 schrieb Adrián Larumbe: >>> Doesn't make any functional difference because generic dma_fence is the >>> first panfrost_fence structure member, but I guess it doesn't hurt either. >> As discussed with Sima we want to push into the exactly opposite direction >> because that requires that the panfrost module stays loaded as long as fences >> are around. > Does that mean in future commits the struct dma_fence_ops' .release pointer will be > done with altogether? Yes, exactly that's the idea. As a first step I'm preparing patches right now to enforce using kmalloc instead of driver brewed approaches for dma_fence handling. Regards, Christian. > >> So clearly a NAK to this one here. Rather document on the structure that the >> dma_fence structure must be the first member. >> >> Regards, >> Christian. >> >>> Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> >>> --- >>> drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c >>> index 5d83c6a148ec..fa219f719bdc 100644 >>> --- a/drivers/gpu/drm/panfrost/panfrost_job.c >>> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c >>> @@ -85,9 +85,15 @@ static const char *panfrost_fence_get_timeline_name(struct dma_fence *fence) >>> } >>> } >>> +static void panfrost_fence_release(struct dma_fence *fence) >>> +{ >>> + kfree(to_panfrost_fence(fence)); >>> +} >>> + >>> static const struct dma_fence_ops panfrost_fence_ops = { >>> .get_driver_name = panfrost_fence_get_driver_name, >>> .get_timeline_name = panfrost_fence_get_timeline_name, >>> + .release = panfrost_fence_release, >>> }; >>> static struct dma_fence *panfrost_fence_create(struct panfrost_device *pfdev, int js_num)

1 year, 4 months

1
0
0 0

Re: [PATCH v1 2/5] arm64: dts: qcom: Add support for configuring channel TRE size

by Krzysztof Kozlowski

On 15/10/2024 14:07, Jyothi Kumar Seerapu wrote: > When high performance with multiple i2c messages in a single transfer > is required, employ Block Event Interrupt (BEI) to trigger interrupts > after specific messages transfer and the last message transfer, > thereby reducing interrupts. > For each i2c message transfer, a series of Transfer Request Elements(TREs) > must be programmed, including config tre for frequency configuration, > go tre for holding i2c address and dma tre for holding dma buffer address, > length as per the hardware programming guide. For transfer using BEI, > multiple I2C messages may necessitate the preparation of config, go, > and tx DMA TREs. However, a channel TRE size of 64 is often insufficient, > potentially leading to failures due to inadequate memory space. > > Adjust the channel TRE size through the device tree. > The default size is 64, but clients can modify this value based on > their heigher channel TRE size requirements. > > Signed-off-by: Jyothi Kumar Seerapu <quic_jseerapu(a)quicinc.com> > --- > arch/arm64/boot/dts/qcom/sc7280.dtsi | 132 +++++++++++++-------------- > 1 file changed, 66 insertions(+), 66 deletions(-) > > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi > index 3d8410683402..c7c0e15ff9d3 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi > @@ -1064,7 +1064,7 @@ > }; > > gpi_dma0: dma-controller@900000 { > - #dma-cells = <3>; > + #dma-cells = <4>; > compatible = "qcom,sc7280-gpi-dma", "qcom,sm6350-gpi-dma"; > reg = <0 0x00900000 0 0x60000>; > interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, > @@ -1114,8 +1114,8 @@ > "qup-memory"; > power-domains = <&rpmhpd SC7280_CX>; > required-opps = <&rpmhpd_opp_low_svs>; > - dmas = <&gpi_dma0 0 0 QCOM_GPI_I2C>, > - <&gpi_dma0 1 0 QCOM_GPI_I2C>; > + dmas = <&gpi_dma0 0 0 QCOM_GPI_I2C 64>, > + <&gpi_dma0 1 0 QCOM_GPI_I2C 64>; So everywhere is 64, thus this is fixed. Deduce it from the compatible Best regards, Krzysztof

1 year, 4 months

2
2
0 0

Re: [PATCH 9/9] drm/panfrost: Explicitly clean up panfrost fence

by Christian König

Am 15.10.24 um 01:31 schrieb Adrián Larumbe: > Doesn't make any functional difference because generic dma_fence is the > first panfrost_fence structure member, but I guess it doesn't hurt either. As discussed with Sima we want to push into the exactly opposite direction because that requires that the panfrost module stays loaded as long as fences are around. So clearly a NAK to this one here. Rather document on the structure that the dma_fence structure must be the first member. Regards, Christian. > Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> > --- > drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c > index 5d83c6a148ec..fa219f719bdc 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_job.c > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c > @@ -85,9 +85,15 @@ static const char *panfrost_fence_get_timeline_name(struct dma_fence *fence) > } > } > > +static void panfrost_fence_release(struct dma_fence *fence) > +{ > + kfree(to_panfrost_fence(fence)); > +} > + > static const struct dma_fence_ops panfrost_fence_ops = { > .get_driver_name = panfrost_fence_get_driver_name, > .get_timeline_name = panfrost_fence_get_timeline_name, > + .release = panfrost_fence_release, > }; > > static struct dma_fence *panfrost_fence_create(struct panfrost_device *pfdev, int js_num)

1 year, 4 months

1
0
0 0

Re: [PATCH v1 1/5] dt-bindings: dmaengine: qcom: gpi: Add additional arg to dma-cell property

by Vinod Koul

On 15-10-24, 17:37, Jyothi Kumar Seerapu wrote: > When high performance with multiple i2c messages in a single transfer > is required, employ Block Event Interrupt (BEI) to trigger interrupts > after specific messages transfer and the last message transfer, > thereby reducing interrupts. > > For each i2c message transfer, a series of Transfer Request Elements(TREs) > must be programmed, including config tre for frequency configuration, > go tre for holding i2c address and dma tre for holding dma buffer address, > length as per the hardware programming guide. For transfer using BEI, > multiple I2C messages may necessitate the preparation of config, go, > and tx DMA TREs. However, a channel TRE size of 64 is often insufficient, > potentially leading to failures due to inadequate memory space. > > Add additional argument to dma-cell property for channel TRE size. > With this, adjust the channel TRE size via the device tree. > The default size is 64, but clients can modify this value based on > their specific requirements. > > Signed-off-by: Jyothi Kumar Seerapu <quic_jseerapu(a)quicinc.com> > --- > Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > index 4df4e61895d2..002495921643 100644 > --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > @@ -54,14 +54,16 @@ properties: > maxItems: 13 > > "#dma-cells": > - const: 3 > + minItems: 3 > + maxItems: 4 > description: > > DMA clients must use the format described in dma.txt, giving a phandle > - to the DMA controller plus the following 3 integer cells: > + to the DMA controller plus the following 4 integer cells: > - channel: if set to 0xffffffff, any available channel will be allocated > for the client. Otherwise, the exact channel specified will be used. > - seid: serial id of the client as defined in the SoC documentation. > - client: type of the client as defined in dt-bindings/dma/qcom-gpi.h > + - channel-tre-size: size of the channel TRE (transfer ring element) This is a firmware /software property, why should this be in hardware description? -- ~Vinod

1 year, 4 months

1
0
0 0

Re: [PATCH v1 00/10] Add MediaTek ISP7 camera system driver

by Nicolas Dufresne

Hi, Le mercredi 09 octobre 2024 à 19:15 +0800, Shu-hsiang Yang a écrit : > Based on linux-next/master, tag: next-20241008 > > The patch set adds the MediaTek ISP7.x camera system hardware driver. > > This driver sets up ISP hardware, handles interrupts, and initializes > V4L2 device nodes and functions. Moreover, implement V4L2 standard > video driver that utilizes media framework APIs. It also connects > the sensors and ISP, bridging with the seninf interface. Communicate > with SCP co-processor to compose ISP registers in the firmware. Thanks for this work. If I read you correctly, this will depends on an scp firmware update. Its probably early at rev1, but we appreciate if you can cross- reference your associated linux-firmware submission (or document which MT flavour of SCP firmware) contains this support already. For ISP drivers reviewers, we have the experience with SCP that the IPC is not versioned, making it difficult to maintain backward compatibility. Won't matter until this is merged, but be aware that unless this SCP IPC design issue has been fixed, any change to the -if headers means a modification to the SCP has been made, and often we have had to ask MTK to revisit the firmware code to unbreak backward compatibility. If this specific part of the SCP IPC is versioned, please let us know. I don't want this to be alarming message, just something we need to collectively be aware of not to break userspace, which may not update their firmwares in lock step with the kernel. regards, Nicolas p.s. for those new to MTK architecture, the SCP firmware provides services to everything multimedia in the platform, including CODECs, color converter and scalers, etc. > > These patches include CSI received data from sensors, sensor interface > bridge, raw/YUV image pre-processing, ISP utility and ISP control parts. > > Thank you for reviewing these patches. > > Shu-hsiang Yang (10): > dt-bindings: media: mediatek: add camsys device > media: platform: mediatek: add seninf controller > media: platform: mediatek: add isp_7x seninf unit > media: platform: mediatek: add isp_7x cam-raw unit > media: platform: mediatek: add isp_7x camsys unit > media: platform: mediatek: add isp_7x utility > media: platform: mediatek: add isp_7x video ops > media: platform: mediatek: add isp_7x state ctrl > media: platform: mediatek: add isp_7x build config > uapi: linux: add mediatek isp_7x camsys user api > > .../media/mediatek/mediatek,cam-raw.yaml | 169 + > .../media/mediatek/mediatek,cam-yuv.yaml | 148 + > .../media/mediatek/mediatek,camisp.yaml | 71 + > .../media/mediatek/mediatek,seninf-core.yaml | 106 + > .../media/mediatek/mediatek,seninf.yaml | 88 + > drivers/media/platform/mediatek/Kconfig | 1 + > drivers/media/platform/mediatek/Makefile | 2 + > drivers/media/platform/mediatek/isp/Kconfig | 21 + > .../platform/mediatek/isp/isp_7x/Makefile | 7 + > .../mediatek/isp/isp_7x/camsys/Makefile | 16 + > .../isp_7x/camsys/kd_imgsensor_define_v4l2.h | 87 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-ctrl.c | 1797 ++++++ > .../mediatek/isp/isp_7x/camsys/mtk_cam-ctrl.h | 140 + > .../isp/isp_7x/camsys/mtk_cam-debug.c | 1271 ++++ > .../isp/isp_7x/camsys/mtk_cam-debug.h | 273 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-defs.h | 168 + > .../isp/isp_7x/camsys/mtk_cam-dmadbg.h | 721 +++ > .../isp/isp_7x/camsys/mtk_cam-feature.c | 40 + > .../isp/isp_7x/camsys/mtk_cam-feature.h | 26 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-fmt.h | 87 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-ipi.h | 233 + > .../isp/isp_7x/camsys/mtk_cam-meta-mt8188.h | 2436 ++++++++ > .../isp/isp_7x/camsys/mtk_cam-plat-util.c | 207 + > .../isp/isp_7x/camsys/mtk_cam-plat-util.h | 16 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-pool.c | 393 ++ > .../mediatek/isp/isp_7x/camsys/mtk_cam-pool.h | 28 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-raw.c | 5359 +++++++++++++++++ > .../mediatek/isp/isp_7x/camsys/mtk_cam-raw.h | 325 + > .../isp/isp_7x/camsys/mtk_cam-raw_debug.c | 403 ++ > .../isp/isp_7x/camsys/mtk_cam-raw_debug.h | 39 + > .../isp/isp_7x/camsys/mtk_cam-regs-mt8188.h | 382 ++ > .../isp/isp_7x/camsys/mtk_cam-seninf-def.h | 193 + > .../isp/isp_7x/camsys/mtk_cam-seninf-drv.c | 1741 ++++++ > .../isp/isp_7x/camsys/mtk_cam-seninf-drv.h | 16 + > .../isp/isp_7x/camsys/mtk_cam-seninf-hw.h | 120 + > .../isp/isp_7x/camsys/mtk_cam-seninf-if.h | 28 + > .../isp/isp_7x/camsys/mtk_cam-seninf-regs.h | 40 + > .../isp/isp_7x/camsys/mtk_cam-seninf-route.c | 356 ++ > .../isp/isp_7x/camsys/mtk_cam-seninf-route.h | 23 + > .../isp/isp_7x/camsys/mtk_cam-seninf.h | 170 + > .../isp/isp_7x/camsys/mtk_cam-timesync.c | 125 + > .../isp/isp_7x/camsys/mtk_cam-timesync.h | 12 + > .../isp/isp_7x/camsys/mtk_cam-ufbc-def.h | 59 + > .../isp/isp_7x/camsys/mtk_cam-video.c | 1817 ++++++ > .../isp/isp_7x/camsys/mtk_cam-video.h | 224 + > .../mediatek/isp/isp_7x/camsys/mtk_cam.c | 4168 +++++++++++++ > .../mediatek/isp/isp_7x/camsys/mtk_cam.h | 733 +++ > .../isp_7x/camsys/mtk_camera-v4l2-controls.h | 65 + > .../isp_7x/camsys/mtk_csi_phy_2_0/Makefile | 5 + > .../mtk_csi_phy_2_0/mtk_cam-seninf-cammux.h | 911 +++ > .../mtk_cam-seninf-csi0-cphy.h | 69 + > .../mtk_cam-seninf-csi0-dphy.h | 139 + > .../mtk_cam-seninf-hw_phy_2_0.c | 2879 +++++++++ > .../mtk_cam-seninf-mipi-rx-ana-cdphy-csi0a.h | 257 + > .../mtk_cam-seninf-seninf1-csi2.h | 415 ++ > .../mtk_cam-seninf-seninf1-mux.h | 147 + > .../mtk_csi_phy_2_0/mtk_cam-seninf-seninf1.h | 47 + > .../mtk_csi_phy_2_0/mtk_cam-seninf-tg1.h | 49 + > .../mtk_csi_phy_2_0/mtk_cam-seninf-top-ctrl.h | 99 + > include/uapi/linux/mtkisp_camsys.h | 227 + > 60 files changed, 30194 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,cam-raw.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,cam-yuv.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,camisp.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,seninf-core.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,seninf.yaml > create mode 100644 drivers/media/platform/mediatek/isp/Kconfig > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/Makefile > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/Makefile > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/kd_imgsensor_define_v4l2.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-ctrl.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-ctrl.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-debug.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-debug.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-defs.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-dmadbg.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-feature.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-feature.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-fmt.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-ipi.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-meta-mt8188.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-plat-util.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-plat-util.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-pool.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-pool.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw_debug.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw_debug.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-regs-mt8188.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-def.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-drv.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-drv.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-hw.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-if.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-regs.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-route.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-route.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-timesync.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-timesync.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-ufbc-def.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-video.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-video.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_camera-v4l2-controls.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/Makefile > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-cammux.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-csi0-cphy.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-csi0-dphy.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-hw_phy_2_0.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-mipi-rx-ana-cdphy-csi0a.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-seninf1-csi2.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-seninf1-mux.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-seninf1.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-tg1.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-top-ctrl.h > create mode 100644 include/uapi/linux/mtkisp_camsys.h >

1 year, 4 months

1
0
0 0

Re: [PATCH v1 1/5] dt-bindings: dmaengine: qcom: gpi: Add additional arg to dma-cell property

by Rob Herring

On Tue, Oct 15, 2024 at 05:37:46PM +0530, Jyothi Kumar Seerapu wrote: > When high performance with multiple i2c messages in a single transfer > is required, employ Block Event Interrupt (BEI) to trigger interrupts > after specific messages transfer and the last message transfer, > thereby reducing interrupts. > > For each i2c message transfer, a series of Transfer Request Elements(TREs) > must be programmed, including config tre for frequency configuration, > go tre for holding i2c address and dma tre for holding dma buffer address, > length as per the hardware programming guide. For transfer using BEI, > multiple I2C messages may necessitate the preparation of config, go, > and tx DMA TREs. However, a channel TRE size of 64 is often insufficient, > potentially leading to failures due to inadequate memory space. > > Add additional argument to dma-cell property for channel TRE size. No such property 'dma-cell' > With this, adjust the channel TRE size via the device tree. > The default size is 64, but clients can modify this value based on > their specific requirements. > > Signed-off-by: Jyothi Kumar Seerapu <quic_jseerapu(a)quicinc.com> > --- > Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > index 4df4e61895d2..002495921643 100644 > --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > @@ -54,14 +54,16 @@ properties: > maxItems: 13 > > "#dma-cells": > - const: 3 > + minItems: 3 > + maxItems: 4 > description: > > DMA clients must use the format described in dma.txt, giving a phandle > - to the DMA controller plus the following 3 integer cells: > + to the DMA controller plus the following 4 integer cells: > - channel: if set to 0xffffffff, any available channel will be allocated > for the client. Otherwise, the exact channel specified will be used. > - seid: serial id of the client as defined in the SoC documentation. > - client: type of the client as defined in dt-bindings/dma/qcom-gpi.h > + - channel-tre-size: size of the channel TRE (transfer ring element) > > iommus: > maxItems: 1 > -- > 2.17.1 >

1 year, 4 months

1
0
0 0

Re: [PATCH v1 1/5] dt-bindings: dmaengine: qcom: gpi: Add additional arg to dma-cell property

by Krzysztof Kozlowski

On 15/10/2024 14:07, Jyothi Kumar Seerapu wrote: > When high performance with multiple i2c messages in a single transfer > is required, employ Block Event Interrupt (BEI) to trigger interrupts > after specific messages transfer and the last message transfer, > thereby reducing interrupts. > > For each i2c message transfer, a series of Transfer Request Elements(TREs) > must be programmed, including config tre for frequency configuration, > go tre for holding i2c address and dma tre for holding dma buffer address, > length as per the hardware programming guide. For transfer using BEI, > multiple I2C messages may necessitate the preparation of config, go, > and tx DMA TREs. However, a channel TRE size of 64 is often insufficient, > potentially leading to failures due to inadequate memory space. Please kindly test the patches before you sent them. Upstream is not a testing service. Best regards, Krzysztof

1 year, 4 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig