Message ID | 20220509044302.27878-2-rex-bc.chen@mediatek.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | MediaTek MT8195 display binding | expand |
On 09/05/2022 06:43, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 RDMA definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,mdp-rdma.yaml | 94 +++++++++++++++++++ > 1 file changed, 94 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml > > diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml > new file mode 100644 > index 000000000000..ca31accb0a95 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml > @@ -0,0 +1,94 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek MDP RDMA > + > +maintainers: > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > + - Philipp Zabel <p.zabel@pengutronix.de> > + > +description: > + The MediaTek MDP RDMA stands for Read Direct Memory Access. > + It provides real time data to the back-end panel driver, such as DSI, > + DPI and DP_INTF. > + It contains one line buffer to store the sufficient pixel data. > + RDMA device node 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. > + > +properties: > + compatible: > + oneOf: oneOf is not needed > + - items: items not needed, you have only one item. > + - const: mediatek,mt8195-vdo1-rdma > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + power-domains: > + description: A phandle and PM domain specifier as defined by bindings of > + the power controller specified by phandle. See > + Documentation/devicetree/bindings/power/power-domain.yaml for details. Skip description, it's obvious. Instead maxItems. > + > + clocks: > + items: > + - description: RDMA Clock > + > + iommus: > + description: > + This property should point to the respective IOMMU block with master port as argument, > + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. Skip description, it's obvious. Instead maxItems. > + > + mediatek,gce-client-reg: > + description: > + The register of display function block to be set by gce. There are 4 arguments, > + such as gce node, subsys id, offset and register size. The subsys id that is > + mapping to the register of display function blocks is defined in the gce header > + include/include/dt-bindings/gce/<chip>-gce.h of each chips. Double "include" in the path. > + $ref: /schemas/types.yaml#/definitions/phandle-array > + items: > + items: > + - description: phandle of GCE > + - description: GCE subsys id > + - description: register offset > + - description: register size > + maxItems: 1 > + > +required: > + - compatible > + - reg > + - power-domains > + - clocks > + - iommus > + - mediatek,gce-client-reg > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + #include <dt-bindings/clock/mt8195-clk.h> > + #include <dt-bindings/power/mt8195-power.h> > + #include <dt-bindings/gce/mt8195-gce.h> > + #include <dt-bindings/memory/mt8195-memory-port.h> > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + vdo1_rdma0: mdp-rdma@1c104000 { Generic node name. dma-controller (if it does not conflict with dma-common.yaml schema)? > + compatible = "mediatek,mt8195-vdo1-rdma"; > + reg = <0 0x1c104000 0 0x1000>; > + interrupts = <GIC_SPI 495 IRQ_TYPE_LEVEL_HIGH 0>; > + clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; > + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; > + iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>; > + mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX 0x4000 0x1000>; > + }; > + }; Best regards, Krzysztof
On Mon, 2022-05-09 at 15:31 +0800, Krzysztof Kozlowski wrote: > On 09/05/2022 06:43, Rex-BC Chen wrote: > > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > > > Add vdosys1 RDMA definition. > > > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > > Reviewed-by: AngeloGioacchino Del Regno < > > angelogioacchino.delregno@collabora.com> > > --- > > .../display/mediatek/mediatek,mdp-rdma.yaml | 94 > > +++++++++++++++++++ > > 1 file changed, 94 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- > > rdma.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- > > rdma.yaml > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- > > rdma.yaml > > new file mode 100644 > > index 000000000000..ca31accb0a95 > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- > > rdma.yaml > > @@ -0,0 +1,94 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: > > https://urldefense.com/v3/__http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml*__;Iw!!CTRNKA9wMg0ARbw!x6pqRSLbN1fx6j57PKXCTTp8n7bulgpLzXS8uUh5vAIxkRKD8K6EqOopnFrXvT54LQXmIEDFFvPQzC4ldr1TddEeTw$ > > > > +$schema: > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!x6pqRSLbN1fx6j57PKXCTTp8n7bulgpLzXS8uUh5vAIxkRKD8K6EqOopnFrXvT54LQXmIEDFFvPQzC4ldr3y-9sW3w$ > > > > + > > +title: MediaTek MDP RDMA > > + > > +maintainers: > > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > > + - Philipp Zabel <p.zabel@pengutronix.de> > > + > > +description: > > + The MediaTek MDP RDMA stands for Read Direct Memory Access. > > + It provides real time data to the back-end panel driver, such as > > DSI, > > + DPI and DP_INTF. > > + It contains one line buffer to store the sufficient pixel data. > > + RDMA device node 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.ya > > ml for details. > > + > > +properties: > > + compatible: > > + oneOf: > > oneOf is not needed > > > + - items: > > items not needed, you have only one item. > Hello Krzysztof, Thanks for your review. ok, we will drop them. > > + - const: mediatek,mt8195-vdo1-rdma > > + > > + reg: > > + maxItems: 1 > > + > > + interrupts: > > + maxItems: 1 > > + > > + power-domains: > > + description: A phandle and PM domain specifier as defined by > > bindings of > > + the power controller specified by phandle. See > > + Documentation/devicetree/bindings/power/power-domain.yaml > > for details. > > Skip description, it's obvious. Instead maxItems. > ok, we will fix it. > > + > > + clocks: > > + items: > > + - description: RDMA Clock > > + > > + iommus: > > + description: > > + This property should point to the respective IOMMU block > > with master port as argument, > > + see > > Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for > > details. > > Skip description, it's obvious. Instead maxItems. > ok, we will fix it. > > + > > + mediatek,gce-client-reg: > > + description: > > + The register of display function block to be set by gce. > > There are 4 arguments, > > + such as gce node, subsys id, offset and register size. The > > subsys id that is > > + mapping to the register of display function blocks is > > defined in the gce header > > + include/include/dt-bindings/gce/<chip>-gce.h of each chips. > > Double "include" in the path. ok, we will fix it. > > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > + items: > > + items: > > + - description: phandle of GCE > > + - description: GCE subsys id > > + - description: register offset > > + - description: register size > > + maxItems: 1 > > + > > +required: > > + - compatible > > + - reg > > + - power-domains > > + - clocks > > + - iommus > > + - mediatek,gce-client-reg > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + #include <dt-bindings/interrupt-controller/arm-gic.h> > > + #include <dt-bindings/clock/mt8195-clk.h> > > + #include <dt-bindings/power/mt8195-power.h> > > + #include <dt-bindings/gce/mt8195-gce.h> > > + #include <dt-bindings/memory/mt8195-memory-port.h> > > + > > + soc { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + vdo1_rdma0: mdp-rdma@1c104000 { > > Generic node name. dma-controller (if it does not conflict with > dma-common.yaml schema)? We don't understand what dma-controller you are referring to? Can you help explain more? Thanks! BRs, Rex > > > + compatible = "mediatek,mt8195-vdo1-rdma"; > > + reg = <0 0x1c104000 0 0x1000>; > > + interrupts = <GIC_SPI 495 IRQ_TYPE_LEVEL_HIGH 0>; > > + clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; > > + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; > > + iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>; > > + mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX > > 0x4000 0x1000>; > > + }; > > + }; > > > Best regards, > Krzysztof
On Mon, 09 May 2022 12:43:00 +0800, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 RDMA definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,mdp-rdma.yaml | 94 +++++++++++++++++++ > 1 file changed, 94 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.example.dts:27:18: fatal error: dt-bindings/memory/mt8195-memory-port.h: No such file or directory 27 | #include <dt-bindings/memory/mt8195-memory-port.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.example.dtb] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:1401: dt_binding_check] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
On 5/9/22 4:45 PM, Rex-BC Chen wrote: > On Mon, 2022-05-09 at 15:31 +0800, Krzysztof Kozlowski wrote: >> On 09/05/2022 06:43, Rex-BC Chen wrote: >>> From: "Nancy.Lin" <nancy.lin@mediatek.com> >>> >>> Add vdosys1 RDMA definition. >>> >>> Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> >>> Reviewed-by: AngeloGioacchino Del Regno < >>> angelogioacchino.delregno@collabora.com> >>> --- >>> .../display/mediatek/mediatek,mdp-rdma.yaml | 94 >>> +++++++++++++++++++ >>> 1 file changed, 94 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- >>> rdma.yaml >>> >>> diff --git >>> a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- >>> rdma.yaml >>> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- >>> rdma.yaml >>> new file mode 100644 >>> index 000000000000..ca31accb0a95 >>> --- /dev/null >>> +++ >>> b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp- >>> rdma.yaml >>> @@ -0,0 +1,94 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: >>> https://urldefense.com/v3/__http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml*__;Iw!!CTRNKA9wMg0ARbw!x6pqRSLbN1fx6j57PKXCTTp8n7bulgpLzXS8uUh5vAIxkRKD8K6EqOopnFrXvT54LQXmIEDFFvPQzC4ldr1TddEeTw$ >>> >>> +$schema: >>> https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!x6pqRSLbN1fx6j57PKXCTTp8n7bulgpLzXS8uUh5vAIxkRKD8K6EqOopnFrXvT54LQXmIEDFFvPQzC4ldr3y-9sW3w$ >>> >>> + >>> +title: MediaTek MDP RDMA >>> + >>> +maintainers: >>> + - Chun-Kuang Hu <chunkuang.hu@kernel.org> >>> + - Philipp Zabel <p.zabel@pengutronix.de> >>> + >>> +description: >>> + The MediaTek MDP RDMA stands for Read Direct Memory Access. >>> + It provides real time data to the back-end panel driver, such as >>> DSI, >>> + DPI and DP_INTF. >>> + It contains one line buffer to store the sufficient pixel data. >>> + RDMA device node 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.ya >>> ml for details. >>> + >>> +properties: >>> + compatible: >>> + oneOf: >> oneOf is not needed >> >>> + - items: >> items not needed, you have only one item. >> > Hello Krzysztof, > > Thanks for your review. > ok, we will drop them. > >>> + - const: mediatek,mt8195-vdo1-rdma >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + interrupts: >>> + maxItems: 1 >>> + >>> + power-domains: >>> + description: A phandle and PM domain specifier as defined by >>> bindings of >>> + the power controller specified by phandle. See >>> + Documentation/devicetree/bindings/power/power-domain.yaml >>> for details. >> Skip description, it's obvious. Instead maxItems. >> > ok, we will fix it. > >>> + >>> + clocks: >>> + items: >>> + - description: RDMA Clock >>> + >>> + iommus: >>> + description: >>> + This property should point to the respective IOMMU block >>> with master port as argument, >>> + see >>> Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for >>> details. >> Skip description, it's obvious. Instead maxItems. >> > ok, we will fix it. > >>> + >>> + mediatek,gce-client-reg: >>> + description: >>> + The register of display function block to be set by gce. >>> There are 4 arguments, >>> + such as gce node, subsys id, offset and register size. The >>> subsys id that is >>> + mapping to the register of display function blocks is >>> defined in the gce header >>> + include/include/dt-bindings/gce/<chip>-gce.h of each chips. >> Double "include" in the path. > ok, we will fix it. > >>> + $ref: /schemas/types.yaml#/definitions/phandle-array >>> + items: >>> + items: >>> + - description: phandle of GCE >>> + - description: GCE subsys id >>> + - description: register offset >>> + - description: register size >>> + maxItems: 1 >>> + >>> +required: >>> + - compatible >>> + - reg >>> + - power-domains >>> + - clocks >>> + - iommus >>> + - mediatek,gce-client-reg >>> + >>> +additionalProperties: false >>> + >>> +examples: >>> + - | >>> + #include <dt-bindings/interrupt-controller/arm-gic.h> >>> + #include <dt-bindings/clock/mt8195-clk.h> >>> + #include <dt-bindings/power/mt8195-power.h> >>> + #include <dt-bindings/gce/mt8195-gce.h> >>> + #include <dt-bindings/memory/mt8195-memory-port.h> >>> + >>> + soc { >>> + #address-cells = <2>; >>> + #size-cells = <2>; >>> + >>> + vdo1_rdma0: mdp-rdma@1c104000 { >> Generic node name. dma-controller (if it does not conflict with >> dma-common.yaml schema)? > We don't understand what dma-controller you are referring to? Can you > help explain more? Thanks! > > BRs, > Rex Hello Krzysztof, Could you also help us to explain what do you mean here? Thanks! BRs, Rex >>> + compatible = "mediatek,mt8195-vdo1-rdma"; >>> + reg = <0 0x1c104000 0 0x1000>; >>> + interrupts = <GIC_SPI 495 IRQ_TYPE_LEVEL_HIGH 0>; >>> + clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; >>> + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; >>> + iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>; >>> + mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX >>> 0x4000 0x1000>; >>> + }; >>> + }; >> >> Best regards, >> Krzysztof
On 09/05/2022 10:45, Rex-BC Chen wrote: >>> + soc { >>> + #address-cells = <2>; >>> + #size-cells = <2>; >>> + >>> + vdo1_rdma0: mdp-rdma@1c104000 { >> >> Generic node name. dma-controller (if it does not conflict with >> dma-common.yaml schema)? > > We don't understand what dma-controller you are referring to? Can you > help explain more? Thanks! Use a generic node name, as Devicetree spec asks: "The name of a node should be somewhat generic, reflecting the function of the device and not its precise programming model. If appropriate, the name should be one of the following choices:" I proposed dma-controller, but feel free to find better generic node name. Best regards, Krzysztof
On Tue, May 10, 2022 at 6:28 PM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 09/05/2022 10:45, Rex-BC Chen wrote: > >>> + soc { > >>> + #address-cells = <2>; > >>> + #size-cells = <2>; > >>> + > >>> + vdo1_rdma0: mdp-rdma@1c104000 { > >> > >> Generic node name. dma-controller (if it does not conflict with > >> dma-common.yaml schema)? > > > > We don't understand what dma-controller you are referring to? Can you > > help explain more? Thanks! > > Use a generic node name, as Devicetree spec asks: > "The name of a node should be somewhat generic, reflecting the function > of the device and not its precise programming > > model. If appropriate, the name should be one of the following choices:" > > I proposed dma-controller, but feel free to find better generic node name. dma-controller is covered by dma-controller.yaml, which references dma-common.yaml in its entirety, so I don't think that would work. What about "blitter"? I think that is a generic term that is/was commonly used with display hardware and sort of describes the function of the RDMA & WDMA blocks, and if only one side is memory and the other is the display pipeline. Regards ChenYu
On 10/05/2022 12:37, Chen-Yu Tsai wrote: >> Use a generic node name, as Devicetree spec asks: >> "The name of a node should be somewhat generic, reflecting the function >> of the device and not its precise programming >> >> model. If appropriate, the name should be one of the following choices:" >> >> I proposed dma-controller, but feel free to find better generic node name. > > dma-controller is covered by dma-controller.yaml, which references > dma-common.yaml in its entirety, so I don't think that would work. > > What about "blitter"? I think that is a generic term that is/was commonly > used with display hardware and sort of describes the function of the RDMA > & WDMA blocks, and if only one side is memory and the other is the display > pipeline. Sure, sounds fine! Best regards, Krzysztof
On Tue, 2022-05-10 at 18:57 +0800, Krzysztof Kozlowski wrote: > On 10/05/2022 12:37, Chen-Yu Tsai wrote: > > > Use a generic node name, as Devicetree spec asks: > > > "The name of a node should be somewhat generic, reflecting the > > > function > > > of the device and not its precise programming > > > > > > model. If appropriate, the name should be one of the following > > > choices:" > > > > > > I proposed dma-controller, but feel free to find better generic > > > node name. > > > > dma-controller is covered by dma-controller.yaml, which references > > dma-common.yaml in its entirety, so I don't think that would work. > > > > What about "blitter"? I think that is a generic term that is/was > > commonly > > used with display hardware and sort of describes the function of > > the RDMA > > & WDMA blocks, and if only one side is memory and the other is the > > display > > pipeline. > > Sure, sounds fine! > > > Best regards, > Krzysztof Hello Krzysztof and Chen-Yu, Nancy thinks our IP is more like rdma. Blitter may be somthing for reading memory and writing to another memory, but we don't have the function of writing memory. If we use rdma, is it ok? BRs, Rex
On 11/05/2022 04:26, Rex-BC Chen wrote: > Hello Krzysztof and Chen-Yu, > > Nancy thinks our IP is more like rdma. > Blitter may be somthing for reading memory and writing to another > memory, but we don't have the function of writing memory. > If we use rdma, is it ok? Sure. Best regards, Krzysztof
On Mon 2022-05-09 12:43:00, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 RDMA definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Your signoff will be needed, too. Best regards, Pavel
On Mon, 2022-05-30 at 15:06 +0800, Pavel Machek wrote: > On Mon 2022-05-09 12:43:00, Rex-BC Chen wrote: > > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > > > Add vdosys1 RDMA definition. > > > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > > Reviewed-by: AngeloGioacchino Del Regno < > > angelogioacchino.delregno@collabora.com> > > Your signoff will be needed, too. > > Best regards, > Pavel Hello Pavel, ok, I will add it in next version. Thanks. BRs, Bo-Chen
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml new file mode 100644 index 000000000000..ca31accb0a95 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,mdp-rdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek MDP RDMA + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: + The MediaTek MDP RDMA stands for Read Direct Memory Access. + It provides real time data to the back-end panel driver, such as DSI, + DPI and DP_INTF. + It contains one line buffer to store the sufficient pixel data. + RDMA device node 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. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8195-vdo1-rdma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: RDMA Clock + + iommus: + description: + This property should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,gce-client-reg: + description: + The register of display function block to be set by gce. There are 4 arguments, + such as gce node, subsys id, offset and register size. The subsys id that is + mapping to the register of display function blocks is defined in the gce header + include/include/dt-bindings/gce/<chip>-gce.h of each chips. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + items: + - description: phandle of GCE + - description: GCE subsys id + - description: register offset + - description: register size + maxItems: 1 + +required: + - compatible + - reg + - power-domains + - clocks + - iommus + - mediatek,gce-client-reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8195-clk.h> + #include <dt-bindings/power/mt8195-power.h> + #include <dt-bindings/gce/mt8195-gce.h> + #include <dt-bindings/memory/mt8195-memory-port.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + vdo1_rdma0: mdp-rdma@1c104000 { + compatible = "mediatek,mt8195-vdo1-rdma"; + reg = <0 0x1c104000 0 0x1000>; + interrupts = <GIC_SPI 495 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + iommus = <&iommu_vdo M4U_PORT_L2_MDP_RDMA0>; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c10XXXX 0x4000 0x1000>; + }; + };