Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

15 participants
3025 discussions

[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

11 months

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)

11 months

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

11 months

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)

11 months

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

11 months

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 >

11 months

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 >

11 months

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

by Krzysztof Kozlowski

11 months

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

by Rob Herring (Arm)

On Tue, 15 Oct 2024 17:37:46 +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. > 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(-) > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/dma/qcom,gpi.yaml: properties:#dma-cells: 'minItems' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf'] from schema $id: http://devicetree.org/meta-schemas/core.yaml# /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/dma/qcom,gpi.yaml: properties:#dma-cells: 'maxItems' is not one of ['description', 'deprecated', 'const', 'enum', 'minimum', 'maximum', 'multipleOf', 'default', '$ref', 'oneOf'] from schema $id: http://devicetree.org/meta-schemas/core.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/202410151207… The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.

11 months

Re: [PATCH v2] dma-buf: fix S_IRUGO to 0444, block comments, func declaration

by John Stultz

On Sat, Oct 5, 2024 at 11:10 AM Pintu Kumar <quic_pintu(a)quicinc.com> wrote: > > These warnings/errors are reported by checkpatch. > Fix them with minor changes to make it clean. > No other functional changes. > > WARNING: Block comments use * on subsequent lines > + /* only support discovering the end of the buffer, > + but also allow SEEK_SET to maintain the idiomatic > > WARNING: Block comments use a trailing */ on a separate line > + SEEK_END(0), SEEK_CUR(0) pattern */ > > WARNING: Block comments use a trailing */ on a separate line > + * before passing the sgt back to the exporter. */ > > ERROR: "foo * bar" should be "foo *bar" > +static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach, > > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'. > + d = debugfs_create_file("bufinfo", S_IRUGO, dma_buf_debugfs_dir, > > total: 1 errors, 4 warnings, 1746 lines checked > > Signed-off-by: Pintu Kumar <quic_pintu(a)quicinc.com> Looks ok to me. Thanks for sending these cleanups! Acked-by: John Stultz <jstultz(a)google.com>

11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig