Linaro-mm-sig October 2024

linaro-mm-sig@lists.linaro.org

23 participants
40 discussions

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

2 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)

2 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

2 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 >

2 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 >

2 months, 1 week

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

by Krzysztof Kozlowski

2 months, 1 week

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.

2 months, 1 week

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>

2 months, 1 week

Notes from the XDC 2024 "universal buffer allocator" workshop

by Laurent Pinchart

Hello, We held a workshop at XDC 2024 titled "Towards a universal buffer allocator for Linux", whose abstract was as follows: Buffer allocation for media contents, despite being required for any framework or application dealing with image capture, processing, decoding, encoding, rendering and display, remains an area plagued by many unsolved problems. Over time improvements have been made to APIs for buffer allocation, both on the kernel side (standardization of the DRM dumb buffer API, or DMA heaps, to name a few) and in userspace (most notably with GBM, and the buffer management API in Vulkan), or for specific use cases (e.g. gralloc in Android). Unfortunately, no universal solution exists to allocate buffers shared by multiple devices. This is hindering interoperability and forces userspace to pile hacks and workarounds. (https://indico.freedesktop.org/event/6/contributions/395/). Here are the raw notes from the workshop. XDC 2024 - Buffer allocation workshop ===================================== Attendees: - Erico Nunes <ernunes(a)redhat.com> - James Jones <jajones(a)nvidia.com> - Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> - Nicolas Dufresne <nicolas(a)collabora.com> - Yunxiang (Teddy) Li <yunxiang.li(a)amd.com> Relevant content: - XDC 2016: https://www.x.org/wiki/Events/XDC2016/Program/Unix_Device_Memory_Allocation… - XDC 2020: https://lpc.events/event/9/contributions/615/attachments/704/1301/XDC_2020_… Discussions ----------- NICs are relevant to the discussion, but likely only on large servers. The proposal needs to accomodate that. Nicolas asked about support for the CPU as a device. A lot of pipelines are hybrid, with CPU processing and dedicated hardware processing. James said previous proposals were able to support the CPU as a device. The last proposal was focussed on usages, so could support CPUs. Demi things this could be viewed as in a similar way as type checking in compilers, which have to resolve constraints. Nicolas is annoyed that we force applications to make a decision, requiring them to go the hard route of reallocation if they get it wrong. Some of the parameters are the MMU configuration, which can't be changed afterwards in Linux. Demi said that there could be cases where the fastest thing to do is to use shadow memory and copy. Nicolas said the first question that would come back is if this is something userspace should decide. Yunxiang asked if we're looking at designing a kernel interface to convey constraints. Nicolas said some kernel APIs expose some constraints. For instance, V4L2 allows discovering some stride constraints. Yunxiang thinks constraints won't be able to scale. Capabilities would be better. The difference is that the hardware device can have lots of constraints, but could more easily say some of the things it can do. Adding a new capability later wouldn't break anything, but adding a new constraint would require all components to understand it. James said the latest proposal handled constraints in a forward-compatible way with versioned constraints. Demi prefers the capabilities approach. Yunxiang said devices could expose which memory they can access. Nicolas said that in GStreamer, the current approach is trial and error. Capabilities would reduce trial and error. Everybody has hacks on top. James is instead bringing a formula that solves this. As soon as each of the nodes involved can be identified (which GStreamer can do now), we can calculate and combine but can't sustain adding capabilities. Liviu said GStreamer could tell which capabilities it supports, and push hardware vendors to comply with that. If the hardware is not compatible, GStreamer would provide converters. Nicolas said buffer sharing is a trade-off. We will find things that won't break it but will make it slower. Demi said that cache-incoherent DMA will usually have higher bandwidth than cache-coherent DMA, unless all the components share the same cache. Discussion followed on capabilities vs. constraints. It's partly a vocabulary matter. The first proposal from James was using the word capability. Constraints in the last proposal describe what a device can do. Nicolas has only stride and number of planes as constraints in GStreamer. James' mechanism has support for much more. Yunxiang asked if we can include the pixel format as constraints. James said we first have to resolve formats and modifiers, and then handle allocation constraints. Yunxiang thinks the allocator should also take care of the format. Nicolas said that when using a tiling modifier, we already reduce the scope of incompatibilities. When using e.g. an Intel tiling modifier, there's a bigger guarantee that the devices that support it will be able to inter-operate as they're designed for that purpose. Demi said it should be possible to validate parameters for buffers without being Mesa. The format modifiers are way too opaque. James said that for each format we need to query possible modifiers, and for each format+modifier we need to query constraints. Modifiers are mostly considered opaque to applications, constraints are semi-opaque, and formats are not opaque. The problem that remains hard to James is when it comes to locality, how do we say "local to a device" ? There's no serializable representation of a device. Nicolas says that as soon as it stays in the graphics stack, the stack will hide the problem from applications. A sysfs path could be used on Linux to identify a device. James asked how an application would be allowed to allocate buffers from e.g. a DRI device, if the allocator library told it that the allocation needs to be done there. This starts becoming a permission issue or a logind issue. Passing fds could help, but when sitting on top of GL, we have no way to get an fd. Nicolas said Vulkan should be OK, but GL is dead. Nicolas asked why it would be useful to get access to fds. James said that at the bottom of the problem we have the question of which fd we send an ioctl to to allocate memory. We could start small to have something and break the chicken and egg problem. James thought about using GBM to start with, but this isn't good for GStreamer. James and Nicolas thought that kernel drivers would register dmabuf heaps. One issue with dmabuf heaps today is that allocation isn't tracked, so we bypass cgroups. DRM and V4L2 have the same issue, offering an infinite amount of memory. logind has a responsibility of not making it worse, so didn't allow access to dmabuf heaps. The problem needs to be fixed in the kernel first, adding accounting. This would then be an incentive to abandon device-specific allocation APIs, as memory accounting would come for free when using dmabuf heaps. Nicolas wonders why the obvious path forward of implementing heaps for devices that have specific constraints didn't happen. James thinks people may just have been too busy. Demi brought up the VFIO case. The hardware device may not be managed by the kernel, it may be managed by userspace, or passed to a guest. Capabilities for those devices can't come from a kernel device. James said the key is communicating the constraints in a serializable way. Allocation would involve passing dmabufs between guests and hosts. Allocation from DMA heaps and from subsystem-specific APIs will coexist for a long time. This needs to be abstracted in a userspace library, so that the underlying allocators can evolve. Demi asked if GBM is needed when using Vulkan. Internally in mesa, everything uses GBM for allocation. James said it's a good argument to ask why not using Vulkan only. If we decide to use GBM to bootstrap this evolution, and GBM allocates for a specific device, then it doesn't seem to be a good fit. We don't want to add support for system memory allocation to GBM. Erico said that there's a use case for GBM even when using Vulkan when there's a separate display device that has no Vulkan implementation. We need an iterative approach. For instance a simple useful improvement would be to expose stride constraints on DRM devices. Conclusions ----------- - We need some library (existing or new one) - We need some API - We need someone to bootstrap this - We need a more iterative approach Action points ------------- - Add memory accounting to DMA heaps - Push drivers to implement their own heaps to replace subsystem allocation APIs -- Regards, Laurent Pinchart

2 months, 1 week

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

by AngeloGioacchino Del Regno

Il 09/10/24 13:15, Shu-hsiang Yang ha scritto: > 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> > --- > .../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_7x/camsys/mtk_camera-v4l2-controls.h | 65 + > 5 files changed, 6191 insertions(+) > 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_camera-v4l2-controls.h > > diff --git a/drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw.c b/drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw.c > new file mode 100644 > index 000000000000..c025f53c952d > --- /dev/null > +++ b/drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw.c > @@ -0,0 +1,5359 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (c) 2022 MediaTek Inc. > + > +#include <linux/clk.h> > +#include <linux/interrupt.h> > +#include <linux/iopoll.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/of_platform.h> > +#include <linux/platform_device.h> > +#include <linux/pm_runtime.h> > +#include <linux/vmalloc.h> > +#include <linux/videodev2.h> > +#include <linux/suspend.h> > +#include <linux/rtc.h> > + > +#include <media/v4l2-device.h> > +#include <media/v4l2-event.h> > +#include <media/v4l2-ioctl.h> > +#include <media/v4l2-subdev.h> > + > +#include <soc/mediatek/smi.h> > + > +#include "mtk_cam.h" > +#include "mtk_cam-feature.h" > +#include "mtk_cam-raw.h" > + > +#include "mtk_cam-regs-mt8188.h" > + > +#include "mtk_cam-video.h" > +#include "mtk_cam-seninf-if.h" > +#include "mtk_camera-v4l2-controls.h" > + > +#include "mtk_cam-dmadbg.h" > +#include "mtk_cam-raw_debug.h" > + > +static unsigned int debug_raw; > +module_param(debug_raw, uint, 0644); > +MODULE_PARM_DESC(debug_raw, "activates debug info"); > + > +static int debug_raw_num = -1; > +module_param(debug_raw_num, int, 0644); > +MODULE_PARM_DESC(debug_raw_num, "debug: num of used raw devices"); > + > +static int debug_pixel_mode = -1; > +module_param(debug_pixel_mode, int, 0644); > +MODULE_PARM_DESC(debug_pixel_mode, "debug: pixel mode"); > + > +static int debug_clk_idx = -1; > +module_param(debug_clk_idx, int, 0644); > +MODULE_PARM_DESC(debug_clk_idx, "debug: clk idx"); > + > +static int debug_dump_fbc; > +module_param(debug_dump_fbc, int, 0644); > +MODULE_PARM_DESC(debug_dump_fbc, "debug: dump fbc"); > + In addition to the first review that I gave you on patch [02/10]: please drop all those module parameters. If you want debug switches, use debugfs instead. Regards, Angelo

2 months, 1 week

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig October 2024