* [PATCH v11 0/3] media: mediatek: support mdp3 on mt8183 platform
@ 2022-01-05 9:37 Moudy Ho
2022-01-05 9:37 ` [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings Moudy Ho
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Moudy Ho @ 2022-01-05 9:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley, Laurent Pinchart,
linux-media, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Alexandre Courbot, tfiga, drinkcat, pihsun, hsinyi,
AngeloGioacchino Del Regno, Maoguang Meng, daoyuan huang,
Ping-Hsun Wu, menghui.lin, sj.huang, allen-kh.cheng, randy.wu,
moudy.ho, jason-jh.lin, roy-cw.yeh, river.cheng, srv_heupstream
Change since v10:
- The routing table needs to be discarded, and the calculation result
on the SCP side is used to write a suitable mux setting for
1 input port and 2 output ports.
- Adjust dts parsing flow to remove redundant HW IDs.
- Fix memory leak caused by no free path information in function "mdp_cmdq_send".
Change since v9:
- Keep only the MDP3 driver patches and split the remaining mmsys and
mutex patches into another mail.
- Move mutex mod settings to corresponding driver and make relevant adjustments
for this in MDP3 driver.
- Fix compile warning reported by kernel test robot.
Change since v8:
- Rebase on v5.16-rc2.
- Refer to Angelo's suggestion, adjust the register writing format to increase
readability and significance.
- Refer to Angelo's suggestion, adjust or reduce inappropriate debugging
messages.
- Refer to Rob Herring's suggestion to correct the the binding file
to make it with the specification.
- Fix compile warning reported by kernel test robot.
Change since v7:
- Rebase on v5.15-rc6.
- Revise several V4L2 M2M settings to pass v4l2-compliance test.
- Integrate those same component dt-binding documents of DRM and MDP, and
move them under the MMSYS domain.
- Split MMSYS and MUTEX into two different files according to
their functional properties.
Changes since v6:
- Refactor GCE event to corresponding node.
- Fix dt_binding_check fail.
- Fix compilation errors.
Changes since v5:
- Rebase on v5.14-rc6.
- Move MMSYS/Mutex settings to corresponding driver.
- Revise the software license description and copyright.
- Remove unnecessary enum. or definitions.
- Optimize platform/chip definition conditions.
- Use general printing functions instead of MDP3 private ones.
- Fix compile warning.
Changes since v4:
- Rebase on v5.13-rc1.
- Remove the CMDQ flush flow to match the CMDQ API change.
- Integrate four of MDP's direct-link subcomponents into MDP controller node
from syscon node to avoid illegal clock usage.
- Rewrite dt-binding in a JSON compatible subset of YAML
- Fix a bit of macro argument precedence.
Changes since v3:
- Rebase on v5.9-rc1.
- modify code for review comment from Rob Herring, cancel multiple nodes using
same register base situation.
- control IOMMU port through pm runtime get/put to DMA components' device.
- SCP(VPU) driver revision.
- stop queuing jobs(remove flush_workqueue()) after mdp_m2m_release().
- add computation of plane address with data_offset.
- fix scale ratio check issue.
- add default v4l2_format setting.
Changes since v2:
- modify code for review comment from Tomasz Figa & Alexandre Courbot
- review comment from Rob Herring will offer code revision in v4, due to
it's related to device node modification, will need to modify code
architecture
Changes since v1:
- modify code for CMDQ v3 API support
- EC ipi cmd migration
- fix compliance test fail item (m2m cmd with -f) due to there is two problem in runing all format(-f) cmd:
1. out of memory before test complete
Due to capture buffer mmap (refcount + 1) after reqbuf but seems
no corresponding munmap called before device close.
There are total 12XX items(formats) in format test and each format
alloc 8 capture/output buffers.
2. unceasingly captureBufs() (randomly)
Seems the break statement didn't catch the count == 0 situation:
In v4l2-test-buffers.cpp, function: captureBufs()
...
count--;
if (!node->is_m2m && !count)
break;
Log is as attachment
I will paste the test result with problem part in another e-mail
Hi,
This is the first version of RFC patch for Media Data Path 3 (MDP3),
MDP3 is used for scaling and color format conversion.
support using GCE to write register in critical time limitation.
support V4L2 m2m device control.
Moudy Ho (3):
dt-binding: mt8183: add Mediatek MDP3 dt-bindings
dts: arm64: mt8183: add Mediatek MDP3 nodes
media: platform: mtk-mdp3: add Mediatek MDP3 driver
.../bindings/media/mediatek,mdp3-rdma.yaml | 193 +++
.../bindings/media/mediatek,mdp3-rsz.yaml | 55 +
.../bindings/media/mediatek,mdp3-wrot.yaml | 57 +
.../bindings/soc/mediatek/mediatek,ccorr.yaml | 47 +
.../bindings/soc/mediatek/mediatek,wdma.yaml | 58 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 108 +-
drivers/media/platform/Kconfig | 20 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/mtk-mdp3/Makefile | 6 +
.../media/platform/mtk-mdp3/mdp_reg_ccorr.h | 19 +
drivers/media/platform/mtk-mdp3/mdp_reg_isp.h | 27 +
.../media/platform/mtk-mdp3/mdp_reg_rdma.h | 65 +
drivers/media/platform/mtk-mdp3/mdp_reg_rsz.h | 39 +
.../media/platform/mtk-mdp3/mdp_reg_wdma.h | 47 +
.../media/platform/mtk-mdp3/mdp_reg_wrot.h | 55 +
drivers/media/platform/mtk-mdp3/mtk-img-ipi.h | 280 ++++
.../media/platform/mtk-mdp3/mtk-mdp3-cmdq.c | 515 +++++++
.../media/platform/mtk-mdp3/mtk-mdp3-cmdq.h | 46 +
.../media/platform/mtk-mdp3/mtk-mdp3-comp.c | 1228 +++++++++++++++++
.../media/platform/mtk-mdp3/mtk-mdp3-comp.h | 147 ++
.../media/platform/mtk-mdp3/mtk-mdp3-core.c | 338 +++++
.../media/platform/mtk-mdp3/mtk-mdp3-core.h | 76 +
.../media/platform/mtk-mdp3/mtk-mdp3-m2m.c | 789 +++++++++++
.../media/platform/mtk-mdp3/mtk-mdp3-m2m.h | 49 +
.../media/platform/mtk-mdp3/mtk-mdp3-regs.c | 737 ++++++++++
.../media/platform/mtk-mdp3/mtk-mdp3-regs.h | 372 +++++
.../media/platform/mtk-mdp3/mtk-mdp3-vpu.c | 312 +++++
.../media/platform/mtk-mdp3/mtk-mdp3-vpu.h | 78 ++
28 files changed, 5764 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
create mode 100644 drivers/media/platform/mtk-mdp3/Makefile
create mode 100644 drivers/media/platform/mtk-mdp3/mdp_reg_ccorr.h
create mode 100644 drivers/media/platform/mtk-mdp3/mdp_reg_isp.h
create mode 100644 drivers/media/platform/mtk-mdp3/mdp_reg_rdma.h
create mode 100644 drivers/media/platform/mtk-mdp3/mdp_reg_rsz.h
create mode 100644 drivers/media/platform/mtk-mdp3/mdp_reg_wdma.h
create mode 100644 drivers/media/platform/mtk-mdp3/mdp_reg_wrot.h
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-img-ipi.h
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.c
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-cmdq.h
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.c
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-comp.h
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-core.c
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-core.h
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-m2m.c
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-m2m.h
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-regs.c
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-regs.h
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-vpu.c
create mode 100644 drivers/media/platform/mtk-mdp3/mtk-mdp3-vpu.h
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings
2022-01-05 9:37 [PATCH v11 0/3] media: mediatek: support mdp3 on mt8183 platform Moudy Ho
@ 2022-01-05 9:37 ` Moudy Ho
2022-01-21 21:16 ` Rob Herring
2022-01-05 9:37 ` [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes Moudy Ho
2022-03-16 8:35 ` [PATCH v11 0/3] media: mediatek: support mdp3 on mt8183 platform AngeloGioacchino Del Regno
2 siblings, 1 reply; 12+ messages in thread
From: Moudy Ho @ 2022-01-05 9:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley, Laurent Pinchart,
linux-media, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Alexandre Courbot, tfiga, drinkcat, pihsun, hsinyi,
AngeloGioacchino Del Regno, Maoguang Meng, daoyuan huang,
Ping-Hsun Wu, menghui.lin, sj.huang, allen-kh.cheng, randy.wu,
moudy.ho, jason-jh.lin, roy-cw.yeh, river.cheng, srv_heupstream
This patch adds DT binding document for Media Data Path 3 (MDP3)
a unit in multimedia system used for scaling and color format convert.
Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
---
.../bindings/media/mediatek,mdp3-rdma.yaml | 193 ++++++++++++++++++
.../bindings/media/mediatek,mdp3-rsz.yaml | 55 +++++
.../bindings/media/mediatek,mdp3-wrot.yaml | 57 ++++++
.../bindings/soc/mediatek/mediatek,ccorr.yaml | 47 +++++
.../bindings/soc/mediatek/mediatek,wdma.yaml | 58 ++++++
5 files changed, 410 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
new file mode 100644
index 000000000000..002503383934
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Read Direct Memory Access
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description: |
+ Mediatek Read Direct Memory Access(RDMA) component used to do read DMA.
+ It contains one line buffer to store the sufficient pixel data, and
+ must be siblings to the central MMSYS_CONFIG node.
+ For a description of the MMSYS_CONFIG binding, see
+ Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+ for details.
+ The 1st RDMA is also used to be a controller node in Media Data Path 3(MDP3)
+ that containing MMSYS, MUTEX, GCE and SCP settings.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ # MDP3 controller node
+ - const: mediatek,mt8183-mdp3
+ - const: mediatek,mt8183-mdp3-rdma0
+ - items:
+ # normal RDMA conponent
+ - const: mediatek,mt8183-mdp3-rdma0
+
+ mediatek,scp:
+ description: The node of system control processor (SCP), using
+ the remoteproc & rpmsg framework.
+ $ref: /schemas/types.yaml#/definitions/phandle
+ maxItems: 1
+
+ mediatek,mdp3-comps:
+ description: MTK sub-system of direct-link or DIP
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ - enum:
+ # MDP direct-link input path selection, create a
+ # component for path connectedness of HW pipe control
+ - mediatek,mt8183-mdp3-dl1
+ - enum:
+ - mediatek,mt8183-mdp3-dl2
+ - enum:
+ # MDP direct-link output path selection, create a
+ # component for path connectedness of HW pipe control
+ - mediatek,mt8183-mdp3-path1
+ - enum:
+ - mediatek,mt8183-mdp3-path2
+ - enum:
+ # Input DMA of ISP PASS2 (DIP) module for raw image input
+ - mediatek,mt8183-mdp3-imgi
+ - enum:
+ # Output DMA of ISP PASS2 (DIP) module for YUV image output
+ - mediatek,mt8183-mdp3-exto
+
+ reg:
+ items:
+ - description: basic RDMA HW address
+ - description: MDP direct-link 1st and 2nd input
+ - description: MDP direct-link 1st output
+ - description: MDP direct-link 2nd output
+ - description: ISP input and output
+
+ mediatek,gce-client-reg:
+ description: The register of client driver can be configured by gce with
+ 4 arguments defined in this property, such as phandle of gce, subsys id,
+ register offset and size. Each GCE subsys id is mapping to a client
+ defined in the header include/dt-bindings/gce/<chip>-gce.h.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - description: GCE client for RDMA
+ - description: GCR client for MDP direct-link 1st and 2nd input
+ - description: GCR client for MDP direct-link 1st output
+ - description: GCR client for MDP direct-link 2nd output
+ - description: GCR client for ISP input and output
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: RDMA clock
+ - description: RSZ clock
+ - description: direck-link TX clock in MDP side
+ - description: direck-link RX clock in MDP side
+ - description: direck-link TX clock in ISP side
+ - description: direck-link RX clock in ISP side
+
+ iommus:
+ maxItems: 1
+
+ mediatek,mmsys:
+ description: The node of mux(multiplexer) controller for HW connections.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ mediatek,mm-mutex:
+ description: The node of sof(start of frame) signal controller.
+ $ref: /schemas/types.yaml#/definitions/phandle
+ maxItems: 1
+
+ mediatek,mailbox-gce:
+ description: The node of global command engine (GCE), used to read/write
+ registers with critical time limitation.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ mboxes:
+ items:
+ - description: used for 1st data pipe from RDMA
+ - description: used for 2nd data pipe from RDMA
+ - description: used for 3rd data pipe from Direct-Link
+ - description: used for 4th data pipe from Direct-Link
+
+ gce-subsys:
+ description: sub-system id corresponding to the global command engine (GCE)
+ register address.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
+if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8183-mdp3
+
+then:
+ required:
+ - mediatek,scp
+ - mediatek,mmsys
+ - mediatek,mm-mutex
+ - mediatek,mailbox-gce
+ - mboxes
+ - gce-subsys
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - mediatek,gce-client-reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/gce/mt8183-gce.h>
+ #include <dt-bindings/power/mt8183-power.h>
+ #include <dt-bindings/memory/mt8183-larb-port.h>
+
+ mdp3_rdma0: mdp3_rdma0@14001000 {
+ compatible = "mediatek,mt8183-mdp3",
+ "mediatek,mt8183-mdp3-rdma0";
+ mediatek,scp = <&scp>;
+ mediatek,mdp3-comps = "mediatek,mt8183-mdp3-dl1",
+ "mediatek,mt8183-mdp3-dl2",
+ "mediatek,mt8183-mdp3-path1",
+ "mediatek,mt8183-mdp3-path2",
+ "mediatek,mt8183-mdp3-imgi",
+ "mediatek,mt8183-mdp3-exto";
+ reg = <0x14001000 0x1000>,
+ <0x14000000 0x1000>,
+ <0x14005000 0x1000>,
+ <0x14006000 0x1000>,
+ <0x15020000 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>,
+ <&gce SUBSYS_1400XXXX 0 0x1000>,
+ <&gce SUBSYS_1400XXXX 0x5000 0x1000>,
+ <&gce SUBSYS_1400XXXX 0x6000 0x1000>,
+ <&gce SUBSYS_1502XXXX 0 0x1000>;
+ power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+ <&mmsys CLK_MM_MDP_RSZ1>,
+ <&mmsys CLK_MM_MDP_DL_TXCK>,
+ <&mmsys CLK_MM_MDP_DL_RX>,
+ <&mmsys CLK_MM_IPU_DL_TXCK>,
+ <&mmsys CLK_MM_IPU_DL_RX>;
+ iommus = <&iommu>;
+ mediatek,mmsys = <&mmsys>;
+ mediatek,mm-mutex = <&mutex>;
+ mediatek,mailbox-gce = <&gce>;
+ mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 21 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 22 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 23 CMDQ_THR_PRIO_LOWEST>;
+ gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
+ <&gce 0x14010000 SUBSYS_1401XXXX>,
+ <&gce 0x14020000 SUBSYS_1402XXXX>,
+ <&gce 0x15020000 SUBSYS_1502XXXX>;
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
new file mode 100644
index 000000000000..cd4cf1531535
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-rsz.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Resizer
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description: |
+ One of Media Data Path 3 (MDP3) components used to do frame resizing.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt8183-mdp3-rsz0
+ - mediatek,mt8183-mdp3-rsz1
+
+ reg:
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description: The register of client driver can be configured by gce with
+ 4 arguments defined in this property, such as phandle of gce, subsys id,
+ register offset and size. Each GCE subsys id is mapping to a client
+ defined in the header include/dt-bindings/gce/<chip>-gce.h.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/gce/mt8183-gce.h>
+
+ mdp3_rsz0: mdp3_rsz0@14003000 {
+ compatible = "mediatek,mt8183-mdp3-rsz0";
+ reg = <0x14003000 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x3000 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ0>;
+ };
+
+ mdp3_rsz1: mdp3_rsz1@14004000 {
+ compatible = "mediatek,mt8183-mdp3-rsz1";
+ reg = <0x14004000 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x4000 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ1>;
+ };
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
new file mode 100644
index 000000000000..7b0f9c4fffd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-wrot.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Write DMA with Rotation
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description: |
+ One of Media Data Path 3 (MDP3) components used to write DMA with frame rotation.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt8183-mdp3-wrot0
+
+ reg:
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description: The register of client driver can be configured by gce with
+ 4 arguments defined in this property, such as phandle of gce, subsys id,
+ register offset and size. Each GCE subsys id is mapping to a client
+ defined in the header include/dt-bindings/gce/<chip>-gce.h.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+
+ iommus:
+ maxItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/gce/mt8183-gce.h>
+ #include <dt-bindings/power/mt8183-power.h>
+ #include <dt-bindings/memory/mt8183-larb-port.h>
+
+ mdp3_wrot0: mdp3_wrot0@14005000 {
+ compatible = "mediatek,mt8183-mdp3-wrot0";
+ reg = <0x14005000 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x5000 0x1000>;
+ power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_MDP_WROT0>;
+ iommus = <&iommu>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
new file mode 100644
index 000000000000..cf23f4f5bd69
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mediatek,ccorr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek color correction
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description: |
+ Mediatek color correction with 3X3 matrix.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt8183-mdp3-ccorr
+
+ reg:
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description: The register of client driver can be configured by gce with
+ 4 arguments defined in this property, such as phandle of gce, subsys id,
+ register offset and size. Each GCE subsys id is mapping to a client
+ defined in the header include/dt-bindings/gce/<chip>-gce.h.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/gce/mt8183-gce.h>
+
+ mdp3_ccorr: mdp3_ccorr@1401c000 {
+ compatible = "mediatek,mt8183-mdp3-ccorr";
+ reg = <0x1401c000 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0xc000 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_CCORR>;
+ };
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
new file mode 100644
index 000000000000..4057b5232e45
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/mediatek/mediatek,wdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek Write Direct Memory Access
+
+maintainers:
+ - Matthias Brugger <matthias.bgg@gmail.com>
+
+description: |
+ Mediatek Write Direct Memory Access(WDMA) component used to write
+ the data into DMA.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - mediatek,mt8183-mdp3-wdma
+
+ reg:
+ maxItems: 1
+
+ mediatek,gce-client-reg:
+ description: The register of client driver can be configured by gce with
+ 4 arguments defined in this property, such as phandle of gce, subsys id,
+ register offset and size. Each GCE subsys id is mapping to a client
+ defined in the header include/dt-bindings/gce/<chip>-gce.h.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+
+ iommus:
+ maxItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8183-clk.h>
+ #include <dt-bindings/gce/mt8183-gce.h>
+ #include <dt-bindings/power/mt8183-power.h>
+ #include <dt-bindings/memory/mt8183-larb-port.h>
+
+ mdp3_wdma: mdp3_wdma@14006000 {
+ compatible = "mediatek,mt8183-mdp3-wdma";
+ reg = <0x14006000 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x6000 0x1000>;
+ power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_MDP_WDMA0>;
+ iommus = <&iommu>;
+ };
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes
2022-01-05 9:37 [PATCH v11 0/3] media: mediatek: support mdp3 on mt8183 platform Moudy Ho
2022-01-05 9:37 ` [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings Moudy Ho
@ 2022-01-05 9:37 ` Moudy Ho
2022-01-21 11:58 ` AngeloGioacchino Del Regno
2022-03-16 8:35 ` [PATCH v11 0/3] media: mediatek: support mdp3 on mt8183 platform AngeloGioacchino Del Regno
2 siblings, 1 reply; 12+ messages in thread
From: Moudy Ho @ 2022-01-05 9:37 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley, Laurent Pinchart,
linux-media, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Alexandre Courbot, tfiga, drinkcat, pihsun, hsinyi,
AngeloGioacchino Del Regno, Maoguang Meng, daoyuan huang,
Ping-Hsun Wu, menghui.lin, sj.huang, allen-kh.cheng, randy.wu,
moudy.ho, jason-jh.lin, roy-cw.yeh, river.cheng, srv_heupstream
Add device nodes for Media Data Path 3 (MDP3) modules.
Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 108 ++++++++++++++++++++++-
1 file changed, 107 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index ba4584faca5a..b872ef1ff6b3 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -1325,6 +1325,79 @@
mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
};
+ mdp3_rdma0: mdp3_rdma0@14001000 {
+ compatible = "mediatek,mt8183-mdp3",
+ "mediatek,mt8183-mdp3-rdma0";
+ mediatek,scp = <&scp>;
+ mediatek,mdp3-comps = "mediatek,mt8183-mdp3-dl1",
+ "mediatek,mt8183-mdp3-dl2",
+ "mediatek,mt8183-mdp3-path1",
+ "mediatek,mt8183-mdp3-path2",
+ "mediatek,mt8183-mdp3-imgi",
+ "mediatek,mt8183-mdp3-exto";
+ reg = <0 0x14001000 0 0x1000>,
+ <0 0x14000000 0 0x1000>,
+ <0 0x14005000 0 0x1000>,
+ <0 0x14006000 0 0x1000>,
+ <0 0x15020000 0 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>,
+ <&gce SUBSYS_1400XXXX 0 0x1000>,
+ <&gce SUBSYS_1400XXXX 0x5000 0x1000>,
+ <&gce SUBSYS_1400XXXX 0x6000 0x1000>,
+ <&gce SUBSYS_1502XXXX 0 0x1000>;
+ power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+ <&mmsys CLK_MM_MDP_RSZ1>,
+ <&mmsys CLK_MM_MDP_DL_TXCK>,
+ <&mmsys CLK_MM_MDP_DL_RX>,
+ <&mmsys CLK_MM_IPU_DL_TXCK>,
+ <&mmsys CLK_MM_IPU_DL_RX>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA0>;
+ mediatek,mmsys = <&mmsys>;
+ mediatek,mm-mutex = <&mutex>;
+ mediatek,mailbox-gce = <&gce>;
+ mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>,
+ <&gce 21 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 22 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 23 CMDQ_THR_PRIO_LOWEST>;
+ gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
+ <&gce 0x14010000 SUBSYS_1401XXXX>,
+ <&gce 0x14020000 SUBSYS_1402XXXX>,
+ <&gce 0x15020000 SUBSYS_1502XXXX>;
+ };
+
+ mdp3_rsz0: mdp3_rsz0@14003000 {
+ compatible = "mediatek,mt8183-mdp3-rsz0";
+ reg = <0 0x14003000 0 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x3000 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ0>;
+ };
+
+ mdp3_rsz1: mdp3_rsz1@14004000 {
+ compatible = "mediatek,mt8183-mdp3-rsz1";
+ reg = <0 0x14004000 0 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x4000 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ1>;
+ };
+
+ mdp3_wrot0: mdp3_wrot0@14005000 {
+ compatible = "mediatek,mt8183-mdp3-wrot0";
+ reg = <0 0x14005000 0 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x5000 0x1000>;
+ power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_MDP_WROT0>;
+ iommus = <&iommu M4U_PORT_MDP_WROT0>;
+ };
+
+ mdp3_wdma: mdp3_wdma@14006000 {
+ compatible = "mediatek,mt8183-mdp3-wdma";
+ reg = <0 0x14006000 0 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x6000 0x1000>;
+ power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_MDP_WDMA0>;
+ iommus = <&iommu M4U_PORT_MDP_WDMA0>;
+ };
+
ovl0: ovl@14008000 {
compatible = "mediatek,mt8183-disp-ovl";
reg = <0 0x14008000 0 0x1000>;
@@ -1449,7 +1522,33 @@
interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
mediatek,gce-events = <CMDQ_EVENT_MUTEX_STREAM_DONE0>,
- <CMDQ_EVENT_MUTEX_STREAM_DONE1>;
+ <CMDQ_EVENT_MUTEX_STREAM_DONE1>,
+ <CMDQ_EVENT_MDP_RDMA0_SOF>,
+ <CMDQ_EVENT_MDP_RDMA0_EOF>,
+ <CMDQ_EVENT_MDP_RSZ0_SOF>,
+ <CMDQ_EVENT_MDP_RSZ1_SOF>,
+ <CMDQ_EVENT_MDP_TDSHP_SOF>,
+ <CMDQ_EVENT_MDP_WROT0_SOF>,
+ <CMDQ_EVENT_MDP_WROT0_EOF>,
+ <CMDQ_EVENT_MDP_WDMA0_SOF>,
+ <CMDQ_EVENT_MDP_WDMA0_EOF>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_0>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_1>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_2>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_3>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_4>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_5>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_6>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_7>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_8>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_9>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_10>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_11>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_12>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_13>,
+ <CMDQ_EVENT_ISP_FRAME_DONE_P2_14>,
+ <CMDQ_EVENT_WPE_A_DONE>,
+ <CMDQ_EVENT_SPE_B_DONE>;
};
larb0: larb@14017000 {
@@ -1473,6 +1572,13 @@
power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
};
+ mdp3_ccorr: mdp3_ccorr@1401c000 {
+ compatible = "mediatek,mt8183-mdp3-ccorr";
+ reg = <0 0x1401c000 0 0x1000>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0xc000 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_CCORR>;
+ };
+
imgsys: syscon@15020000 {
compatible = "mediatek,mt8183-imgsys", "syscon";
reg = <0 0x15020000 0 0x1000>;
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes
2022-01-05 9:37 ` [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes Moudy Ho
@ 2022-01-21 11:58 ` AngeloGioacchino Del Regno
2022-01-25 8:20 ` moudy ho
0 siblings, 1 reply; 12+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-01-21 11:58 UTC (permalink / raw)
To: Moudy Ho, Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley, Laurent Pinchart,
linux-media, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Alexandre Courbot, tfiga, drinkcat, pihsun, hsinyi,
Maoguang Meng, daoyuan huang, Ping-Hsun Wu, menghui.lin,
sj.huang, allen-kh.cheng, randy.wu, jason-jh.lin, roy-cw.yeh,
river.cheng, srv_heupstream
Il 05/01/22 10:37, Moudy Ho ha scritto:
> Add device nodes for Media Data Path 3 (MDP3) modules.
>
> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 108 ++++++++++++++++++++++-
> 1 file changed, 107 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index ba4584faca5a..b872ef1ff6b3 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -1325,6 +1325,79 @@
> mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
> };
>
> + mdp3_rdma0: mdp3_rdma0@14001000 {
> + compatible = "mediatek,mt8183-mdp3",
> + "mediatek,mt8183-mdp3-rdma0";
> + mediatek,scp = <&scp>;
> + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-dl1",
> + "mediatek,mt8183-mdp3-dl2",
> + "mediatek,mt8183-mdp3-path1",
> + "mediatek,mt8183-mdp3-path2",
> + "mediatek,mt8183-mdp3-imgi",
> + "mediatek,mt8183-mdp3-exto";
> + reg = <0 0x14001000 0 0x1000>,
> + <0 0x14000000 0 0x1000>,
> + <0 0x14005000 0 0x1000>,
> + <0 0x14006000 0 0x1000>,
> + <0 0x15020000 0 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>,
> + <&gce SUBSYS_1400XXXX 0 0x1000>,
> + <&gce SUBSYS_1400XXXX 0x5000 0x1000>,
> + <&gce SUBSYS_1400XXXX 0x6000 0x1000>,
> + <&gce SUBSYS_1502XXXX 0 0x1000>;
> + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> + <&mmsys CLK_MM_MDP_RSZ1>,
> + <&mmsys CLK_MM_MDP_DL_TXCK>,
> + <&mmsys CLK_MM_MDP_DL_RX>,
> + <&mmsys CLK_MM_IPU_DL_TXCK>,
> + <&mmsys CLK_MM_IPU_DL_RX>;
> + iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> + mediatek,mmsys = <&mmsys>;
> + mediatek,mm-mutex = <&mutex>;
> + mediatek,mailbox-gce = <&gce>;
> + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>,
> + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
Hello Moudy,
the mboxes for gce 21, 22, 23 are missing the third cell. Please fix.
Regards,
Angelo
> + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
> + <&gce 0x14010000 SUBSYS_1401XXXX>,
> + <&gce 0x14020000 SUBSYS_1402XXXX>,
> + <&gce 0x15020000 SUBSYS_1502XXXX>;
> + };
> +
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings
2022-01-05 9:37 ` [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings Moudy Ho
@ 2022-01-21 21:16 ` Rob Herring
2022-01-24 11:40 ` AngeloGioacchino Del Regno
0 siblings, 1 reply; 12+ messages in thread
From: Rob Herring @ 2022-01-21 21:16 UTC (permalink / raw)
To: Moudy Ho
Cc: Mauro Carvalho Chehab, Matthias Brugger, Hans Verkuil,
Jernej Skrabec, Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley,
Laurent Pinchart, linux-media, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Alexandre Courbot, tfiga, drinkcat,
pihsun, hsinyi, AngeloGioacchino Del Regno, Maoguang Meng,
daoyuan huang, Ping-Hsun Wu, menghui.lin, sj.huang,
allen-kh.cheng, randy.wu, jason-jh.lin, roy-cw.yeh, river.cheng,
srv_heupstream
On Wed, Jan 05, 2022 at 05:37:56PM +0800, Moudy Ho wrote:
> This patch adds DT binding document for Media Data Path 3 (MDP3)
> a unit in multimedia system used for scaling and color format convert.
>
> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> ---
> .../bindings/media/mediatek,mdp3-rdma.yaml | 193 ++++++++++++++++++
> .../bindings/media/mediatek,mdp3-rsz.yaml | 55 +++++
> .../bindings/media/mediatek,mdp3-wrot.yaml | 57 ++++++
> .../bindings/soc/mediatek/mediatek,ccorr.yaml | 47 +++++
> .../bindings/soc/mediatek/mediatek,wdma.yaml | 58 ++++++
> 5 files changed, 410 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> new file mode 100644
> index 000000000000..002503383934
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> @@ -0,0 +1,193 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek Read Direct Memory Access
> +
> +maintainers:
> + - Matthias Brugger <matthias.bgg@gmail.com>
> +
> +description: |
> + Mediatek Read Direct Memory Access(RDMA) component used to do read DMA.
> + It contains one line buffer to store the sufficient pixel data, and
> + must be siblings to the central MMSYS_CONFIG node.
> + For a description of the MMSYS_CONFIG binding, see
> + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> + for details.
> + The 1st RDMA is also used to be a controller node in Media Data Path 3(MDP3)
> + that containing MMSYS, MUTEX, GCE and SCP settings.
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + # MDP3 controller node
> + - const: mediatek,mt8183-mdp3
How is this more specific than this:
> + - const: mediatek,mt8183-mdp3-rdma0
> + - items:
> + # normal RDMA conponent
> + - const: mediatek,mt8183-mdp3-rdma0
> +
> + mediatek,scp:
> + description: The node of system control processor (SCP), using
> + the remoteproc & rpmsg framework.
> + $ref: /schemas/types.yaml#/definitions/phandle
> + maxItems: 1
> +
> + mediatek,mdp3-comps:
> + description: MTK sub-system of direct-link or DIP
This needs a better description. What is DIP? What is direct-link?
> + $ref: /schemas/types.yaml#/definitions/string-array
> + items:
> + - enum:
> + # MDP direct-link input path selection, create a
> + # component for path connectedness of HW pipe control
> + - mediatek,mt8183-mdp3-dl1
> + - enum:
> + - mediatek,mt8183-mdp3-dl2
> + - enum:
> + # MDP direct-link output path selection, create a
> + # component for path connectedness of HW pipe control
> + - mediatek,mt8183-mdp3-path1
> + - enum:
> + - mediatek,mt8183-mdp3-path2
> + - enum:
> + # Input DMA of ISP PASS2 (DIP) module for raw image input
> + - mediatek,mt8183-mdp3-imgi
> + - enum:
> + # Output DMA of ISP PASS2 (DIP) module for YUV image output
> + - mediatek,mt8183-mdp3-exto
There's only 1 possible value for mediatek,mdp3-comps, so why does it
need to be in DT?
> +
> + reg:
> + items:
> + - description: basic RDMA HW address
> + - description: MDP direct-link 1st and 2nd input
> + - description: MDP direct-link 1st output
> + - description: MDP direct-link 2nd output
> + - description: ISP input and output
> +
> + mediatek,gce-client-reg:
> + description: The register of client driver can be configured by gce with
> + 4 arguments defined in this property, such as phandle of gce, subsys id,
> + register offset and size. Each GCE subsys id is mapping to a client
> + defined in the header include/dt-bindings/gce/<chip>-gce.h.
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - description: GCE client for RDMA
> + - description: GCR client for MDP direct-link 1st and 2nd input
> + - description: GCR client for MDP direct-link 1st output
> + - description: GCR client for MDP direct-link 2nd output
> + - description: GCR client for ISP input and output
> +
> + power-domains:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: RDMA clock
> + - description: RSZ clock
> + - description: direck-link TX clock in MDP side
> + - description: direck-link RX clock in MDP side
> + - description: direck-link TX clock in ISP side
> + - description: direck-link RX clock in ISP side
> +
> + iommus:
> + maxItems: 1
> +
> + mediatek,mmsys:
> + description: The node of mux(multiplexer) controller for HW connections.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> + mediatek,mm-mutex:
Is this some sort of h/w lock? We have a standard binding for that.
> + description: The node of sof(start of frame) signal controller.
> + $ref: /schemas/types.yaml#/definitions/phandle
> + maxItems: 1
> +
> + mediatek,mailbox-gce:
> + description: The node of global command engine (GCE), used to read/write
> + registers with critical time limitation.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> + mboxes:
> + items:
> + - description: used for 1st data pipe from RDMA
> + - description: used for 2nd data pipe from RDMA
> + - description: used for 3rd data pipe from Direct-Link
> + - description: used for 4th data pipe from Direct-Link
> +
> + gce-subsys:
> + description: sub-system id corresponding to the global command engine (GCE)
> + register address.
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +if:
> + properties:
> + compatible:
> + contains:
> + const: mediatek,mt8183-mdp3
> +
> +then:
> + required:
> + - mediatek,scp
> + - mediatek,mmsys
> + - mediatek,mm-mutex
> + - mediatek,mailbox-gce
> + - mboxes
> + - gce-subsys
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - mediatek,gce-client-reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/mt8183-clk.h>
> + #include <dt-bindings/gce/mt8183-gce.h>
> + #include <dt-bindings/power/mt8183-power.h>
> + #include <dt-bindings/memory/mt8183-larb-port.h>
> +
> + mdp3_rdma0: mdp3_rdma0@14001000 {
> + compatible = "mediatek,mt8183-mdp3",
> + "mediatek,mt8183-mdp3-rdma0";
> + mediatek,scp = <&scp>;
> + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-dl1",
> + "mediatek,mt8183-mdp3-dl2",
> + "mediatek,mt8183-mdp3-path1",
> + "mediatek,mt8183-mdp3-path2",
> + "mediatek,mt8183-mdp3-imgi",
> + "mediatek,mt8183-mdp3-exto";
> + reg = <0x14001000 0x1000>,
> + <0x14000000 0x1000>,
> + <0x14005000 0x1000>,
> + <0x14006000 0x1000>,
> + <0x15020000 0x1000>;
> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>,
> + <&gce SUBSYS_1400XXXX 0 0x1000>,
> + <&gce SUBSYS_1400XXXX 0x5000 0x1000>,
> + <&gce SUBSYS_1400XXXX 0x6000 0x1000>,
> + <&gce SUBSYS_1502XXXX 0 0x1000>;
> + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> + <&mmsys CLK_MM_MDP_RSZ1>,
> + <&mmsys CLK_MM_MDP_DL_TXCK>,
> + <&mmsys CLK_MM_MDP_DL_RX>,
> + <&mmsys CLK_MM_IPU_DL_TXCK>,
> + <&mmsys CLK_MM_IPU_DL_RX>;
> + iommus = <&iommu>;
> + mediatek,mmsys = <&mmsys>;
> + mediatek,mm-mutex = <&mutex>;
> + mediatek,mailbox-gce = <&gce>;
> + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
> + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
> + <&gce 0x14010000 SUBSYS_1401XXXX>,
> + <&gce 0x14020000 SUBSYS_1402XXXX>,
> + <&gce 0x15020000 SUBSYS_1502XXXX>;
> + };
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
> new file mode 100644
> index 000000000000..cd4cf1531535
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/mediatek,mdp3-rsz.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek Resizer
> +
> +maintainers:
> + - Matthias Brugger <matthias.bgg@gmail.com>
> +
> +description: |
> + One of Media Data Path 3 (MDP3) components used to do frame resizing.
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - mediatek,mt8183-mdp3-rsz0
> + - mediatek,mt8183-mdp3-rsz1
Again, what's the difference between 0 and 1?
I've probably asked that before, but without a sufficient reasoning
here in the schema I'm just going to keep asking the same question.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings
2022-01-21 21:16 ` Rob Herring
@ 2022-01-24 11:40 ` AngeloGioacchino Del Regno
2022-01-26 10:24 ` moudy.ho
0 siblings, 1 reply; 12+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-01-24 11:40 UTC (permalink / raw)
To: Rob Herring, Moudy Ho
Cc: Mauro Carvalho Chehab, Matthias Brugger, Hans Verkuil,
Jernej Skrabec, Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley,
Laurent Pinchart, linux-media, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Alexandre Courbot, tfiga, drinkcat,
pihsun, hsinyi, Maoguang Meng, daoyuan huang, Ping-Hsun Wu,
menghui.lin, sj.huang, allen-kh.cheng, randy.wu, jason-jh.lin,
roy-cw.yeh, river.cheng, srv_heupstream
Il 21/01/22 22:16, Rob Herring ha scritto:
> On Wed, Jan 05, 2022 at 05:37:56PM +0800, Moudy Ho wrote:
Hello Rob,
since I'm not the best at reviewing dt-bindings, I always try to leave that to
other reviewers; in which case, thank you for your awesome review activity on
all of these (and helping me a lot on some of my attempts to write yaml..!!)
In this case, though, since I do have knowledge about the platform, it's probably
worth for me to try to address some of your questions, on at least this one.
>> This patch adds DT binding document for Media Data Path 3 (MDP3)
>> a unit in multimedia system used for scaling and color format convert.
>>
>> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
>> ---
>> .../bindings/media/mediatek,mdp3-rdma.yaml | 193 ++++++++++++++++++
>> .../bindings/media/mediatek,mdp3-rsz.yaml | 55 +++++
>> .../bindings/media/mediatek,mdp3-wrot.yaml | 57 ++++++
>> .../bindings/soc/mediatek/mediatek,ccorr.yaml | 47 +++++
>> .../bindings/soc/mediatek/mediatek,wdma.yaml | 58 ++++++
>> 5 files changed, 410 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
>> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
>> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
>> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yaml
>> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
>> new file mode 100644
>> index 000000000000..002503383934
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
>> @@ -0,0 +1,193 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Mediatek Read Direct Memory Access
>> +
>> +maintainers:
>> + - Matthias Brugger <matthias.bgg@gmail.com>
>> +
>> +description: |
>> + Mediatek Read Direct Memory Access(RDMA) component used to do read DMA.
>> + It contains one line buffer to store the sufficient pixel data, and
>> + must be siblings to the central MMSYS_CONFIG node.
>> + For a description of the MMSYS_CONFIG binding, see
>> + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
>> + for details.
>> + The 1st RDMA is also used to be a controller node in Media Data Path 3(MDP3)
>> + that containing MMSYS, MUTEX, GCE and SCP settings.
>> +
>> +properties:
>> + compatible:
>> + oneOf:
>> + - items:
>> + # MDP3 controller node
>> + - const: mediatek,mt8183-mdp3
>
> How is this more specific than this:
>
>> + - const: mediatek,mt8183-mdp3-rdma0
>
Probably, oneOf is not the right choice here... "mediatek,mt8183-mdp3" is needed
to probe the "main" mdp3 core pdev, while RDMA0 is a necessary component (as in
this driver uses the component framework, and rdma0 is required for functionality,
as far as I understand).
This shouldn't be a choice, meaning that defining mdp3-rdma0 without mdp3 is
completely useless, as there wouldn't be anything else initializing that component,
nor sub-components of that.
>> + - items:
>> + # normal RDMA conponent
>> + - const: mediatek,mt8183-mdp3-rdma0
>> +
>> + mediatek,scp:
>> + description: The node of system control processor (SCP), using
>> + the remoteproc & rpmsg framework.
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + maxItems: 1
>> +
>> + mediatek,mdp3-comps:
>> + description: MTK sub-system of direct-link or DIP
>
> This needs a better description. What is DIP? What is direct-link?
I agree, this needs a better description.
>
>> + $ref: /schemas/types.yaml#/definitions/string-array
>> + items:
>> + - enum:
>> + # MDP direct-link input path selection, create a
>> + # component for path connectedness of HW pipe control
>> + - mediatek,mt8183-mdp3-dl1
>> + - enum:
>> + - mediatek,mt8183-mdp3-dl2
>> + - enum:
>> + # MDP direct-link output path selection, create a
>> + # component for path connectedness of HW pipe control
>> + - mediatek,mt8183-mdp3-path1
>> + - enum:
>> + - mediatek,mt8183-mdp3-path2
>> + - enum:
>> + # Input DMA of ISP PASS2 (DIP) module for raw image input
>> + - mediatek,mt8183-mdp3-imgi
>> + - enum:
>> + # Output DMA of ISP PASS2 (DIP) module for YUV image output
>> + - mediatek,mt8183-mdp3-exto
>
> There's only 1 possible value for mediatek,mdp3-comps, so why does it
> need to be in DT?
>
The wanted logic here (I believe) is that, depending on firmware capabilities
and/or platform/board capabilities, you may miss some subcomponents like IMGI
and/or EXTO.
As for DL1/2 and PATH1/2... DL1+PATH1 is surely critically necessary for the
functionality of the MDP3 RDMA... I don't know whether it's possible that we
get any fw/platform/device that's not using DL2/PATH2 at all.
Moudy, can you please explain?
>> +
>> + reg:
>> + items:
>> + - description: basic RDMA HW address
>> + - description: MDP direct-link 1st and 2nd input
>> + - description: MDP direct-link 1st output
>> + - description: MDP direct-link 2nd output
>> + - description: ISP input and output
>> +
>> + mediatek,gce-client-reg:
>> + description: The register of client driver can be configured by gce with
>> + 4 arguments defined in this property, such as phandle of gce, subsys id,
>> + register offset and size. Each GCE subsys id is mapping to a client
>> + defined in the header include/dt-bindings/gce/<chip>-gce.h.
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + - description: GCE client for RDMA
>> + - description: GCR client for MDP direct-link 1st and 2nd input
>> + - description: GCR client for MDP direct-link 1st output
>> + - description: GCR client for MDP direct-link 2nd output
>> + - description: GCR client for ISP input and output
>> +
>> + power-domains:
>> + maxItems: 1
>> +
>> + clocks:
>> + items:
>> + - description: RDMA clock
>> + - description: RSZ clock
>> + - description: direck-link TX clock in MDP side
>> + - description: direck-link RX clock in MDP side
>> + - description: direck-link TX clock in ISP side
>> + - description: direck-link RX clock in ISP side
>> +
>> + iommus:
>> + maxItems: 1
>> +
>> + mediatek,mmsys:
>> + description: The node of mux(multiplexer) controller for HW connections.
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> +
>> + mediatek,mm-mutex:
>
> Is this some sort of h/w lock? We have a standard binding for that.
>
There's a story behind that one: this was part of mtk (display) DRM drivers, then
it was moved to soc/mediatek/mtk-mutex.c as it started being shared.
I wonder if the mm-mutex can be rewritten and moved to hwspinlock... this driver
is growing and now, with the introduction of MDP3, we're seeing some more.
Though, it's definitely worth mentioning that the usage of MediaTek's mm-mutex is
varying a bit between the drm case and the mdp3 case as, here, we have a "command
queue" mechanism that is used for commands ordering in HW.
This is a very complex architecture that has very specific requirements.
For how I see it, migrating that to hwspinlock would require an almost complete
reimplementation of soc/mediatek/*, which would take a considerable amount of
time and efforts.
I'm mostly sure that I can help with that, but for how things are looking right
now, between refactoring, getting code solid, going through sane reviews and a
final merge, I'd say that this will take 8-12 months from now.
For this reason, I would propose to perform a slow and steady migration of the
MediaTek mmsys, scpsys, mutex over time, but only after getting in the support
for the new SoCs and functionality for the older ones, provided in this series
and some others that were already sent by MTK, half (or more) of which have
already been merged.
>> + description: The node of sof(start of frame) signal controller.
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + maxItems: 1
>> +
>> + mediatek,mailbox-gce:
>> + description: The node of global command engine (GCE), used to read/write
>> + registers with critical time limitation.
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> +
>> + mboxes:
>> + items:
>> + - description: used for 1st data pipe from RDMA
>> + - description: used for 2nd data pipe from RDMA
>> + - description: used for 3rd data pipe from Direct-Link
>> + - description: used for 4th data pipe from Direct-Link
>> +
>> + gce-subsys:
>> + description: sub-system id corresponding to the global command engine (GCE)
>> + register address.
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> +
>> +if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: mediatek,mt8183-mdp3
>> +
>> +then:
>> + required:
>> + - mediatek,scp
>> + - mediatek,mmsys
>> + - mediatek,mm-mutex
>> + - mediatek,mailbox-gce
>> + - mboxes
>> + - gce-subsys
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> + - mediatek,gce-client-reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/clock/mt8183-clk.h>
>> + #include <dt-bindings/gce/mt8183-gce.h>
>> + #include <dt-bindings/power/mt8183-power.h>
>> + #include <dt-bindings/memory/mt8183-larb-port.h>
>> +
>> + mdp3_rdma0: mdp3_rdma0@14001000 {
>> + compatible = "mediatek,mt8183-mdp3",
>> + "mediatek,mt8183-mdp3-rdma0";
>> + mediatek,scp = <&scp>;
>> + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-dl1",
>> + "mediatek,mt8183-mdp3-dl2",
>> + "mediatek,mt8183-mdp3-path1",
>> + "mediatek,mt8183-mdp3-path2",
>> + "mediatek,mt8183-mdp3-imgi",
>> + "mediatek,mt8183-mdp3-exto";
>> + reg = <0x14001000 0x1000>,
>> + <0x14000000 0x1000>,
>> + <0x14005000 0x1000>,
>> + <0x14006000 0x1000>,
>> + <0x15020000 0x1000>;
>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000 0x1000>,
>> + <&gce SUBSYS_1400XXXX 0 0x1000>,
>> + <&gce SUBSYS_1400XXXX 0x5000 0x1000>,
>> + <&gce SUBSYS_1400XXXX 0x6000 0x1000>,
>> + <&gce SUBSYS_1502XXXX 0 0x1000>;
>> + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
>> + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
>> + <&mmsys CLK_MM_MDP_RSZ1>,
>> + <&mmsys CLK_MM_MDP_DL_TXCK>,
>> + <&mmsys CLK_MM_MDP_DL_RX>,
>> + <&mmsys CLK_MM_IPU_DL_TXCK>,
>> + <&mmsys CLK_MM_IPU_DL_RX>;
>> + iommus = <&iommu>;
>> + mediatek,mmsys = <&mmsys>;
>> + mediatek,mm-mutex = <&mutex>;
>> + mediatek,mailbox-gce = <&gce>;
>> + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
>> + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
>> + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
>> + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
>> + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
>> + <&gce 0x14010000 SUBSYS_1401XXXX>,
>> + <&gce 0x14020000 SUBSYS_1402XXXX>,
>> + <&gce 0x15020000 SUBSYS_1502XXXX>;
>> + };
>> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
>> new file mode 100644
>> index 000000000000..cd4cf1531535
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
>> @@ -0,0 +1,55 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/mediatek,mdp3-rsz.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Mediatek Resizer
>> +
>> +maintainers:
>> + - Matthias Brugger <matthias.bgg@gmail.com>
>> +
>> +description: |
>> + One of Media Data Path 3 (MDP3) components used to do frame resizing.
>> +
>> +properties:
>> + compatible:
>> + items:
>> + - enum:
>> + - mediatek,mt8183-mdp3-rsz0
>> + - mediatek,mt8183-mdp3-rsz1
>
> Again, what's the difference between 0 and 1?
>
> I've probably asked that before, but without a sufficient reasoning
> here in the schema I'm just going to keep asking the same question.
This can probably be, instead, something like
compatible = "mediatek,mt8183-mdp3-rsz";
reg = < .... >;
mediatek,instance-id = <0>;
gce reg, clocks, blah...
or
compatible = "mediatek,mt8183-mdp3-rsz";
reg = < ...rsz0... >, < ...rsz1... >;
reg-names = "rsz0", "rsz1";
gce reg, clocks, blah...
...In any case, if MediaTek chose to separate these like that, I guess that
there will be differences in newer SoCs that would make that kind of binding
much necessary.
Please Moudy, can you explain why you didn't write that like the examples
that I provided there?
>
> Rob
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes
2022-01-21 11:58 ` AngeloGioacchino Del Regno
@ 2022-01-25 8:20 ` moudy ho
2022-01-27 10:57 ` AngeloGioacchino Del Regno
0 siblings, 1 reply; 12+ messages in thread
From: moudy ho @ 2022-01-25 8:20 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Hans Verkuil, Jernej Skrabec
Cc: Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley, Laurent Pinchart,
linux-media, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Alexandre Courbot, tfiga, drinkcat, pihsun, hsinyi,
Maoguang Meng, daoyuan huang, Ping-Hsun Wu, menghui.lin,
sj.huang, allen-kh.cheng, randy.wu, jason-jh.lin, roy-cw.yeh,
river.cheng, srv_heupstream
On Fri, 2022-01-21 at 12:58 +0100, AngeloGioacchino Del Regno wrote:
> Il 05/01/22 10:37, Moudy Ho ha scritto:
> > Add device nodes for Media Data Path 3 (MDP3) modules.
> >
> > Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> > ---
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 108
> > ++++++++++++++++++++++-
> > 1 file changed, 107 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > index ba4584faca5a..b872ef1ff6b3 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> > @@ -1325,6 +1325,79 @@
> > mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX
> > 0 0x1000>;
> > };
> >
> > + mdp3_rdma0: mdp3_rdma0@14001000 {
> > + compatible = "mediatek,mt8183-mdp3",
> > + "mediatek,mt8183-mdp3-rdma0";
> > + mediatek,scp = <&scp>;
> > + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-
> > dl1",
> > + "mediatek,mt8183-mdp3-
> > dl2",
> > + "mediatek,mt8183-mdp3-
> > path1",
> > + "mediatek,mt8183-mdp3-
> > path2",
> > + "mediatek,mt8183-mdp3-
> > imgi",
> > + "mediatek,mt8183-mdp3-
> > exto";
> > + reg = <0 0x14001000 0 0x1000>,
> > + <0 0x14000000 0 0x1000>,
> > + <0 0x14005000 0 0x1000>,
> > + <0 0x14006000 0 0x1000>,
> > + <0 0x15020000 0 0x1000>;
> > + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX
> > 0x1000 0x1000>,
> > + <&gce SUBSYS_1400XXXX
> > 0 0x1000>,
> > + <&gce SUBSYS_1400XXXX
> > 0x5000 0x1000>,
> > + <&gce SUBSYS_1400XXXX
> > 0x6000 0x1000>,
> > + <&gce SUBSYS_1502XXXX
> > 0 0x1000>;
> > + power-domains = <&spm
> > MT8183_POWER_DOMAIN_DISP>;
> > + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> > + <&mmsys CLK_MM_MDP_RSZ1>,
> > + <&mmsys CLK_MM_MDP_DL_TXCK>,
> > + <&mmsys CLK_MM_MDP_DL_RX>,
> > + <&mmsys CLK_MM_IPU_DL_TXCK>,
> > + <&mmsys CLK_MM_IPU_DL_RX>;
> > + iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> > + mediatek,mmsys = <&mmsys>;
> > + mediatek,mm-mutex = <&mutex>;
> > + mediatek,mailbox-gce = <&gce>;
> > + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>,
> > + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
> > + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
> > + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
>
> Hello Moudy,
> the mboxes for gce 21, 22, 23 are missing the third cell. Please fix.
>
> Regards,
> Angelo
Hi Angelo,
Thanks for the reminder, but I'm a bit confused, the previous
version(v10) mentioned that the current upstream mbox has only 2
cells.
So I should follow this rule to remove the extra 0 in the first item as
follows:
+ mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 21 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 22 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 23 CMDQ_THR_PRIO_LOWEST>;
Thanks,
Moudy Ho
>
> > + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
> > + <&gce 0x14010000 SUBSYS_1401XXXX>,
> > + <&gce 0x14020000 SUBSYS_1402XXXX>,
> > + <&gce 0x15020000 SUBSYS_1502XXXX>;
> > + };
> > +
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings
2022-01-24 11:40 ` AngeloGioacchino Del Regno
@ 2022-01-26 10:24 ` moudy.ho
2022-02-21 7:47 ` moudy.ho
0 siblings, 1 reply; 12+ messages in thread
From: moudy.ho @ 2022-01-26 10:24 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, Rob Herring
Cc: Mauro Carvalho Chehab, Matthias Brugger, Hans Verkuil,
Jernej Skrabec, Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley,
Laurent Pinchart, linux-media, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Alexandre Courbot, tfiga, drinkcat,
pihsun, hsinyi, Maoguang Meng, daoyuan huang, Ping-Hsun Wu,
menghui.lin, sj.huang, allen-kh.cheng, randy.wu, jason-jh.lin,
roy-cw.yeh, river.cheng, srv_heupstream
On Mon, 2022-01-24 at 12:40 +0100, AngeloGioacchino Del Regno wrote:
> Il 21/01/22 22:16, Rob Herring ha scritto:
> > On Wed, Jan 05, 2022 at 05:37:56PM +0800, Moudy Ho wrote:
>
> Hello Rob,
>
> since I'm not the best at reviewing dt-bindings, I always try to
> leave that to
>
> other reviewers; in which case, thank you for your awesome review
> activity on
>
> all of these (and helping me a lot on some of my attempts to write
> yaml..!!)
>
>
> In this case, though, since I do have knowledge about the platform,
> it's probably
> worth for me to try to address some of your questions, on at least
> this one.
>
>
> > > This patch adds DT binding document for Media Data Path 3 (MDP3)
> > > a unit in multimedia system used for scaling and color format
> > > convert.
> > >
> > > Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> > > ---
> > > .../bindings/media/mediatek,mdp3-rdma.yaml | 193
> > > ++++++++++++++++++
> > > .../bindings/media/mediatek,mdp3-rsz.yaml | 55 +++++
> > > .../bindings/media/mediatek,mdp3-wrot.yaml | 57 ++++++
> > > .../bindings/soc/mediatek/mediatek,ccorr.yaml | 47 +++++
> > > .../bindings/soc/mediatek/mediatek,wdma.yaml | 58 ++++++
> > > 5 files changed, 410 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> > > create mode 100644
> > > Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
> > > create mode 100644
> > > Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
> > > create mode 100644
> > > Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.yam
> > > l
> > > create mode 100644
> > > Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> > > b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> > > new file mode 100644
> > > index 000000000000..002503383934
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > rdma.yaml
> > > @@ -0,0 +1,193 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > https://urldefense.com/v3/__http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtt5fpkQb$
> > >
> > > +$schema:
> > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtk8-fzFI$
> > >
> > > +
> > > +title: Mediatek Read Direct Memory Access
> > > +
> > > +maintainers:
> > > + - Matthias Brugger <matthias.bgg@gmail.com>
> > > +
> > > +description: |
> > > + Mediatek Read Direct Memory Access(RDMA) component used to do
> > > read DMA.
> > > + It contains one line buffer to store the sufficient pixel
> > > data, and
> > > + must be siblings to the central MMSYS_CONFIG node.
> > > + For a description of the MMSYS_CONFIG binding, see
> > > + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.
> > > yaml
> > > + for details.
> > > + The 1st RDMA is also used to be a controller node in Media
> > > Data Path 3(MDP3)
> > > + that containing MMSYS, MUTEX, GCE and SCP settings.
> > > +
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - items:
> > > + # MDP3 controller node
> > > + - const: mediatek,mt8183-mdp3
> >
> > How is this more specific than this:
> >
> > > + - const: mediatek,mt8183-mdp3-rdma0
>
> Probably, oneOf is not the right choice here... "mediatek,mt8183-
> mdp3" is needed
> to probe the "main" mdp3 core pdev, while RDMA0 is a necessary
> component (as in
> this driver uses the component framework, and rdma0 is required for
> functionality,
> as far as I understand).
>
> This shouldn't be a choice, meaning that defining mdp3-rdma0 without
> mdp3 is
> completely useless, as there wouldn't be anything else initializing
> that component,
> nor sub-components of that.
>
Hi Rob and Angelo,
Sorry for the incomplete description here, I originally planned to add
a compatible name here in the future when the chip has multiple RDMAs.
Since 8183 currently has only one RDMA, the above design expression is
incorrect and should be rewritten as follows:
[8183]
properties:
compatible:
items:
# MDP3 controller node
- const: mediatek,mt8183-mdp3
- const: mediatek,mt8195-mdp3-rdma0
[8195]
properties:
compatible:
oneOf:
- items:
# MDP3 controller node
- const: mediatek,mt8183-mdp3
- const: mediatek,mt8195-mdp3-rdma0
- items:
# normal RDMA conponent
- const: mediatek,mt8195-mdp3-rdma1
- items:
# normal RDMA conponent
- const: mediatek,mt8195-mdp3-rdma2
- items:
# normal RDMA conponent
- const: mediatek,mt8195-mdp3-rdma3
> > > + - items:
> > > + # normal RDMA conponent
> > > + - const: mediatek,mt8183-mdp3-rdma0
> > > +
> > > + mediatek,scp:
> > > + description: The node of system control processor (SCP),
> > > using
> > > + the remoteproc & rpmsg framework.
> > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > + maxItems: 1
> > > +
> > > + mediatek,mdp3-comps:
> > > + description: MTK sub-system of direct-link or DIP
> >
> > This needs a better description. What is DIP? What is direct-link?
>
> I agree, this needs a better description.
>
I tried to modify the description as follows, could you help to see if
there is anything confusing:
mediatek,mdp3-comps:
description:
MDP subsystem which has direct-link from Image Signal
Processor(ISP).
When using the camera, the DMA of ISP PASS (DIP) module will
directly trigger MDP3 without other control (such as V4L2 M2M) to
create corresponding HW path.
The MDP3 controller must set up a series of registers at the
beginning of path creation which covering MMSYS, IMGSYS, and MDP3's
components, so that data flow can pass through MDP3.
The entire path is briefly described as follows:
DIP : ISP ->
MDP3 : IMGI -> DL -> CCORR(optional) -> RSZ -> PATH_OUT ->
WDMA/WROT
> >
> > > + $ref: /schemas/types.yaml#/definitions/string-array
> > > + items:
> > > + - enum:
> > > + # MDP direct-link input path selection, create a
> > > + # component for path connectedness of HW pipe control
> > > + - mediatek,mt8183-mdp3-dl1
> > > + - enum:
> > > + - mediatek,mt8183-mdp3-dl2
> > > + - enum:
> > > + # MDP direct-link output path selection, create a
> > > + # component for path connectedness of HW pipe control
> > > + - mediatek,mt8183-mdp3-path1
> > > + - enum:
> > > + - mediatek,mt8183-mdp3-path2
> > > + - enum:
> > > + # Input DMA of ISP PASS2 (DIP) module for raw image
> > > input
> > > + - mediatek,mt8183-mdp3-imgi
> > > + - enum:
> > > + # Output DMA of ISP PASS2 (DIP) module for YUV image
> > > output
> > > + - mediatek,mt8183-mdp3-exto
> >
> > There's only 1 possible value for mediatek,mdp3-comps, so why does
> > it
> > need to be in DT?
> >
>
> The wanted logic here (I believe) is that, depending on firmware
> capabilities
> and/or platform/board capabilities, you may miss some subcomponents
> like IMGI
> and/or EXTO.
> As for DL1/2 and PATH1/2... DL1+PATH1 is surely critically necessary
> for the
> functionality of the MDP3 RDMA... I don't know whether it's possible
> that we
> get any fw/platform/device that's not using DL2/PATH2 at all.
>
> Moudy, can you please explain?
>
Hi Angelo,
Thanks for your help and your assumptions are correct.
In further chips(such as 8195), IMGI will be replaced by WPE, and
PATH_OUT will be removed, and DL will be expanded to 6 (implicit number
of direct-link from ISP paths).
For this variable hardware design, not sure how to flexibly describe
in dt-bindings to meet futher requirements.
It should be that I got wrong with the definition of "enum", should
it be rewritten as follows in 8183?
items:
- enum:
# MDP direct-link input path selection, create a
# component for path connectedness of HW pipe control
- mediatek,mt8183-mdp3-dl1
- mediatek,mt8183-mdp3-dl2
# MDP direct-link output path selection, create a
# component for path connectedness of HW pipe control
- mediatek,mt8183-mdp3-path1
- mediatek,mt8183-mdp3-path2
# Input DMA of ISP PASS2 (DIP) module for raw image input
- mediatek,mt8183-mdp3-imgi
# Output DMA of ISP PASS2 (DIP) module for YUV image output
- mediatek,mt8183-mdp3-exto
items: (8195)
snip....
items: (8192)
snip...
> > > +
> > > + reg:
> > > + items:
> > > + - description: basic RDMA HW address
> > > + - description: MDP direct-link 1st and 2nd input
> > > + - description: MDP direct-link 1st output
> > > + - description: MDP direct-link 2nd output
> > > + - description: ISP input and output
> > > +
> > > + mediatek,gce-client-reg:
> > > + description: The register of client driver can be configured
> > > by gce with
> > > + 4 arguments defined in this property, such as phandle of
> > > gce, subsys id,
> > > + register offset and size. Each GCE subsys id is mapping to
> > > a client
> > > + defined in the header include/dt-bindings/gce/<chip>-
> > > gce.h.
> > > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > > + items:
> > > + - description: GCE client for RDMA
> > > + - description: GCR client for MDP direct-link 1st and 2nd
> > > input
> > > + - description: GCR client for MDP direct-link 1st output
> > > + - description: GCR client for MDP direct-link 2nd output
> > > + - description: GCR client for ISP input and output
> > > +
> > > + power-domains:
> > > + maxItems: 1
> > > +
> > > + clocks:
> > > + items:
> > > + - description: RDMA clock
> > > + - description: RSZ clock
> > > + - description: direck-link TX clock in MDP side
> > > + - description: direck-link RX clock in MDP side
> > > + - description: direck-link TX clock in ISP side
> > > + - description: direck-link RX clock in ISP side
> > > +
> > > + iommus:
> > > + maxItems: 1
> > > +
> > > + mediatek,mmsys:
> > > + description: The node of mux(multiplexer) controller for HW
> > > connections.
> > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > +
> > > + mediatek,mm-mutex:
> >
> > Is this some sort of h/w lock? We have a standard binding for that.
> >
>
> There's a story behind that one: this was part of mtk (display) DRM
> drivers, then
> it was moved to soc/mediatek/mtk-mutex.c as it started being shared.
>
> I wonder if the mm-mutex can be rewritten and moved to hwspinlock...
> this driver
> is growing and now, with the introduction of MDP3, we're seeing some
> more.
>
> Though, it's definitely worth mentioning that the usage of MediaTek's
> mm-mutex is
> varying a bit between the drm case and the mdp3 case as, here, we
> have a "command
> queue" mechanism that is used for commands ordering in HW.
> This is a very complex architecture that has very specific
> requirements.
> For how I see it, migrating that to hwspinlock would require an
> almost complete
> reimplementation of soc/mediatek/*, which would take a considerable
> amount of
> time and efforts.
> I'm mostly sure that I can help with that, but for how things are
> looking right
>
> now, between refactoring, getting code solid, going through sane
> reviews and a
> final merge, I'd say that this will take 8-12 months from now.
>
> For this reason, I would propose to perform a slow and steady
> migration of the
> MediaTek mmsys, scpsys, mutex over time, but only after getting in
> the support
> for the new SoCs and functionality for the older ones, provided in
> this series
> and some others that were already sent by MTK, half (or more) of
> which have
> already been merged.
Sorry for the misunderstanding caused by the name, the original mtk-
mutex design did have the ability to lock registers, but that has since
been removed but the name continues.
It's not one of those h/w locks like spinlock, semaphore, or mutex
but is just designed to send signals to trigger h/w components to get
or send data.
> > > + description: The node of sof(start of frame) signal
> > > controller.
> > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > + maxItems: 1
> > > +
> > > + mediatek,mailbox-gce:
> > > + description: The node of global command engine (GCE), used
> > > to read/write
> > > + registers with critical time limitation.
> > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > +
> > > + mboxes:
> > > + items:
> > > + - description: used for 1st data pipe from RDMA
> > > + - description: used for 2nd data pipe from RDMA
> > > + - description: used for 3rd data pipe from Direct-Link
> > > + - description: used for 4th data pipe from Direct-Link
> > > +
> > > + gce-subsys:
> > > + description: sub-system id corresponding to the global
> > > command engine (GCE)
> > > + register address.
> > > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > > +
> > > +if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + const: mediatek,mt8183-mdp3
> > > +
> > > +then:
> > > + required:
> > > + - mediatek,scp
> > > + - mediatek,mmsys
> > > + - mediatek,mm-mutex
> > > + - mediatek,mailbox-gce
> > > + - mboxes
> > > + - gce-subsys
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - clocks
> > > + - mediatek,gce-client-reg
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > + #include <dt-bindings/gce/mt8183-gce.h>
> > > + #include <dt-bindings/power/mt8183-power.h>
> > > + #include <dt-bindings/memory/mt8183-larb-port.h>
> > > +
> > > + mdp3_rdma0: mdp3_rdma0@14001000 {
> > > + compatible = "mediatek,mt8183-mdp3",
> > > + "mediatek,mt8183-mdp3-rdma0";
> > > + mediatek,scp = <&scp>;
> > > + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-dl1",
> > > + "mediatek,mt8183-mdp3-dl2",
> > > + "mediatek,mt8183-mdp3-path1",
> > > + "mediatek,mt8183-mdp3-path2",
> > > + "mediatek,mt8183-mdp3-imgi",
> > > + "mediatek,mt8183-mdp3-exto";
> > > + reg = <0x14001000 0x1000>,
> > > + <0x14000000 0x1000>,
> > > + <0x14005000 0x1000>,
> > > + <0x14006000 0x1000>,
> > > + <0x15020000 0x1000>;
> > > + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000
> > > 0x1000>,
> > > + <&gce SUBSYS_1400XXXX 0 0x1000>,
> > > + <&gce SUBSYS_1400XXXX 0x5000
> > > 0x1000>,
> > > + <&gce SUBSYS_1400XXXX 0x6000
> > > 0x1000>,
> > > + <&gce SUBSYS_1502XXXX 0 0x1000>;
> > > + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> > > + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> > > + <&mmsys CLK_MM_MDP_RSZ1>,
> > > + <&mmsys CLK_MM_MDP_DL_TXCK>,
> > > + <&mmsys CLK_MM_MDP_DL_RX>,
> > > + <&mmsys CLK_MM_IPU_DL_TXCK>,
> > > + <&mmsys CLK_MM_IPU_DL_RX>;
> > > + iommus = <&iommu>;
> > > + mediatek,mmsys = <&mmsys>;
> > > + mediatek,mm-mutex = <&mutex>;
> > > + mediatek,mailbox-gce = <&gce>;
> > > + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
> > > + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
> > > + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
> > > + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
> > > + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
> > > + <&gce 0x14010000 SUBSYS_1401XXXX>,
> > > + <&gce 0x14020000 SUBSYS_1402XXXX>,
> > > + <&gce 0x15020000 SUBSYS_1502XXXX>;
> > > + };
> > > diff --git
> > > a/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
> > > b/Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
> > > new file mode 100644
> > > index 000000000000..cd4cf1531535
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > rsz.yaml
> > > @@ -0,0 +1,55 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > https://urldefense.com/v3/__http://devicetree.org/schemas/media/mediatek,mdp3-rsz.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtoNRPuZQ$
> > >
> > > +$schema:
> > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtk8-fzFI$
> > >
> > > +
> > > +title: Mediatek Resizer
> > > +
> > > +maintainers:
> > > + - Matthias Brugger <matthias.bgg@gmail.com>
> > > +
> > > +description: |
> > > + One of Media Data Path 3 (MDP3) components used to do frame
> > > resizing.
> > > +
> > > +properties:
> > > + compatible:
> > > + items:
> > > + - enum:
> > > + - mediatek,mt8183-mdp3-rsz0
> > > + - mediatek,mt8183-mdp3-rsz1
> >
> > Again, what's the difference between 0 and 1?
> >
> > I've probably asked that before, but without a sufficient reasoning
> > here in the schema I'm just going to keep asking the same question.
>
> This can probably be, instead, something like
>
> compatible = "mediatek,mt8183-mdp3-rsz";
> reg = < .... >;
> mediatek,instance-id = <0>;
> gce reg, clocks, blah...
>
> or
>
> compatible = "mediatek,mt8183-mdp3-rsz";
> reg = < ...rsz0... >, < ...rsz1... >;
> reg-names = "rsz0", "rsz1";
> gce reg, clocks, blah...
>
>
> ...In any case, if MediaTek chose to separate these like that, I
> guess that
> there will be differences in newer SoCs that would make that kind of
> binding
> much necessary.
>
> Please Moudy, can you explain why you didn't write that like the
> examples
> that I provided there?
Before version 10 it was written the same way as the first form Angelo
mentioned - with h/w indexed properties, but Rob thinks it's bad idea.
At that time I asked Rob if it could be rewritten into its current V11
form, but I updated before I got a suggestion.
Apologize for the inconvenience casued by my careless handling.
In the 8183 MDP3, only RSZ is configured with 2 sets. The 1st set
upstream can have quality adjustment components (like AAL or CCORR or
both) connected, but the 2nd set does not.
Although those two RSZ components have the same hardware function but
register address. The MDP paths with different functions will be
created due to the different upstream and downstream connections.
In addition to the various upstream/downstream connection methods
caused by chip design, the above conditions are also dynamically
determined according to the current usage scenario(with or without PQ,
rotation...etc).
Also, considering that multiple paths are used at the same time, MDP3
will need to know which components are currently available for
dispatch.
At present, I can't find a better description form, let me know if you
have any thoughts with this.
> >
> > Rob
> >
Thanks,
Moudy
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes
2022-01-25 8:20 ` moudy ho
@ 2022-01-27 10:57 ` AngeloGioacchino Del Regno
0 siblings, 0 replies; 12+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-01-27 10:57 UTC (permalink / raw)
To: moudy ho, Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley, Laurent Pinchart,
linux-media, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Alexandre Courbot, tfiga, drinkcat, pihsun, hsinyi,
Maoguang Meng, daoyuan huang, Ping-Hsun Wu, menghui.lin,
sj.huang, allen-kh.cheng, randy.wu, jason-jh.lin, roy-cw.yeh,
river.cheng, srv_heupstream
Il 25/01/22 09:20, moudy ho ha scritto:
> On Fri, 2022-01-21 at 12:58 +0100, AngeloGioacchino Del Regno wrote:
>> Il 05/01/22 10:37, Moudy Ho ha scritto:
>>> Add device nodes for Media Data Path 3 (MDP3) modules.
>>>
>>> Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
>>> ---
>>> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 108
>>> ++++++++++++++++++++++-
>>> 1 file changed, 107 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> index ba4584faca5a..b872ef1ff6b3 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
>>> @@ -1325,6 +1325,79 @@
>>> mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX
>>> 0 0x1000>;
>>> };
>>>
>>> + mdp3_rdma0: mdp3_rdma0@14001000 {
>>> + compatible = "mediatek,mt8183-mdp3",
>>> + "mediatek,mt8183-mdp3-rdma0";
>>> + mediatek,scp = <&scp>;
>>> + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-
>>> dl1",
>>> + "mediatek,mt8183-mdp3-
>>> dl2",
>>> + "mediatek,mt8183-mdp3-
>>> path1",
>>> + "mediatek,mt8183-mdp3-
>>> path2",
>>> + "mediatek,mt8183-mdp3-
>>> imgi",
>>> + "mediatek,mt8183-mdp3-
>>> exto";
>>> + reg = <0 0x14001000 0 0x1000>,
>>> + <0 0x14000000 0 0x1000>,
>>> + <0 0x14005000 0 0x1000>,
>>> + <0 0x14006000 0 0x1000>,
>>> + <0 0x15020000 0 0x1000>;
>>> + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX
>>> 0x1000 0x1000>,
>>> + <&gce SUBSYS_1400XXXX
>>> 0 0x1000>,
>>> + <&gce SUBSYS_1400XXXX
>>> 0x5000 0x1000>,
>>> + <&gce SUBSYS_1400XXXX
>>> 0x6000 0x1000>,
>>> + <&gce SUBSYS_1502XXXX
>>> 0 0x1000>;
>>> + power-domains = <&spm
>>> MT8183_POWER_DOMAIN_DISP>;
>>> + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
>>> + <&mmsys CLK_MM_MDP_RSZ1>,
>>> + <&mmsys CLK_MM_MDP_DL_TXCK>,
>>> + <&mmsys CLK_MM_MDP_DL_RX>,
>>> + <&mmsys CLK_MM_IPU_DL_TXCK>,
>>> + <&mmsys CLK_MM_IPU_DL_RX>;
>>> + iommus = <&iommu M4U_PORT_MDP_RDMA0>;
>>> + mediatek,mmsys = <&mmsys>;
>>> + mediatek,mm-mutex = <&mutex>;
>>> + mediatek,mailbox-gce = <&gce>;
>>> + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST 0>,
>>> + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
>>> + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
>>> + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
>>
>> Hello Moudy,
>> the mboxes for gce 21, 22, 23 are missing the third cell. Please fix.
>>
>> Regards,
>> Angelo
>
> Hi Angelo,
> Thanks for the reminder, but I'm a bit confused, the previous
> version(v10) mentioned that the current upstream mbox has only 2
> cells.
> So I should follow this rule to remove the extra 0 in the first item as
> follows:
> + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
> + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
>
> Thanks,
> Moudy Ho
Hello Moudy,
I'm sorry for this confusion and you are totally right in the proposed solution,
which is the exact opposite of what I said.
Thanks for understanding,
Angelo
>>
>>> + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
>>> + <&gce 0x14010000 SUBSYS_1401XXXX>,
>>> + <&gce 0x14020000 SUBSYS_1402XXXX>,
>>> + <&gce 0x15020000 SUBSYS_1502XXXX>;
>>> + };
>>> +
>>
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings
2022-01-26 10:24 ` moudy.ho
@ 2022-02-21 7:47 ` moudy.ho
2022-02-21 8:33 ` moudy.ho
0 siblings, 1 reply; 12+ messages in thread
From: moudy.ho @ 2022-02-21 7:47 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, Rob Herring
Cc: Mauro Carvalho Chehab, Matthias Brugger, Hans Verkuil,
Jernej Skrabec, Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley,
Laurent Pinchart, linux-media, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Alexandre Courbot, tfiga, drinkcat,
pihsun, hsinyi, Maoguang Meng, daoyuan huang, Ping-Hsun Wu,
menghui.lin, sj.huang, allen-kh.cheng, randy.wu, jason-jh.lin,
roy-cw.yeh, river.cheng, srv_heupstream
On Wed, 2022-01-26 at 18:24 +0800, moudy.ho wrote:
> On Mon, 2022-01-24 at 12:40 +0100, AngeloGioacchino Del Regno wrote:
> > Il 21/01/22 22:16, Rob Herring ha scritto:
> > > On Wed, Jan 05, 2022 at 05:37:56PM +0800, Moudy Ho wrote:
> >
> > Hello Rob,
> >
> > since I'm not the best at reviewing dt-bindings, I always try to
> > leave that to
> >
> > other reviewers; in which case, thank you for your awesome review
> > activity on
> >
> > all of these (and helping me a lot on some of my attempts to write
> > yaml..!!)
> >
> >
> > In this case, though, since I do have knowledge about the platform,
> > it's probably
> > worth for me to try to address some of your questions, on at least
> > this one.
> >
> >
> > > > This patch adds DT binding document for Media Data Path 3
> > > > (MDP3)
> > > > a unit in multimedia system used for scaling and color format
> > > > convert.
> > > >
> > > > Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> > > > ---
> > > > .../bindings/media/mediatek,mdp3-rdma.yaml | 193
> > > > ++++++++++++++++++
> > > > .../bindings/media/mediatek,mdp3-rsz.yaml | 55 +++++
> > > > .../bindings/media/mediatek,mdp3-wrot.yaml | 57 ++++++
> > > > .../bindings/soc/mediatek/mediatek,ccorr.yaml | 47 +++++
> > > > .../bindings/soc/mediatek/mediatek,wdma.yaml | 58 ++++++
> > > > 5 files changed, 410 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/media/mediatek,mdp3-rsz.yaml
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr.y
> > > > am
> > > > l
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.ya
> > > > ml
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > rdma.yaml
> > > > b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > rdma.yaml
> > > > new file mode 100644
> > > > index 000000000000..002503383934
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > rdma.yaml
> > > > @@ -0,0 +1,193 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id:
> > > >
https://urldefense.com/v3/__http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtt5fpkQb$
> > > >
> > > > +$schema:
> > > >
https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtk8-fzFI$
> > > >
> > > > +
> > > > +title: Mediatek Read Direct Memory Access
> > > > +
> > > > +maintainers:
> > > > + - Matthias Brugger <matthias.bgg@gmail.com>
> > > > +
> > > > +description: |
> > > > + Mediatek Read Direct Memory Access(RDMA) component used to
> > > > do
> > > > read DMA.
> > > > + It contains one line buffer to store the sufficient pixel
> > > > data, and
> > > > + must be siblings to the central MMSYS_CONFIG node.
> > > > + For a description of the MMSYS_CONFIG binding, see
> > > > + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsy
> > > > s.
> > > > yaml
> > > > + for details.
> > > > + The 1st RDMA is also used to be a controller node in Media
> > > > Data Path 3(MDP3)
> > > > + that containing MMSYS, MUTEX, GCE and SCP settings.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + oneOf:
> > > > + - items:
> > > > + # MDP3 controller node
> > > > + - const: mediatek,mt8183-mdp3
> > >
> > > How is this more specific than this:
> > >
> > > > + - const: mediatek,mt8183-mdp3-rdma0
> >
> > Probably, oneOf is not the right choice here... "mediatek,mt8183-
> > mdp3" is needed
> > to probe the "main" mdp3 core pdev, while RDMA0 is a necessary
> > component (as in
> > this driver uses the component framework, and rdma0 is required for
> > functionality,
> > as far as I understand).
> >
> > This shouldn't be a choice, meaning that defining mdp3-rdma0
> > without
> > mdp3 is
> > completely useless, as there wouldn't be anything else initializing
> > that component,
> > nor sub-components of that.
> >
>
> Hi Rob and Angelo,
> Sorry for the incomplete description here, I originally planned to
> add
> a compatible name here in the future when the chip has multiple
> RDMAs.
> Since 8183 currently has only one RDMA, the above design expression
> is
> incorrect and should be rewritten as follows:
>
> [8183]
> properties:
> compatible:
> items:
> # MDP3 controller node
> - const: mediatek,mt8183-mdp3
> - const: mediatek,mt8195-mdp3-rdma0
fix typo
- const: mediatek,mt8183-mdp3-rdma0
>
> [8195]
> properties:
> compatible:
> oneOf:
> - items:
> # MDP3 controller node
> - const: mediatek,mt8183-mdp3
> - const: mediatek,mt8195-mdp3-rdma0
> - items:
> # normal RDMA conponent
> - const: mediatek,mt8195-mdp3-rdma1
> - items:
> # normal RDMA conponent
> - const: mediatek,mt8195-mdp3-rdma2
> - items:
> # normal RDMA conponent
> - const: mediatek,mt8195-mdp3-rdma3
>
> > > > + - items:
> > > > + # normal RDMA conponent
> > > > + - const: mediatek,mt8183-mdp3-rdma0
> > > > +
> > > > + mediatek,scp:
> > > > + description: The node of system control processor (SCP),
> > > > using
> > > > + the remoteproc & rpmsg framework.
> > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > + maxItems: 1
> > > > +
> > > > + mediatek,mdp3-comps:
> > > > + description: MTK sub-system of direct-link or DIP
> > >
> > > This needs a better description. What is DIP? What is direct-
> > > link?
> >
> > I agree, this needs a better description.
> >
>
> I tried to modify the description as follows, could you help to see
> if
> there is anything confusing:
>
> mediatek,mdp3-comps:
> description:
> MDP subsystem which has direct-link from Image Signal
> Processor(ISP).
> When using the camera, the DMA of ISP PASS (DIP) module will
> directly trigger MDP3 without other control (such as V4L2 M2M) to
> create corresponding HW path.
> The MDP3 controller must set up a series of registers at the
> beginning of path creation which covering MMSYS, IMGSYS, and MDP3's
> components, so that data flow can pass through MDP3.
> The entire path is briefly described as follows:
> DIP : ISP ->
> MDP3 : IMGI -> DL -> CCORR(optional) -> RSZ -> PATH_OUT
> ->
> WDMA/WROT
> > >
> > > > + $ref: /schemas/types.yaml#/definitions/string-array
> > > > + items:
> > > > + - enum:
> > > > + # MDP direct-link input path selection, create a
> > > > + # component for path connectedness of HW pipe
> > > > control
> > > > + - mediatek,mt8183-mdp3-dl1
> > > > + - enum:
> > > > + - mediatek,mt8183-mdp3-dl2
> > > > + - enum:
> > > > + # MDP direct-link output path selection, create a
> > > > + # component for path connectedness of HW pipe
> > > > control
> > > > + - mediatek,mt8183-mdp3-path1
> > > > + - enum:
> > > > + - mediatek,mt8183-mdp3-path2
> > > > + - enum:
> > > > + # Input DMA of ISP PASS2 (DIP) module for raw image
> > > > input
> > > > + - mediatek,mt8183-mdp3-imgi
> > > > + - enum:
> > > > + # Output DMA of ISP PASS2 (DIP) module for YUV image
> > > > output
> > > > + - mediatek,mt8183-mdp3-exto
> > >
> > > There's only 1 possible value for mediatek,mdp3-comps, so why
> > > does
> > > it
> > > need to be in DT?
> > >
> >
> > The wanted logic here (I believe) is that, depending on firmware
> > capabilities
> > and/or platform/board capabilities, you may miss some subcomponents
> > like IMGI
> > and/or EXTO.
> > As for DL1/2 and PATH1/2... DL1+PATH1 is surely critically
> > necessary
> > for the
> > functionality of the MDP3 RDMA... I don't know whether it's
> > possible
> > that we
> > get any fw/platform/device that's not using DL2/PATH2 at all.
> >
> > Moudy, can you please explain?
> >
>
> Hi Angelo,
> Thanks for your help and your assumptions are correct.
> In further chips(such as 8195), IMGI will be replaced by WPE, and
> PATH_OUT will be removed, and DL will be expanded to 6 (implicit
> number
> of direct-link from ISP paths).
> For this variable hardware design, not sure how to flexibly
> describe
> in dt-bindings to meet futher requirements.
> It should be that I got wrong with the definition of "enum", should
> it be rewritten as follows in 8183?
> items:
> - enum:
> # MDP direct-link input path selection, create a
> # component for path connectedness of HW pipe control
> - mediatek,mt8183-mdp3-dl1
> - mediatek,mt8183-mdp3-dl2
> # MDP direct-link output path selection, create a
> # component for path connectedness of HW pipe control
> - mediatek,mt8183-mdp3-path1
> - mediatek,mt8183-mdp3-path2
> # Input DMA of ISP PASS2 (DIP) module for raw image input
> - mediatek,mt8183-mdp3-imgi
> # Output DMA of ISP PASS2 (DIP) module for YUV image output
> - mediatek,mt8183-mdp3-exto
> items: (8195)
> snip....
> items: (8192)
> snip...
> > > > +
> > > > + reg:
> > > > + items:
> > > > + - description: basic RDMA HW address
> > > > + - description: MDP direct-link 1st and 2nd input
> > > > + - description: MDP direct-link 1st output
> > > > + - description: MDP direct-link 2nd output
> > > > + - description: ISP input and output
> > > > +
> > > > + mediatek,gce-client-reg:
> > > > + description: The register of client driver can be
> > > > configured
> > > > by gce with
> > > > + 4 arguments defined in this property, such as phandle of
> > > > gce, subsys id,
> > > > + register offset and size. Each GCE subsys id is mapping
> > > > to
> > > > a client
> > > > + defined in the header include/dt-bindings/gce/<chip>-
> > > > gce.h.
> > > > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > + items:
> > > > + - description: GCE client for RDMA
> > > > + - description: GCR client for MDP direct-link 1st and
> > > > 2nd
> > > > input
> > > > + - description: GCR client for MDP direct-link 1st output
> > > > + - description: GCR client for MDP direct-link 2nd output
> > > > + - description: GCR client for ISP input and output
> > > > +
> > > > + power-domains:
> > > > + maxItems: 1
> > > > +
> > > > + clocks:
> > > > + items:
> > > > + - description: RDMA clock
> > > > + - description: RSZ clock
> > > > + - description: direck-link TX clock in MDP side
> > > > + - description: direck-link RX clock in MDP side
> > > > + - description: direck-link TX clock in ISP side
> > > > + - description: direck-link RX clock in ISP side
> > > > +
> > > > + iommus:
> > > > + maxItems: 1
> > > > +
> > > > + mediatek,mmsys:
> > > > + description: The node of mux(multiplexer) controller for
> > > > HW
> > > > connections.
> > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > +
> > > > + mediatek,mm-mutex:
> > >
> > > Is this some sort of h/w lock? We have a standard binding for
> > > that.
> > >
> >
> > There's a story behind that one: this was part of mtk (display) DRM
> > drivers, then
> > it was moved to soc/mediatek/mtk-mutex.c as it started being
> > shared.
> >
> > I wonder if the mm-mutex can be rewritten and moved to
> > hwspinlock...
> > this driver
> > is growing and now, with the introduction of MDP3, we're seeing
> > some
> > more.
> >
> > Though, it's definitely worth mentioning that the usage of
> > MediaTek's
> > mm-mutex is
> > varying a bit between the drm case and the mdp3 case as, here, we
> > have a "command
> > queue" mechanism that is used for commands ordering in HW.
> > This is a very complex architecture that has very specific
> > requirements.
> > For how I see it, migrating that to hwspinlock would require an
> > almost complete
> > reimplementation of soc/mediatek/*, which would take a considerable
> > amount of
> > time and efforts.
> > I'm mostly sure that I can help with that, but for how things are
> > looking right
> >
> > now, between refactoring, getting code solid, going through sane
> > reviews and a
> > final merge, I'd say that this will take 8-12 months from now.
> >
> > For this reason, I would propose to perform a slow and steady
> > migration of the
> > MediaTek mmsys, scpsys, mutex over time, but only after getting in
> > the support
> > for the new SoCs and functionality for the older ones, provided in
> > this series
> > and some others that were already sent by MTK, half (or more) of
> > which have
> > already been merged.
>
> Sorry for the misunderstanding caused by the name, the original
> mtk-
> mutex design did have the ability to lock registers, but that has
> since
> been removed but the name continues.
> It's not one of those h/w locks like spinlock, semaphore, or mutex
> but is just designed to send signals to trigger h/w components to get
> or send data.
>
> > > > + description: The node of sof(start of frame) signal
> > > > controller.
> > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > + maxItems: 1
> > > > +
> > > > + mediatek,mailbox-gce:
> > > > + description: The node of global command engine (GCE), used
> > > > to read/write
> > > > + registers with critical time limitation.
> > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > +
> > > > + mboxes:
> > > > + items:
> > > > + - description: used for 1st data pipe from RDMA
> > > > + - description: used for 2nd data pipe from RDMA
> > > > + - description: used for 3rd data pipe from Direct-Link
> > > > + - description: used for 4th data pipe from Direct-Link
> > > > +
> > > > + gce-subsys:
> > > > + description: sub-system id corresponding to the global
> > > > command engine (GCE)
> > > > + register address.
> > > > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > +
> > > > +if:
> > > > + properties:
> > > > + compatible:
> > > > + contains:
> > > > + const: mediatek,mt8183-mdp3
> > > > +
> > > > +then:
> > > > + required:
> > > > + - mediatek,scp
> > > > + - mediatek,mmsys
> > > > + - mediatek,mm-mutex
> > > > + - mediatek,mailbox-gce
> > > > + - mboxes
> > > > + - gce-subsys
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > + - clocks
> > > > + - mediatek,gce-client-reg
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > > + #include <dt-bindings/gce/mt8183-gce.h>
> > > > + #include <dt-bindings/power/mt8183-power.h>
> > > > + #include <dt-bindings/memory/mt8183-larb-port.h>
> > > > +
> > > > + mdp3_rdma0: mdp3_rdma0@14001000 {
> > > > + compatible = "mediatek,mt8183-mdp3",
> > > > + "mediatek,mt8183-mdp3-rdma0";
> > > > + mediatek,scp = <&scp>;
> > > > + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-dl1",
> > > > + "mediatek,mt8183-mdp3-dl2",
> > > > + "mediatek,mt8183-mdp3-path1",
> > > > + "mediatek,mt8183-mdp3-path2",
> > > > + "mediatek,mt8183-mdp3-imgi",
> > > > + "mediatek,mt8183-mdp3-exto";
> > > > + reg = <0x14001000 0x1000>,
> > > > + <0x14000000 0x1000>,
> > > > + <0x14005000 0x1000>,
> > > > + <0x14006000 0x1000>,
> > > > + <0x15020000 0x1000>;
> > > > + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000
> > > > 0x1000>,
> > > > + <&gce SUBSYS_1400XXXX 0
> > > > 0x1000>,
> > > > + <&gce SUBSYS_1400XXXX 0x5000
> > > > 0x1000>,
> > > > + <&gce SUBSYS_1400XXXX 0x6000
> > > > 0x1000>,
> > > > + <&gce SUBSYS_1502XXXX 0
> > > > 0x1000>;
> > > > + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> > > > + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> > > > + <&mmsys CLK_MM_MDP_RSZ1>,
> > > > + <&mmsys CLK_MM_MDP_DL_TXCK>,
> > > > + <&mmsys CLK_MM_MDP_DL_RX>,
> > > > + <&mmsys CLK_MM_IPU_DL_TXCK>,
> > > > + <&mmsys CLK_MM_IPU_DL_RX>;
> > > > + iommus = <&iommu>;
> > > > + mediatek,mmsys = <&mmsys>;
> > > > + mediatek,mm-mutex = <&mutex>;
> > > > + mediatek,mailbox-gce = <&gce>;
> > > > + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
> > > > + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
> > > > + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
> > > > + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
> > > > + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
> > > > + <&gce 0x14010000 SUBSYS_1401XXXX>,
> > > > + <&gce 0x14020000 SUBSYS_1402XXXX>,
> > > > + <&gce 0x15020000 SUBSYS_1502XXXX>;
> > > > + };
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > rsz.yaml
> > > > b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > rsz.yaml
> > > > new file mode 100644
> > > > index 000000000000..cd4cf1531535
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > rsz.yaml
> > > > @@ -0,0 +1,55 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id:
> > > >
https://urldefense.com/v3/__http://devicetree.org/schemas/media/mediatek,mdp3-rsz.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtoNRPuZQ$
> > > >
> > > > +$schema:
> > > >
https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtk8-fzFI$
> > > >
> > > > +
> > > > +title: Mediatek Resizer
> > > > +
> > > > +maintainers:
> > > > + - Matthias Brugger <matthias.bgg@gmail.com>
> > > > +
> > > > +description: |
> > > > + One of Media Data Path 3 (MDP3) components used to do frame
> > > > resizing.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + items:
> > > > + - enum:
> > > > + - mediatek,mt8183-mdp3-rsz0
> > > > + - mediatek,mt8183-mdp3-rsz1
> > >
> > > Again, what's the difference between 0 and 1?
> > >
> > > I've probably asked that before, but without a sufficient
> > > reasoning
> > > here in the schema I'm just going to keep asking the same
> > > question.
> >
> > This can probably be, instead, something like
> >
> > compatible = "mediatek,mt8183-mdp3-rsz";
> > reg = < .... >;
> > mediatek,instance-id = <0>;
> > gce reg, clocks, blah...
> >
> > or
> >
> > compatible = "mediatek,mt8183-mdp3-rsz";
> > reg = < ...rsz0... >, < ...rsz1... >;
> > reg-names = "rsz0", "rsz1";
> > gce reg, clocks, blah...
> >
> >
> > ...In any case, if MediaTek chose to separate these like that, I
> > guess that
> > there will be differences in newer SoCs that would make that kind
> > of
> > binding
> > much necessary.
> >
> > Please Moudy, can you explain why you didn't write that like the
> > examples
> > that I provided there?
>
> Before version 10 it was written the same way as the first form
> Angelo
> mentioned - with h/w indexed properties, but Rob thinks it's bad
> idea.
> At that time I asked Rob if it could be rewritten into its current
> V11
> form, but I updated before I got a suggestion.
> Apologize for the inconvenience casued by my careless handling.
>
> In the 8183 MDP3, only RSZ is configured with 2 sets. The 1st set
> upstream can have quality adjustment components (like AAL or CCORR or
> both) connected, but the 2nd set does not.
> Although those two RSZ components have the same hardware function but
> register address. The MDP paths with different functions will be
> created due to the different upstream and downstream connections.
> In addition to the various upstream/downstream connection methods
> caused by chip design, the above conditions are also dynamically
> determined according to the current usage scenario(with or without
> PQ,
> rotation...etc).
> Also, considering that multiple paths are used at the same time, MDP3
> will need to know which components are currently available for
> dispatch.
> At present, I can't find a better description form, let me know if
> you
> have any thoughts with this.
>
> > >
> > > Rob
> > >
>
> Thanks,
> Moudy
Hi Rob and Angelo,
I tried to draw the flow to illustrate that there will be different
selections of component (RSZ0 or RSZ1) because of the different target
paths created.
+------------+ +------------+
| RDMA0 | | ISP[*1] |
+------------+ +----
--------+
A B C 2 1
v v v
v v
| | | | |
| | +---------
+ | |
| | | | |
| +-------
+ | | |
| | | | |
| +----
---+----+---------+ |
| | | | |
| |
| +---------+ |
v v | | |
A 2
| | |
******** | | |
** ** | | |
* PQ[*2] * | | |
** ** | | |
******** | | |
| | | | |
v v | v v
A 2 | C 1
+---+------+ | +------
-----+
| RSZ0 | | | RSZ1 |
+---+----
--+ | +-----------+
D | 3 4
v
| v v
| | | |
| +-------+ | |
| | | |
| | +-------------------+ |
| | | |
v v v v
D B 3 4
+------------+ +------------+
| WROT0 | | WDMA |
+------------+ +------
------+
[*1] Direct-link path for camera input
[*2] A series of
picture quality adjustment
engines, composed of AAL, CCORR, TDSHP
and COLOR
Although components RSZ0 and RSZ1 have the same HW function,
considering that the components corresponding to their upstream and
downstream are different, paths with different functions can be created
as approprate.
There are 3 paths from RDMA0, which are
A. Path with full PQ(picture quality) adjustments, resize and rotation.
B. rotation only.
C. Path with resize and rotation.
For direct-link input, there has 2 possible path, which are
1. Main path: write buffer with resize function
2. Secondary path: can only be used when the picked components are
free.
Combining the above features, it can create one of the 5 paths, or dual
paths at the same time such as: A+1, B+1 or C(4)+2. In further chips,
the number of multi-components and paths will increase.
Is there a more appropriate way to replace the HW index for this
design?
Thanks,
Moudy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings
2022-02-21 7:47 ` moudy.ho
@ 2022-02-21 8:33 ` moudy.ho
0 siblings, 0 replies; 12+ messages in thread
From: moudy.ho @ 2022-02-21 8:33 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, Rob Herring
Cc: Mauro Carvalho Chehab, Matthias Brugger, Hans Verkuil,
Jernej Skrabec, Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley,
Laurent Pinchart, linux-media, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Alexandre Courbot, tfiga, drinkcat,
pihsun, hsinyi, Maoguang Meng, daoyuan huang, Ping-Hsun Wu,
menghui.lin, sj.huang, allen-kh.cheng, randy.wu, jason-jh.lin,
roy-cw.yeh, river.cheng, srv_heupstream
On Mon, 2022-02-21 at 15:47 +0800, moudy.ho wrote:
> On Wed, 2022-01-26 at 18:24 +0800, moudy.ho wrote:
> > On Mon, 2022-01-24 at 12:40 +0100, AngeloGioacchino Del Regno
> > wrote:
> > > Il 21/01/22 22:16, Rob Herring ha scritto:
> > > > On Wed, Jan 05, 2022 at 05:37:56PM +0800, Moudy Ho wrote:
> > >
> > > Hello Rob,
> > >
> > > since I'm not the best at reviewing dt-bindings, I always try to
> > > leave that to
> > >
> > > other reviewers; in which case, thank you for your awesome review
> > > activity on
> > >
> > > all of these (and helping me a lot on some of my attempts to
> > > write
> > > yaml..!!)
> > >
> > >
> > > In this case, though, since I do have knowledge about the
> > > platform,
> > > it's probably
> > > worth for me to try to address some of your questions, on at
> > > least
> > > this one.
> > >
> > >
> > > > > This patch adds DT binding document for Media Data Path 3
> > > > > (MDP3)
> > > > > a unit in multimedia system used for scaling and color format
> > > > > convert.
> > > > >
> > > > > Signed-off-by: Moudy Ho <moudy.ho@mediatek.com>
> > > > > ---
> > > > > .../bindings/media/mediatek,mdp3-rdma.yaml | 193
> > > > > ++++++++++++++++++
> > > > > .../bindings/media/mediatek,mdp3-rsz.yaml | 55 +++++
> > > > > .../bindings/media/mediatek,mdp3-wrot.yaml | 57 ++++++
> > > > > .../bindings/soc/mediatek/mediatek,ccorr.yaml | 47 +++++
> > > > > .../bindings/soc/mediatek/mediatek,wdma.yaml | 58 ++++++
> > > > > 5 files changed, 410 insertions(+)
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > > rdma.yaml
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > > rsz.yaml
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > > wrot.yaml
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/soc/mediatek/mediatek,ccorr
> > > > > .y
> > > > > am
> > > > > l
> > > > > create mode 100644
> > > > > Documentation/devicetree/bindings/soc/mediatek/mediatek,wdma.
> > > > > ya
> > > > > ml
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > > rdma.yaml
> > > > > b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > > rdma.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..002503383934
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > > rdma.yaml
> > > > > @@ -0,0 +1,193 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id:
> > > > >
>
>
https://urldefense.com/v3/__http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtt5fpkQb$
> > > > >
> > > > > +$schema:
> > > > >
>
>
https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtk8-fzFI$
> > > > >
> > > > > +
> > > > > +title: Mediatek Read Direct Memory Access
> > > > > +
> > > > > +maintainers:
> > > > > + - Matthias Brugger <matthias.bgg@gmail.com>
> > > > > +
> > > > > +description: |
> > > > > + Mediatek Read Direct Memory Access(RDMA) component used to
> > > > > do
> > > > > read DMA.
> > > > > + It contains one line buffer to store the sufficient pixel
> > > > > data, and
> > > > > + must be siblings to the central MMSYS_CONFIG node.
> > > > > + For a description of the MMSYS_CONFIG binding, see
> > > > > + Documentation/devicetree/bindings/arm/mediatek/mediatek,mm
> > > > > sy
> > > > > s.
> > > > > yaml
> > > > > + for details.
> > > > > + The 1st RDMA is also used to be a controller node in Media
> > > > > Data Path 3(MDP3)
> > > > > + that containing MMSYS, MUTEX, GCE and SCP settings.
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + oneOf:
> > > > > + - items:
> > > > > + # MDP3 controller node
> > > > > + - const: mediatek,mt8183-mdp3
> > > >
> > > > How is this more specific than this:
> > > >
> > > > > + - const: mediatek,mt8183-mdp3-rdma0
> > >
> > > Probably, oneOf is not the right choice here... "mediatek,mt8183-
> > > mdp3" is needed
> > > to probe the "main" mdp3 core pdev, while RDMA0 is a necessary
> > > component (as in
> > > this driver uses the component framework, and rdma0 is required
> > > for
> > > functionality,
> > > as far as I understand).
> > >
> > > This shouldn't be a choice, meaning that defining mdp3-rdma0
> > > without
> > > mdp3 is
> > > completely useless, as there wouldn't be anything else
> > > initializing
> > > that component,
> > > nor sub-components of that.
> > >
> >
> > Hi Rob and Angelo,
> > Sorry for the incomplete description here, I originally planned to
> > add
> > a compatible name here in the future when the chip has multiple
> > RDMAs.
> > Since 8183 currently has only one RDMA, the above design expression
> > is
> > incorrect and should be rewritten as follows:
> >
> > [8183]
> > properties:
> > compatible:
> > items:
> > # MDP3 controller node
> > - const: mediatek,mt8183-mdp3
> > - const: mediatek,mt8195-mdp3-rdma0
>
> fix typo
> - const: mediatek,mt8183-mdp3-rdma0
> >
> > [8195]
> > properties:
> > compatible:
> > oneOf:
> > - items:
> > # MDP3 controller node
> > - const: mediatek,mt8183-mdp3
> > - const: mediatek,mt8195-mdp3-rdma0
> > - items:
> > # normal RDMA conponent
> > - const: mediatek,mt8195-mdp3-rdma1
> > - items:
> > # normal RDMA conponent
> > - const: mediatek,mt8195-mdp3-rdma2
> > - items:
> > # normal RDMA conponent
> > - const: mediatek,mt8195-mdp3-rdma3
> >
> > > > > + - items:
> > > > > + # normal RDMA conponent
> > > > > + - const: mediatek,mt8183-mdp3-rdma0
> > > > > +
> > > > > + mediatek,scp:
> > > > > + description: The node of system control processor (SCP),
> > > > > using
> > > > > + the remoteproc & rpmsg framework.
> > > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > > + maxItems: 1
> > > > > +
> > > > > + mediatek,mdp3-comps:
> > > > > + description: MTK sub-system of direct-link or DIP
> > > >
> > > > This needs a better description. What is DIP? What is direct-
> > > > link?
> > >
> > > I agree, this needs a better description.
> > >
> >
> > I tried to modify the description as follows, could you help to see
> > if
> > there is anything confusing:
> >
> > mediatek,mdp3-comps:
> > description:
> > MDP subsystem which has direct-link from Image Signal
> > Processor(ISP).
> > When using the camera, the DMA of ISP PASS (DIP) module will
> > directly trigger MDP3 without other control (such as V4L2 M2M) to
> > create corresponding HW path.
> > The MDP3 controller must set up a series of registers at the
> > beginning of path creation which covering MMSYS, IMGSYS, and MDP3's
> > components, so that data flow can pass through MDP3.
> > The entire path is briefly described as follows:
> > DIP : ISP ->
> > MDP3 : IMGI -> DL -> CCORR(optional) -> RSZ ->
> > PATH_OUT
> > ->
> > WDMA/WROT
> > > >
> > > > > + $ref: /schemas/types.yaml#/definitions/string-array
> > > > > + items:
> > > > > + - enum:
> > > > > + # MDP direct-link input path selection, create a
> > > > > + # component for path connectedness of HW pipe
> > > > > control
> > > > > + - mediatek,mt8183-mdp3-dl1
> > > > > + - enum:
> > > > > + - mediatek,mt8183-mdp3-dl2
> > > > > + - enum:
> > > > > + # MDP direct-link output path selection, create a
> > > > > + # component for path connectedness of HW pipe
> > > > > control
> > > > > + - mediatek,mt8183-mdp3-path1
> > > > > + - enum:
> > > > > + - mediatek,mt8183-mdp3-path2
> > > > > + - enum:
> > > > > + # Input DMA of ISP PASS2 (DIP) module for raw
> > > > > image
> > > > > input
> > > > > + - mediatek,mt8183-mdp3-imgi
> > > > > + - enum:
> > > > > + # Output DMA of ISP PASS2 (DIP) module for YUV
> > > > > image
> > > > > output
> > > > > + - mediatek,mt8183-mdp3-exto
> > > >
> > > > There's only 1 possible value for mediatek,mdp3-comps, so why
> > > > does
> > > > it
> > > > need to be in DT?
> > > >
> > >
> > > The wanted logic here (I believe) is that, depending on firmware
> > > capabilities
> > > and/or platform/board capabilities, you may miss some
> > > subcomponents
> > > like IMGI
> > > and/or EXTO.
> > > As for DL1/2 and PATH1/2... DL1+PATH1 is surely critically
> > > necessary
> > > for the
> > > functionality of the MDP3 RDMA... I don't know whether it's
> > > possible
> > > that we
> > > get any fw/platform/device that's not using DL2/PATH2 at all.
> > >
> > > Moudy, can you please explain?
> > >
> >
> > Hi Angelo,
> > Thanks for your help and your assumptions are correct.
> > In further chips(such as 8195), IMGI will be replaced by WPE, and
> > PATH_OUT will be removed, and DL will be expanded to 6 (implicit
> > number
> > of direct-link from ISP paths).
> > For this variable hardware design, not sure how to flexibly
> > describe
> > in dt-bindings to meet futher requirements.
> > It should be that I got wrong with the definition of "enum",
> > should
> > it be rewritten as follows in 8183?
> > items:
> > - enum:
> > # MDP direct-link input path selection, create a
> > # component for path connectedness of HW pipe control
> > - mediatek,mt8183-mdp3-dl1
> > - mediatek,mt8183-mdp3-dl2
> > # MDP direct-link output path selection, create a
> > # component for path connectedness of HW pipe control
> > - mediatek,mt8183-mdp3-path1
> > - mediatek,mt8183-mdp3-path2
> > # Input DMA of ISP PASS2 (DIP) module for raw image input
> > - mediatek,mt8183-mdp3-imgi
> > # Output DMA of ISP PASS2 (DIP) module for YUV image
> > output
> > - mediatek,mt8183-mdp3-exto
> > items: (8195)
> > snip....
> > items: (8192)
> > snip...
> > > > > +
> > > > > + reg:
> > > > > + items:
> > > > > + - description: basic RDMA HW address
> > > > > + - description: MDP direct-link 1st and 2nd input
> > > > > + - description: MDP direct-link 1st output
> > > > > + - description: MDP direct-link 2nd output
> > > > > + - description: ISP input and output
> > > > > +
> > > > > + mediatek,gce-client-reg:
> > > > > + description: The register of client driver can be
> > > > > configured
> > > > > by gce with
> > > > > + 4 arguments defined in this property, such as phandle
> > > > > of
> > > > > gce, subsys id,
> > > > > + register offset and size. Each GCE subsys id is
> > > > > mapping
> > > > > to
> > > > > a client
> > > > > + defined in the header include/dt-bindings/gce/<chip>-
> > > > > gce.h.
> > > > > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > + items:
> > > > > + - description: GCE client for RDMA
> > > > > + - description: GCR client for MDP direct-link 1st and
> > > > > 2nd
> > > > > input
> > > > > + - description: GCR client for MDP direct-link 1st
> > > > > output
> > > > > + - description: GCR client for MDP direct-link 2nd
> > > > > output
> > > > > + - description: GCR client for ISP input and output
> > > > > +
> > > > > + power-domains:
> > > > > + maxItems: 1
> > > > > +
> > > > > + clocks:
> > > > > + items:
> > > > > + - description: RDMA clock
> > > > > + - description: RSZ clock
> > > > > + - description: direck-link TX clock in MDP side
> > > > > + - description: direck-link RX clock in MDP side
> > > > > + - description: direck-link TX clock in ISP side
> > > > > + - description: direck-link RX clock in ISP side
> > > > > +
> > > > > + iommus:
> > > > > + maxItems: 1
> > > > > +
> > > > > + mediatek,mmsys:
> > > > > + description: The node of mux(multiplexer) controller for
> > > > > HW
> > > > > connections.
> > > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > > +
> > > > > + mediatek,mm-mutex:
> > > >
> > > > Is this some sort of h/w lock? We have a standard binding for
> > > > that.
> > > >
> > >
> > > There's a story behind that one: this was part of mtk (display)
> > > DRM
> > > drivers, then
> > > it was moved to soc/mediatek/mtk-mutex.c as it started being
> > > shared.
> > >
> > > I wonder if the mm-mutex can be rewritten and moved to
> > > hwspinlock...
> > > this driver
> > > is growing and now, with the introduction of MDP3, we're seeing
> > > some
> > > more.
> > >
> > > Though, it's definitely worth mentioning that the usage of
> > > MediaTek's
> > > mm-mutex is
> > > varying a bit between the drm case and the mdp3 case as, here, we
> > > have a "command
> > > queue" mechanism that is used for commands ordering in HW.
> > > This is a very complex architecture that has very specific
> > > requirements.
> > > For how I see it, migrating that to hwspinlock would require an
> > > almost complete
> > > reimplementation of soc/mediatek/*, which would take a
> > > considerable
> > > amount of
> > > time and efforts.
> > > I'm mostly sure that I can help with that, but for how things are
> > > looking right
> > >
> > > now, between refactoring, getting code solid, going through sane
> > > reviews and a
> > > final merge, I'd say that this will take 8-12 months from now.
> > >
> > > For this reason, I would propose to perform a slow and steady
> > > migration of the
> > > MediaTek mmsys, scpsys, mutex over time, but only after getting
> > > in
> > > the support
> > > for the new SoCs and functionality for the older ones, provided
> > > in
> > > this series
> > > and some others that were already sent by MTK, half (or more) of
> > > which have
> > > already been merged.
> >
> > Sorry for the misunderstanding caused by the name, the original
> > mtk-
> > mutex design did have the ability to lock registers, but that has
> > since
> > been removed but the name continues.
> > It's not one of those h/w locks like spinlock, semaphore, or
> > mutex
> > but is just designed to send signals to trigger h/w components to
> > get
> > or send data.
> >
> > > > > + description: The node of sof(start of frame) signal
> > > > > controller.
> > > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > > + maxItems: 1
> > > > > +
> > > > > + mediatek,mailbox-gce:
> > > > > + description: The node of global command engine (GCE),
> > > > > used
> > > > > to read/write
> > > > > + registers with critical time limitation.
> > > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > > +
> > > > > + mboxes:
> > > > > + items:
> > > > > + - description: used for 1st data pipe from RDMA
> > > > > + - description: used for 2nd data pipe from RDMA
> > > > > + - description: used for 3rd data pipe from Direct-Link
> > > > > + - description: used for 4th data pipe from Direct-Link
> > > > > +
> > > > > + gce-subsys:
> > > > > + description: sub-system id corresponding to the global
> > > > > command engine (GCE)
> > > > > + register address.
> > > > > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > > +
> > > > > +if:
> > > > > + properties:
> > > > > + compatible:
> > > > > + contains:
> > > > > + const: mediatek,mt8183-mdp3
> > > > > +
> > > > > +then:
> > > > > + required:
> > > > > + - mediatek,scp
> > > > > + - mediatek,mmsys
> > > > > + - mediatek,mm-mutex
> > > > > + - mediatek,mailbox-gce
> > > > > + - mboxes
> > > > > + - gce-subsys
> > > > > +
> > > > > +required:
> > > > > + - compatible
> > > > > + - reg
> > > > > + - clocks
> > > > > + - mediatek,gce-client-reg
> > > > > +
> > > > > +additionalProperties: false
> > > > > +
> > > > > +examples:
> > > > > + - |
> > > > > + #include <dt-bindings/clock/mt8183-clk.h>
> > > > > + #include <dt-bindings/gce/mt8183-gce.h>
> > > > > + #include <dt-bindings/power/mt8183-power.h>
> > > > > + #include <dt-bindings/memory/mt8183-larb-port.h>
> > > > > +
> > > > > + mdp3_rdma0: mdp3_rdma0@14001000 {
> > > > > + compatible = "mediatek,mt8183-mdp3",
> > > > > + "mediatek,mt8183-mdp3-rdma0";
> > > > > + mediatek,scp = <&scp>;
> > > > > + mediatek,mdp3-comps = "mediatek,mt8183-mdp3-dl1",
> > > > > + "mediatek,mt8183-mdp3-dl2",
> > > > > + "mediatek,mt8183-mdp3-path1",
> > > > > + "mediatek,mt8183-mdp3-path2",
> > > > > + "mediatek,mt8183-mdp3-imgi",
> > > > > + "mediatek,mt8183-mdp3-exto";
> > > > > + reg = <0x14001000 0x1000>,
> > > > > + <0x14000000 0x1000>,
> > > > > + <0x14005000 0x1000>,
> > > > > + <0x14006000 0x1000>,
> > > > > + <0x15020000 0x1000>;
> > > > > + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x1000
> > > > > 0x1000>,
> > > > > + <&gce SUBSYS_1400XXXX 0
> > > > > 0x1000>,
> > > > > + <&gce SUBSYS_1400XXXX 0x5000
> > > > > 0x1000>,
> > > > > + <&gce SUBSYS_1400XXXX 0x6000
> > > > > 0x1000>,
> > > > > + <&gce SUBSYS_1502XXXX 0
> > > > > 0x1000>;
> > > > > + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
> > > > > + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> > > > > + <&mmsys CLK_MM_MDP_RSZ1>,
> > > > > + <&mmsys CLK_MM_MDP_DL_TXCK>,
> > > > > + <&mmsys CLK_MM_MDP_DL_RX>,
> > > > > + <&mmsys CLK_MM_IPU_DL_TXCK>,
> > > > > + <&mmsys CLK_MM_IPU_DL_RX>;
> > > > > + iommus = <&iommu>;
> > > > > + mediatek,mmsys = <&mmsys>;
> > > > > + mediatek,mm-mutex = <&mutex>;
> > > > > + mediatek,mailbox-gce = <&gce>;
> > > > > + mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
> > > > > + <&gce 21 CMDQ_THR_PRIO_LOWEST>,
> > > > > + <&gce 22 CMDQ_THR_PRIO_LOWEST>,
> > > > > + <&gce 23 CMDQ_THR_PRIO_LOWEST>;
> > > > > + gce-subsys = <&gce 0x14000000 SUBSYS_1400XXXX>,
> > > > > + <&gce 0x14010000 SUBSYS_1401XXXX>,
> > > > > + <&gce 0x14020000 SUBSYS_1402XXXX>,
> > > > > + <&gce 0x15020000 SUBSYS_1502XXXX>;
> > > > > + };
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > > rsz.yaml
> > > > > b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > > rsz.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..cd4cf1531535
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-
> > > > > rsz.yaml
> > > > > @@ -0,0 +1,55 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id:
> > > > >
>
>
https://urldefense.com/v3/__http://devicetree.org/schemas/media/mediatek,mdp3-rsz.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtoNRPuZQ$
> > > > >
> > > > > +$schema:
> > > > >
>
>
https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!zgc4tZBqeOyinIM3DFy7YlTTFM9LtRFRUOLmIB6Go6xpTeaPQaFg_ekOtk8-fzFI$
> > > > >
> > > > > +
> > > > > +title: Mediatek Resizer
> > > > > +
> > > > > +maintainers:
> > > > > + - Matthias Brugger <matthias.bgg@gmail.com>
> > > > > +
> > > > > +description: |
> > > > > + One of Media Data Path 3 (MDP3) components used to do
> > > > > frame
> > > > > resizing.
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > + items:
> > > > > + - enum:
> > > > > + - mediatek,mt8183-mdp3-rsz0
> > > > > + - mediatek,mt8183-mdp3-rsz1
> > > >
> > > > Again, what's the difference between 0 and 1?
> > > >
> > > > I've probably asked that before, but without a sufficient
> > > > reasoning
> > > > here in the schema I'm just going to keep asking the same
> > > > question.
> > >
> > > This can probably be, instead, something like
> > >
> > > compatible = "mediatek,mt8183-mdp3-rsz";
> > > reg = < .... >;
> > > mediatek,instance-id = <0>;
> > > gce reg, clocks, blah...
> > >
> > > or
> > >
> > > compatible = "mediatek,mt8183-mdp3-rsz";
> > > reg = < ...rsz0... >, < ...rsz1... >;
> > > reg-names = "rsz0", "rsz1";
> > > gce reg, clocks, blah...
> > >
> > >
> > > ...In any case, if MediaTek chose to separate these like that, I
> > > guess that
> > > there will be differences in newer SoCs that would make that kind
> > > of
> > > binding
> > > much necessary.
> > >
> > > Please Moudy, can you explain why you didn't write that like the
> > > examples
> > > that I provided there?
> >
> > Before version 10 it was written the same way as the first form
> > Angelo
> > mentioned - with h/w indexed properties, but Rob thinks it's bad
> > idea.
> > At that time I asked Rob if it could be rewritten into its current
> > V11
> > form, but I updated before I got a suggestion.
> > Apologize for the inconvenience casued by my careless handling.
> >
> > In the 8183 MDP3, only RSZ is configured with 2 sets. The 1st set
> > upstream can have quality adjustment components (like AAL or CCORR
> > or
> > both) connected, but the 2nd set does not.
> > Although those two RSZ components have the same hardware function
> > but
> > register address. The MDP paths with different functions will be
> > created due to the different upstream and downstream connections.
> > In addition to the various upstream/downstream connection methods
> > caused by chip design, the above conditions are also dynamically
> > determined according to the current usage scenario(with or without
> > PQ,
> > rotation...etc).
> > Also, considering that multiple paths are used at the same time,
> > MDP3
> > will need to know which components are currently available for
> > dispatch.
> > At present, I can't find a better description form, let me know if
> > you
> > have any thoughts with this.
> >
> > > >
> > > > Rob
> > > >
> >
> > Thanks,
> > Moudy
>
> Hi Rob and Angelo,
>
> I tried to draw the flow to illustrate that there will be different
> selections of component (RSZ0 or RSZ1) because of the different
> target
> paths created.
+------------+ +------------+
| RDMA0 | | ISP[*1] |
+---+--+--+--+ +-----+--+---+
A B C 2 1
v v v v v
| | | | |
| | +---------+ | |
| | | | |
| +-------+ | | |
| | | | |
| +-------+----+---------+ |
| | | | |
| | | +---------+ |
v v | | |
A 2 | | |
******** | | |
** ** | | |
* PQ[*2] * | | |
** ** | | |
******** | | |
| | | | |
v v | v v
A 2 | C 1
+---+--+---+ | +-----+--+--+
| RSZ0 | | | RSZ1 |
+---+------+ | +-----+--+--+
D | 3 4
v | v v
| | | |
| +-------+ | |
| | | |
| | +-------------------+ |
| | | |
v v v v
D B 3 4
+---+--+--+--+ +---------+--+
| WROT0 | | WDMA |
+------------+ +------------+
update diagram for typesetting
> [*1] Direct-link path for camera input
> [*2] A series of
> picture quality adjustment
> engines, composed of AAL, CCORR, TDSHP
> and COLOR
>
> Although components RSZ0 and RSZ1 have the same HW function,
> considering that the components corresponding to their upstream and
> downstream are different, paths with different functions can be
> created
> as approprate.
> There are 3 paths from RDMA0, which are
> A. Path with full PQ(picture quality) adjustments, resize and
> rotation.
> B. rotation only.
> C. Path with resize and rotation.
>
> For direct-link input, there has 2 possible path, which are
> 1. Main path: write buffer with resize function
> 2. Secondary path: can only be used when the picked components are
> free.
>
> Combining the above features, it can create one of the 5 paths, or
> dual
> paths at the same time such as: A+1, B+1 or C(4)+2. In further chips,
> the number of multi-components and paths will increase.
> Is there a more appropriate way to replace the HW index for this
> design?
>
> Thanks,
> Moudy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v11 0/3] media: mediatek: support mdp3 on mt8183 platform
2022-01-05 9:37 [PATCH v11 0/3] media: mediatek: support mdp3 on mt8183 platform Moudy Ho
2022-01-05 9:37 ` [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings Moudy Ho
2022-01-05 9:37 ` [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes Moudy Ho
@ 2022-03-16 8:35 ` AngeloGioacchino Del Regno
2 siblings, 0 replies; 12+ messages in thread
From: AngeloGioacchino Del Regno @ 2022-03-16 8:35 UTC (permalink / raw)
To: Moudy Ho, Mauro Carvalho Chehab, Rob Herring, Matthias Brugger,
Hans Verkuil, Jernej Skrabec
Cc: Chun-Kuang Hu, Geert Uytterhoeven, Rob Landley, Laurent Pinchart,
linux-media, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel, Alexandre Courbot, tfiga, drinkcat, pihsun, hsinyi,
Maoguang Meng, daoyuan huang, Ping-Hsun Wu, menghui.lin,
sj.huang, allen-kh.cheng, randy.wu, jason-jh.lin, roy-cw.yeh,
river.cheng, srv_heupstream
Il 05/01/22 10:37, Moudy Ho ha scritto:
> Change since v10:
> - The routing table needs to be discarded, and the calculation result
> on the SCP side is used to write a suitable mux setting for
> 1 input port and 2 output ports.
> - Adjust dts parsing flow to remove redundant HW IDs.
> - Fix memory leak caused by no free path information in function "mdp_cmdq_send".
>
> Change since v9:
> - Keep only the MDP3 driver patches and split the remaining mmsys and
> mutex patches into another mail.
> - Move mutex mod settings to corresponding driver and make relevant adjustments
> for this in MDP3 driver.
> - Fix compile warning reported by kernel test robot.
>
> Change since v8:
> - Rebase on v5.16-rc2.
> - Refer to Angelo's suggestion, adjust the register writing format to increase
> readability and significance.
> - Refer to Angelo's suggestion, adjust or reduce inappropriate debugging
> messages.
> - Refer to Rob Herring's suggestion to correct the the binding file
> to make it with the specification.
> - Fix compile warning reported by kernel test robot.
>
> Change since v7:
> - Rebase on v5.15-rc6.
> - Revise several V4L2 M2M settings to pass v4l2-compliance test.
> - Integrate those same component dt-binding documents of DRM and MDP, and
> move them under the MMSYS domain.
> - Split MMSYS and MUTEX into two different files according to
> their functional properties.
>
> Changes since v6:
> - Refactor GCE event to corresponding node.
> - Fix dt_binding_check fail.
> - Fix compilation errors.
>
> Changes since v5:
> - Rebase on v5.14-rc6.
> - Move MMSYS/Mutex settings to corresponding driver.
> - Revise the software license description and copyright.
> - Remove unnecessary enum. or definitions.
> - Optimize platform/chip definition conditions.
> - Use general printing functions instead of MDP3 private ones.
> - Fix compile warning.
>
> Changes since v4:
> - Rebase on v5.13-rc1.
> - Remove the CMDQ flush flow to match the CMDQ API change.
> - Integrate four of MDP's direct-link subcomponents into MDP controller node
> from syscon node to avoid illegal clock usage.
> - Rewrite dt-binding in a JSON compatible subset of YAML
> - Fix a bit of macro argument precedence.
>
> Changes since v3:
> - Rebase on v5.9-rc1.
> - modify code for review comment from Rob Herring, cancel multiple nodes using
> same register base situation.
> - control IOMMU port through pm runtime get/put to DMA components' device.
> - SCP(VPU) driver revision.
> - stop queuing jobs(remove flush_workqueue()) after mdp_m2m_release().
> - add computation of plane address with data_offset.
> - fix scale ratio check issue.
> - add default v4l2_format setting.
>
> Changes since v2:
> - modify code for review comment from Tomasz Figa & Alexandre Courbot
> - review comment from Rob Herring will offer code revision in v4, due to
> it's related to device node modification, will need to modify code
> architecture
>
> Changes since v1:
> - modify code for CMDQ v3 API support
> - EC ipi cmd migration
> - fix compliance test fail item (m2m cmd with -f) due to there is two problem in runing all format(-f) cmd:
> 1. out of memory before test complete
> Due to capture buffer mmap (refcount + 1) after reqbuf but seems
> no corresponding munmap called before device close.
> There are total 12XX items(formats) in format test and each format
> alloc 8 capture/output buffers.
> 2. unceasingly captureBufs() (randomly)
> Seems the break statement didn't catch the count == 0 situation:
> In v4l2-test-buffers.cpp, function: captureBufs()
> ...
> count--;
> if (!node->is_m2m && !count)
> break;
> Log is as attachment
>
> I will paste the test result with problem part in another e-mail
>
> Hi,
>
> This is the first version of RFC patch for Media Data Path 3 (MDP3),
> MDP3 is used for scaling and color format conversion.
> support using GCE to write register in critical time limitation.
> support V4L2 m2m device control.
>
> Moudy Ho (3):
> dt-binding: mt8183: add Mediatek MDP3 dt-bindings
> dts: arm64: mt8183: add Mediatek MDP3 nodes
> media: platform: mtk-mdp3: add Mediatek MDP3 driver
>
Hello Moudy,
In next-20220315, all MediaTek media drivers have been moved in a different
subdirectory. Now they are all in drivers/media/platform/mediatek/.
Can you please rebase this series, placing the MDP3 driver in
drivers/media/platform/mediatek/mdp3 ?
While at it, also please include the additional documentation and address the
rdma/rsz (etc) suggestions about using one compatible and a instance-id property
to express the multiple instances (remember: "mediatek,mt8183-mdp3-rdma",
mediatek,instance-id = <0>).... and all the other constructive suggestions that
were given during the extensive review of patch 1/3 of this series.
Looking forward to see a new version!
Regards,
Angelo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-03-16 8:37 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-05 9:37 [PATCH v11 0/3] media: mediatek: support mdp3 on mt8183 platform Moudy Ho
2022-01-05 9:37 ` [PATCH v11 1/3] dt-binding: mt8183: add Mediatek MDP3 dt-bindings Moudy Ho
2022-01-21 21:16 ` Rob Herring
2022-01-24 11:40 ` AngeloGioacchino Del Regno
2022-01-26 10:24 ` moudy.ho
2022-02-21 7:47 ` moudy.ho
2022-02-21 8:33 ` moudy.ho
2022-01-05 9:37 ` [PATCH v11 2/3] dts: arm64: mt8183: add Mediatek MDP3 nodes Moudy Ho
2022-01-21 11:58 ` AngeloGioacchino Del Regno
2022-01-25 8:20 ` moudy ho
2022-01-27 10:57 ` AngeloGioacchino Del Regno
2022-03-16 8:35 ` [PATCH v11 0/3] media: mediatek: support mdp3 on mt8183 platform AngeloGioacchino Del Regno
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).