Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

15 participants
3025 discussions

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.

10 months, 3 weeks

[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

10 months, 3 weeks

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.

10 months, 3 weeks

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

10 months, 3 weeks

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

10 months, 3 weeks

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

10 months, 3 weeks

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

10 months, 3 weeks

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

by kernel test robot

10 months, 4 weeks

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

10 months, 4 weeks

[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

10 months, 4 weeks

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig