* [PATCH v2 0/3] MediaTek MT8195 display binding @ 2022-05-09 4:42 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:42 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group, Rex-BC Chen Add this series to present MediaTek display binding for MT8195. The reason I send this series is Jason and Nancy's binding patches are never received by devicetree mail server. Therefore, I help them to resend binding patches. Changes for v2: 1. This patch is based on linux next-20220506. 2. Jason's patches are accepted and I drop them. [1]: https://lore.kernel.org/all/20220504091440.2052-2-nancy.lin@mediatek.com/ Nancy.Lin (3): dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 dt-bindings: reset: mt8195: add vdosys1 reset control bit dt-bindings: mediatek: add ethdr definition for mt8195 .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ .../display/mediatek/mediatek,mdp-rdma.yaml | 94 +++++++++ include/dt-bindings/reset/mt8195-resets.h | 45 +++++ 3 files changed, 330 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml -- 2.18.0 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* [PATCH v2 0/3] MediaTek MT8195 display binding @ 2022-05-09 4:42 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:42 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group, Rex-BC Chen Add this series to present MediaTek display binding for MT8195. The reason I send this series is Jason and Nancy's binding patches are never received by devicetree mail server. Therefore, I help them to resend binding patches. Changes for v2: 1. This patch is based on linux next-20220506. 2. Jason's patches are accepted and I drop them. [1]: https://lore.kernel.org/all/20220504091440.2052-2-nancy.lin@mediatek.com/ Nancy.Lin (3): dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 dt-bindings: reset: mt8195: add vdosys1 reset control bit dt-bindings: mediatek: add ethdr definition for mt8195 .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ .../display/mediatek/mediatek,mdp-rdma.yaml | 94 +++++++++ include/dt-bindings/reset/mt8195-resets.h | 45 +++++ 3 files changed, 330 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml -- 2.18.0 ^ permalink raw reply [flat|nested] 90+ messages in thread
* [PATCH v2 0/3] MediaTek MT8195 display binding @ 2022-05-09 4:42 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:42 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group, Rex-BC Chen Add this series to present MediaTek display binding for MT8195. The reason I send this series is Jason and Nancy's binding patches are never received by devicetree mail server. Therefore, I help them to resend binding patches. Changes for v2: 1. This patch is based on linux next-20220506. 2. Jason's patches are accepted and I drop them. [1]: https://lore.kernel.org/all/20220504091440.2052-2-nancy.lin@mediatek.com/ Nancy.Lin (3): dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 dt-bindings: reset: mt8195: add vdosys1 reset control bit dt-bindings: mediatek: add ethdr definition for mt8195 .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ .../display/mediatek/mediatek,mdp-rdma.yaml | 94 +++++++++ include/dt-bindings/reset/mt8195-resets.h | 45 +++++ 3 files changed, 330 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml -- 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] 90+ messages in thread
* [PATCH v2 0/3] MediaTek MT8195 display binding @ 2022-05-09 4:42 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:42 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Rex-BC Chen, nancy.lin, linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno Add this series to present MediaTek display binding for MT8195. The reason I send this series is Jason and Nancy's binding patches are never received by devicetree mail server. Therefore, I help them to resend binding patches. Changes for v2: 1. This patch is based on linux next-20220506. 2. Jason's patches are accepted and I drop them. [1]: https://lore.kernel.org/all/20220504091440.2052-2-nancy.lin@mediatek.com/ Nancy.Lin (3): dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 dt-bindings: reset: mt8195: add vdosys1 reset control bit dt-bindings: mediatek: add ethdr definition for mt8195 .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ .../display/mediatek/mediatek,mdp-rdma.yaml | 94 +++++++++ include/dt-bindings/reset/mt8195-resets.h | 45 +++++ 3 files changed, 330 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml -- 2.18.0 ^ permalink raw reply [flat|nested] 90+ messages in thread
* [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-09 4:42 ` Rex-BC Chen (?) (?) @ 2022-05-09 4:43 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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: + - 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>; + }; + }; -- 2.18.0 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 4:43 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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: + - 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>; + }; + }; -- 2.18.0 ^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 4:43 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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: + - 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>; + }; + }; -- 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] 90+ messages in thread
* [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 4:43 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, nancy.lin, linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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: + - 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>; + }; + }; -- 2.18.0 ^ permalink raw reply related [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-09 4:43 ` Rex-BC Chen (?) (?) @ 2022-05-09 7:31 ` Krzysztof Kozlowski -1 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 7:31 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 7:31 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 7:31 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 7:31 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 7:31 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 7:31 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 7:31 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, nancy.lin, linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-09 7:31 ` Krzysztof Kozlowski (?) (?) @ 2022-05-09 8:45 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 8:45 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 8:45 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 8:45 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 8:45 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 8:45 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 8:45 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 8:45 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-09 8:45 ` Rex-BC Chen @ 2022-05-10 2:23 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-10 2:23 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 2:23 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-10 2:23 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno [-- Attachment #1: Type: text/html, Size: 11507 bytes --] [-- Attachment #2: Type: text/plain, Size: 5662 bytes --] 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-09 8:45 ` Rex-BC Chen (?) (?) @ 2022-05-10 10:28 ` Krzysztof Kozlowski -1 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 10:28 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 10:28 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 10:28 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 10:28 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 10:28 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 10:28 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 10:28 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-10 10:28 ` Krzysztof Kozlowski (?) (?) @ 2022-05-10 10:37 ` Chen-Yu Tsai -1 siblings, 0 replies; 90+ messages in thread From: Chen-Yu Tsai @ 2022-05-10 10:37 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 10:37 ` Chen-Yu Tsai 0 siblings, 0 replies; 90+ messages in thread From: Chen-Yu Tsai @ 2022-05-10 10:37 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 10:37 ` Chen-Yu Tsai 0 siblings, 0 replies; 90+ messages in thread From: Chen-Yu Tsai @ 2022-05-10 10:37 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 10:37 ` Chen-Yu Tsai 0 siblings, 0 replies; 90+ messages in thread From: Chen-Yu Tsai @ 2022-05-10 10:37 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: chunkuang.hu, krzysztof.kozlowski+dt, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, matthias.bgg, robh+dt, linux-mediatek, Rex-BC Chen, Nancy Lin (林欣螢), linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-10 10:37 ` Chen-Yu Tsai (?) (?) @ 2022-05-10 10:57 ` Krzysztof Kozlowski -1 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 10:57 UTC (permalink / raw) To: Chen-Yu Tsai Cc: chunkuang.hu, krzysztof.kozlowski+dt, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, matthias.bgg, robh+dt, linux-mediatek, Rex-BC Chen, Nancy Lin (林欣螢), linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 10:57 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 10:57 UTC (permalink / raw) To: Chen-Yu Tsai Cc: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 10:57 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 10:57 UTC (permalink / raw) To: Chen-Yu Tsai Cc: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-10 10:57 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 10:57 UTC (permalink / raw) To: Chen-Yu Tsai Cc: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-10 10:57 ` Krzysztof Kozlowski (?) (?) @ 2022-05-11 2:26 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-11 2:26 UTC (permalink / raw) To: Krzysztof Kozlowski, Chen-Yu Tsai Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-11 2:26 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-11 2:26 UTC (permalink / raw) To: Krzysztof Kozlowski, Chen-Yu Tsai Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-11 2:26 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-11 2:26 UTC (permalink / raw) To: Krzysztof Kozlowski, Chen-Yu Tsai Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-11 2:26 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-11 2:26 UTC (permalink / raw) To: Krzysztof Kozlowski, Chen-Yu Tsai Cc: chunkuang.hu, krzysztof.kozlowski+dt, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, robh+dt, linux-mediatek, matthias.bgg, Nancy Lin (林欣螢), linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-11 2:26 ` Rex-BC Chen (?) (?) @ 2022-05-11 7:21 ` Krzysztof Kozlowski -1 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-11 7:21 UTC (permalink / raw) To: Rex-BC Chen, Chen-Yu Tsai Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-11 7:21 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-11 7:21 UTC (permalink / raw) To: Rex-BC Chen, Chen-Yu Tsai Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-11 7:21 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-11 7:21 UTC (permalink / raw) To: Rex-BC Chen, Chen-Yu Tsai Cc: chunkuang.hu, krzysztof.kozlowski+dt, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, robh+dt, linux-mediatek, matthias.bgg, Nancy Lin (林欣螢), linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-11 7:21 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-11 7:21 UTC (permalink / raw) To: Rex-BC Chen, Chen-Yu Tsai Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno 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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-09 4:43 ` Rex-BC Chen (?) (?) @ 2022-05-09 12:20 ` Rob Herring -1 siblings, 0 replies; 90+ messages in thread From: Rob Herring @ 2022-05-09 12:20 UTC (permalink / raw) To: Rex-BC Chen Cc: airlied, robh+dt, angelogioacchino.delregno, matthias.bgg, krzysztof.kozlowski+dt, chunkuang.hu, linux-kernel, dri-devel, linux-arm-kernel, p.zabel, devicetree, jason-jh.lin, Project_Global_Chrome_Upstream_Group, nancy.lin, linux-mediatek 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. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 12:20 ` Rob Herring 0 siblings, 0 replies; 90+ messages in thread From: Rob Herring @ 2022-05-09 12:20 UTC (permalink / raw) To: Rex-BC Chen Cc: airlied, robh+dt, angelogioacchino.delregno, matthias.bgg, krzysztof.kozlowski+dt, chunkuang.hu, linux-kernel, dri-devel, linux-arm-kernel, p.zabel, devicetree, jason-jh.lin, Project_Global_Chrome_Upstream_Group, nancy.lin, linux-mediatek 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. _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 12:20 ` Rob Herring 0 siblings, 0 replies; 90+ messages in thread From: Rob Herring @ 2022-05-09 12:20 UTC (permalink / raw) To: Rex-BC Chen Cc: airlied, robh+dt, angelogioacchino.delregno, matthias.bgg, krzysztof.kozlowski+dt, chunkuang.hu, linux-kernel, dri-devel, linux-arm-kernel, p.zabel, devicetree, jason-jh.lin, Project_Global_Chrome_Upstream_Group, nancy.lin, linux-mediatek 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. _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-09 12:20 ` Rob Herring 0 siblings, 0 replies; 90+ messages in thread From: Rob Herring @ 2022-05-09 12:20 UTC (permalink / raw) To: Rex-BC Chen Cc: chunkuang.hu, devicetree, airlied, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, robh+dt, linux-mediatek, krzysztof.kozlowski+dt, matthias.bgg, nancy.lin, linux-arm-kernel, angelogioacchino.delregno 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. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-09 4:43 ` Rex-BC Chen (?) (?) @ 2022-05-30 7:06 ` Pavel Machek -1 siblings, 0 replies; 90+ messages in thread From: Pavel Machek @ 2022-05-30 7:06 UTC (permalink / raw) To: Rex-BC Chen Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-30 7:06 ` Pavel Machek 0 siblings, 0 replies; 90+ messages in thread From: Pavel Machek @ 2022-05-30 7:06 UTC (permalink / raw) To: Rex-BC Chen Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-30 7:06 ` Pavel Machek 0 siblings, 0 replies; 90+ messages in thread From: Pavel Machek @ 2022-05-30 7:06 UTC (permalink / raw) To: Rex-BC Chen Cc: chunkuang.hu, krzysztof.kozlowski+dt, devicetree, airlied, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, robh+dt, linux-mediatek, matthias.bgg, nancy.lin, linux-arm-kernel, angelogioacchino.delregno 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-05-30 7:06 ` Pavel Machek 0 siblings, 0 replies; 90+ messages in thread From: Pavel Machek @ 2022-05-30 7:06 UTC (permalink / raw) To: Rex-BC Chen Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 2022-05-30 7:06 ` Pavel Machek (?) (?) @ 2022-06-02 3:53 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-06-02 3:53 UTC (permalink / raw) To: Pavel Machek Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-06-02 3:53 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-06-02 3:53 UTC (permalink / raw) To: Pavel Machek Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-06-02 3:53 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-06-02 3:53 UTC (permalink / raw) To: Pavel Machek Cc: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel, airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group 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 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 @ 2022-06-02 3:53 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-06-02 3:53 UTC (permalink / raw) To: Pavel Machek Cc: chunkuang.hu, krzysztof.kozlowski+dt, devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, robh+dt, linux-mediatek, matthias.bgg, Nancy Lin (林欣螢), linux-arm-kernel, angelogioacchino.delregno 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 ^ permalink raw reply [flat|nested] 90+ messages in thread
* [PATCH v2 2/3] dt-bindings: reset: mt8195: add vdosys1 reset control bit 2022-05-09 4:42 ` Rex-BC Chen (?) (?) @ 2022-05-09 4:43 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group From: "Nancy.Lin" <nancy.lin@mediatek.com> Add vdosys1 reset control bit for MT8195 platform. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> --- include/dt-bindings/reset/mt8195-resets.h | 45 +++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/include/dt-bindings/reset/mt8195-resets.h b/include/dt-bindings/reset/mt8195-resets.h index a26bccc8b957..1ccfe2f28964 100644 --- a/include/dt-bindings/reset/mt8195-resets.h +++ b/include/dt-bindings/reset/mt8195-resets.h @@ -26,4 +26,49 @@ #define MT8195_TOPRGU_SW_RST_NUM 16 +/* VDOSYS1 */ +#define MT8195_VDOSYS1_SW0_RST_B_SMI_LARB2 0 +#define MT8195_VDOSYS1_SW0_RST_B_SMI_LARB3 1 +#define MT8195_VDOSYS1_SW0_RST_B_GALS 2 +#define MT8195_VDOSYS1_SW0_RST_B_FAKE_ENG0 3 +#define MT8195_VDOSYS1_SW0_RST_B_FAKE_ENG1 4 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA0 5 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA1 6 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA2 7 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA3 8 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE0 9 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE1 10 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE2 11 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE3 12 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE4 13 +#define MT8195_VDOSYS1_SW0_RST_B_VPP2_TO_VDO1_DL_ASYNC 14 +#define MT8195_VDOSYS1_SW0_RST_B_VPP3_TO_VDO1_DL_ASYNC 15 +#define MT8195_VDOSYS1_SW0_RST_B_DISP_MUTEX 16 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA4 17 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA5 18 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA6 19 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA7 20 +#define MT8195_VDOSYS1_SW0_RST_B_DP_INTF0 21 +#define MT8195_VDOSYS1_SW0_RST_B_DPI0 22 +#define MT8195_VDOSYS1_SW0_RST_B_DPI1 23 +#define MT8195_VDOSYS1_SW0_RST_B_DISP_MONITOR 24 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE0_DL_ASYNC 25 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE1_DL_ASYNC 26 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE2_DL_ASYNC 27 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE3_DL_ASYNC 28 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE4_DL_ASYNC 29 +#define MT8195_VDOSYS1_SW0_RST_B_VDO0_DSC_TO_VDO1_DL_ASYNC 30 +#define MT8195_VDOSYS1_SW0_RST_B_VDO0_MERGE_TO_VDO1_DL_ASYNC 31 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0 32 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0 33 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE 34 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1 48 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1 49 +#define MT8195_VDOSYS1_SW1_RST_B_DISP_MIXER 50 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC 51 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC 52 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC 53 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC 54 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC 55 + #endif /* _DT_BINDINGS_RESET_CONTROLLER_MT8195 */ -- 2.18.0 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 2/3] dt-bindings: reset: mt8195: add vdosys1 reset control bit @ 2022-05-09 4:43 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group From: "Nancy.Lin" <nancy.lin@mediatek.com> Add vdosys1 reset control bit for MT8195 platform. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> --- include/dt-bindings/reset/mt8195-resets.h | 45 +++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/include/dt-bindings/reset/mt8195-resets.h b/include/dt-bindings/reset/mt8195-resets.h index a26bccc8b957..1ccfe2f28964 100644 --- a/include/dt-bindings/reset/mt8195-resets.h +++ b/include/dt-bindings/reset/mt8195-resets.h @@ -26,4 +26,49 @@ #define MT8195_TOPRGU_SW_RST_NUM 16 +/* VDOSYS1 */ +#define MT8195_VDOSYS1_SW0_RST_B_SMI_LARB2 0 +#define MT8195_VDOSYS1_SW0_RST_B_SMI_LARB3 1 +#define MT8195_VDOSYS1_SW0_RST_B_GALS 2 +#define MT8195_VDOSYS1_SW0_RST_B_FAKE_ENG0 3 +#define MT8195_VDOSYS1_SW0_RST_B_FAKE_ENG1 4 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA0 5 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA1 6 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA2 7 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA3 8 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE0 9 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE1 10 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE2 11 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE3 12 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE4 13 +#define MT8195_VDOSYS1_SW0_RST_B_VPP2_TO_VDO1_DL_ASYNC 14 +#define MT8195_VDOSYS1_SW0_RST_B_VPP3_TO_VDO1_DL_ASYNC 15 +#define MT8195_VDOSYS1_SW0_RST_B_DISP_MUTEX 16 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA4 17 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA5 18 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA6 19 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA7 20 +#define MT8195_VDOSYS1_SW0_RST_B_DP_INTF0 21 +#define MT8195_VDOSYS1_SW0_RST_B_DPI0 22 +#define MT8195_VDOSYS1_SW0_RST_B_DPI1 23 +#define MT8195_VDOSYS1_SW0_RST_B_DISP_MONITOR 24 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE0_DL_ASYNC 25 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE1_DL_ASYNC 26 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE2_DL_ASYNC 27 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE3_DL_ASYNC 28 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE4_DL_ASYNC 29 +#define MT8195_VDOSYS1_SW0_RST_B_VDO0_DSC_TO_VDO1_DL_ASYNC 30 +#define MT8195_VDOSYS1_SW0_RST_B_VDO0_MERGE_TO_VDO1_DL_ASYNC 31 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0 32 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0 33 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE 34 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1 48 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1 49 +#define MT8195_VDOSYS1_SW1_RST_B_DISP_MIXER 50 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC 51 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC 52 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC 53 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC 54 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC 55 + #endif /* _DT_BINDINGS_RESET_CONTROLLER_MT8195 */ -- 2.18.0 ^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 2/3] dt-bindings: reset: mt8195: add vdosys1 reset control bit @ 2022-05-09 4:43 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group From: "Nancy.Lin" <nancy.lin@mediatek.com> Add vdosys1 reset control bit for MT8195 platform. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> --- include/dt-bindings/reset/mt8195-resets.h | 45 +++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/include/dt-bindings/reset/mt8195-resets.h b/include/dt-bindings/reset/mt8195-resets.h index a26bccc8b957..1ccfe2f28964 100644 --- a/include/dt-bindings/reset/mt8195-resets.h +++ b/include/dt-bindings/reset/mt8195-resets.h @@ -26,4 +26,49 @@ #define MT8195_TOPRGU_SW_RST_NUM 16 +/* VDOSYS1 */ +#define MT8195_VDOSYS1_SW0_RST_B_SMI_LARB2 0 +#define MT8195_VDOSYS1_SW0_RST_B_SMI_LARB3 1 +#define MT8195_VDOSYS1_SW0_RST_B_GALS 2 +#define MT8195_VDOSYS1_SW0_RST_B_FAKE_ENG0 3 +#define MT8195_VDOSYS1_SW0_RST_B_FAKE_ENG1 4 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA0 5 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA1 6 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA2 7 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA3 8 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE0 9 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE1 10 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE2 11 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE3 12 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE4 13 +#define MT8195_VDOSYS1_SW0_RST_B_VPP2_TO_VDO1_DL_ASYNC 14 +#define MT8195_VDOSYS1_SW0_RST_B_VPP3_TO_VDO1_DL_ASYNC 15 +#define MT8195_VDOSYS1_SW0_RST_B_DISP_MUTEX 16 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA4 17 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA5 18 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA6 19 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA7 20 +#define MT8195_VDOSYS1_SW0_RST_B_DP_INTF0 21 +#define MT8195_VDOSYS1_SW0_RST_B_DPI0 22 +#define MT8195_VDOSYS1_SW0_RST_B_DPI1 23 +#define MT8195_VDOSYS1_SW0_RST_B_DISP_MONITOR 24 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE0_DL_ASYNC 25 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE1_DL_ASYNC 26 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE2_DL_ASYNC 27 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE3_DL_ASYNC 28 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE4_DL_ASYNC 29 +#define MT8195_VDOSYS1_SW0_RST_B_VDO0_DSC_TO_VDO1_DL_ASYNC 30 +#define MT8195_VDOSYS1_SW0_RST_B_VDO0_MERGE_TO_VDO1_DL_ASYNC 31 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0 32 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0 33 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE 34 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1 48 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1 49 +#define MT8195_VDOSYS1_SW1_RST_B_DISP_MIXER 50 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC 51 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC 52 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC 53 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC 54 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC 55 + #endif /* _DT_BINDINGS_RESET_CONTROLLER_MT8195 */ -- 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] 90+ messages in thread
* [PATCH v2 2/3] dt-bindings: reset: mt8195: add vdosys1 reset control bit @ 2022-05-09 4:43 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, nancy.lin, linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno From: "Nancy.Lin" <nancy.lin@mediatek.com> Add vdosys1 reset control bit for MT8195 platform. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> --- include/dt-bindings/reset/mt8195-resets.h | 45 +++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/include/dt-bindings/reset/mt8195-resets.h b/include/dt-bindings/reset/mt8195-resets.h index a26bccc8b957..1ccfe2f28964 100644 --- a/include/dt-bindings/reset/mt8195-resets.h +++ b/include/dt-bindings/reset/mt8195-resets.h @@ -26,4 +26,49 @@ #define MT8195_TOPRGU_SW_RST_NUM 16 +/* VDOSYS1 */ +#define MT8195_VDOSYS1_SW0_RST_B_SMI_LARB2 0 +#define MT8195_VDOSYS1_SW0_RST_B_SMI_LARB3 1 +#define MT8195_VDOSYS1_SW0_RST_B_GALS 2 +#define MT8195_VDOSYS1_SW0_RST_B_FAKE_ENG0 3 +#define MT8195_VDOSYS1_SW0_RST_B_FAKE_ENG1 4 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA0 5 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA1 6 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA2 7 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA3 8 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE0 9 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE1 10 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE2 11 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE3 12 +#define MT8195_VDOSYS1_SW0_RST_B_VPP_MERGE4 13 +#define MT8195_VDOSYS1_SW0_RST_B_VPP2_TO_VDO1_DL_ASYNC 14 +#define MT8195_VDOSYS1_SW0_RST_B_VPP3_TO_VDO1_DL_ASYNC 15 +#define MT8195_VDOSYS1_SW0_RST_B_DISP_MUTEX 16 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA4 17 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA5 18 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA6 19 +#define MT8195_VDOSYS1_SW0_RST_B_MDP_RDMA7 20 +#define MT8195_VDOSYS1_SW0_RST_B_DP_INTF0 21 +#define MT8195_VDOSYS1_SW0_RST_B_DPI0 22 +#define MT8195_VDOSYS1_SW0_RST_B_DPI1 23 +#define MT8195_VDOSYS1_SW0_RST_B_DISP_MONITOR 24 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE0_DL_ASYNC 25 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE1_DL_ASYNC 26 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE2_DL_ASYNC 27 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE3_DL_ASYNC 28 +#define MT8195_VDOSYS1_SW0_RST_B_MERGE4_DL_ASYNC 29 +#define MT8195_VDOSYS1_SW0_RST_B_VDO0_DSC_TO_VDO1_DL_ASYNC 30 +#define MT8195_VDOSYS1_SW0_RST_B_VDO0_MERGE_TO_VDO1_DL_ASYNC 31 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0 32 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0 33 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE 34 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1 48 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1 49 +#define MT8195_VDOSYS1_SW1_RST_B_DISP_MIXER 50 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC 51 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC 52 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC 53 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC 54 +#define MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC 55 + #endif /* _DT_BINDINGS_RESET_CONTROLLER_MT8195 */ -- 2.18.0 ^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 2022-05-09 4:42 ` Rex-BC Chen (?) (?) @ 2022-05-09 4:43 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group From: "Nancy.Lin" <nancy.lin@mediatek.com> Add vdosys1 ETHDR definition. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> --- .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ 1 file changed, 191 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml new file mode 100644 index 000000000000..65f22fba9fed --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml @@ -0,0 +1,191 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Ethdr Device Tree Bindings + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: + ETHDR is designed for HDR video and graphics conversion in the external display path. + It handles multiple HDR input types and performs tone mapping, color space/color + format conversion, and then combine different layers, output the required HDR or + SDR signal to the subsequent display path. This engine is composed of two video + frontends, two graphic frontends, one video backend and a mixer. ETHDR has two + DMA function blocks, DS and ADL. These two function blocks read the pre-programmed + registers from DRAM and set them to HW in the v-blanking period. + +properties: + compatible: + items: + - const: mediatek,mt8195-disp-ethdr + + reg: + maxItems: 7 + + reg-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + + interrupts: + maxItems: 1 + + iommus: + description: The compatible property is DMA function blocks. + Should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for + details. + minItems: 1 + maxItems: 2 + + clocks: + items: + - description: mixer clock + - description: video frontend 0 clock + - description: video frontend 1 clock + - description: graphic frontend 0 clock + - description: graphic frontend 1 clock + - description: video backend clock + - description: autodownload and menuload clock + - description: video frontend 0 async clock + - description: video frontend 1 async clock + - description: graphic frontend 0 async clock + - description: graphic frontend 1 async clock + - description: video backend async clock + - description: ethdr top clock + + clock-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + - const: ethdr_top + + power-domains: + maxItems: 1 + + resets: + items: + - description: video frontend 0 async reset + - description: video frontend 1 async reset + - description: graphic frontend 0 async reset + - description: graphic frontend 1 async reset + - description: video backend async reset + + reset-names: + items: + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + + mediatek,gce-client-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: The register of display function block to be set by gce. + There are 4 arguments in this property, gce node, subsys id, offset and + register size. The subsys id is defined in the gce header of each chips + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the register of + display function block. + items: + items: + - description: phandle of GCE + - description: GCE subsys id + - description: register offset + - description: register size + minItems: 7 + maxItems: 7 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - power-domains + - resets + - 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/gce/mt8195-gce.h> + #include <dt-bindings/memory/mt8195-memory-port.h> + #include <dt-bindings/power/mt8195-power.h> + #include <dt-bindings/reset/mt8195-resets.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + disp_ethdr@1c114000 { + compatible = "mediatek,mt8195-disp-ethdr"; + reg = <0 0x1c114000 0 0x1000>, + <0 0x1c115000 0 0x1000>, + <0 0x1c117000 0 0x1000>, + <0 0x1c119000 0 0x1000>, + <0 0x1c11a000 0 0x1000>, + <0 0x1c11b000 0 0x1000>, + <0 0x1c11b000 0 0x1000>; + reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds"; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0x4000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x5000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x7000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x9000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xa000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xb000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xc000 0x1000>; + clocks = <&vdosys1 CLK_VDO1_DISP_MIXER>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE>, + <&vdosys1 CLK_VDO1_26M_SLOW>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE_DL_ASYNC>, + <&topckgen CLK_TOP_ETHDR>; + clock-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds", "vdo_fe0_async", "vdo_fe1_async", + "gfx_fe0_async", "gfx_fe1_async","vdo_be_async", + "ethdr_top"; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + iommus = <&iommu_vpp M4U_PORT_L3_HDR_DS>, + <&iommu_vpp M4U_PORT_L3_HDR_ADL>; + interrupts = <GIC_SPI 517 IRQ_TYPE_LEVEL_HIGH 0>; /* disp mixer */ + resets = <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC>; + reset-names = "vdo_fe0_async", "vdo_fe1_async", "gfx_fe0_async", + "gfx_fe1_async", "vdo_be_async"; + }; + }; +... -- 2.18.0 _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 4:43 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group From: "Nancy.Lin" <nancy.lin@mediatek.com> Add vdosys1 ETHDR definition. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> --- .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ 1 file changed, 191 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml new file mode 100644 index 000000000000..65f22fba9fed --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml @@ -0,0 +1,191 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Ethdr Device Tree Bindings + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: + ETHDR is designed for HDR video and graphics conversion in the external display path. + It handles multiple HDR input types and performs tone mapping, color space/color + format conversion, and then combine different layers, output the required HDR or + SDR signal to the subsequent display path. This engine is composed of two video + frontends, two graphic frontends, one video backend and a mixer. ETHDR has two + DMA function blocks, DS and ADL. These two function blocks read the pre-programmed + registers from DRAM and set them to HW in the v-blanking period. + +properties: + compatible: + items: + - const: mediatek,mt8195-disp-ethdr + + reg: + maxItems: 7 + + reg-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + + interrupts: + maxItems: 1 + + iommus: + description: The compatible property is DMA function blocks. + Should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for + details. + minItems: 1 + maxItems: 2 + + clocks: + items: + - description: mixer clock + - description: video frontend 0 clock + - description: video frontend 1 clock + - description: graphic frontend 0 clock + - description: graphic frontend 1 clock + - description: video backend clock + - description: autodownload and menuload clock + - description: video frontend 0 async clock + - description: video frontend 1 async clock + - description: graphic frontend 0 async clock + - description: graphic frontend 1 async clock + - description: video backend async clock + - description: ethdr top clock + + clock-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + - const: ethdr_top + + power-domains: + maxItems: 1 + + resets: + items: + - description: video frontend 0 async reset + - description: video frontend 1 async reset + - description: graphic frontend 0 async reset + - description: graphic frontend 1 async reset + - description: video backend async reset + + reset-names: + items: + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + + mediatek,gce-client-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: The register of display function block to be set by gce. + There are 4 arguments in this property, gce node, subsys id, offset and + register size. The subsys id is defined in the gce header of each chips + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the register of + display function block. + items: + items: + - description: phandle of GCE + - description: GCE subsys id + - description: register offset + - description: register size + minItems: 7 + maxItems: 7 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - power-domains + - resets + - 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/gce/mt8195-gce.h> + #include <dt-bindings/memory/mt8195-memory-port.h> + #include <dt-bindings/power/mt8195-power.h> + #include <dt-bindings/reset/mt8195-resets.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + disp_ethdr@1c114000 { + compatible = "mediatek,mt8195-disp-ethdr"; + reg = <0 0x1c114000 0 0x1000>, + <0 0x1c115000 0 0x1000>, + <0 0x1c117000 0 0x1000>, + <0 0x1c119000 0 0x1000>, + <0 0x1c11a000 0 0x1000>, + <0 0x1c11b000 0 0x1000>, + <0 0x1c11b000 0 0x1000>; + reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds"; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0x4000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x5000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x7000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x9000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xa000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xb000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xc000 0x1000>; + clocks = <&vdosys1 CLK_VDO1_DISP_MIXER>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE>, + <&vdosys1 CLK_VDO1_26M_SLOW>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE_DL_ASYNC>, + <&topckgen CLK_TOP_ETHDR>; + clock-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds", "vdo_fe0_async", "vdo_fe1_async", + "gfx_fe0_async", "gfx_fe1_async","vdo_be_async", + "ethdr_top"; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + iommus = <&iommu_vpp M4U_PORT_L3_HDR_DS>, + <&iommu_vpp M4U_PORT_L3_HDR_ADL>; + interrupts = <GIC_SPI 517 IRQ_TYPE_LEVEL_HIGH 0>; /* disp mixer */ + resets = <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC>; + reset-names = "vdo_fe0_async", "vdo_fe1_async", "gfx_fe0_async", + "gfx_fe1_async", "vdo_be_async"; + }; + }; +... -- 2.18.0 ^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 4:43 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group From: "Nancy.Lin" <nancy.lin@mediatek.com> Add vdosys1 ETHDR definition. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> --- .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ 1 file changed, 191 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml new file mode 100644 index 000000000000..65f22fba9fed --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml @@ -0,0 +1,191 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Ethdr Device Tree Bindings + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: + ETHDR is designed for HDR video and graphics conversion in the external display path. + It handles multiple HDR input types and performs tone mapping, color space/color + format conversion, and then combine different layers, output the required HDR or + SDR signal to the subsequent display path. This engine is composed of two video + frontends, two graphic frontends, one video backend and a mixer. ETHDR has two + DMA function blocks, DS and ADL. These two function blocks read the pre-programmed + registers from DRAM and set them to HW in the v-blanking period. + +properties: + compatible: + items: + - const: mediatek,mt8195-disp-ethdr + + reg: + maxItems: 7 + + reg-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + + interrupts: + maxItems: 1 + + iommus: + description: The compatible property is DMA function blocks. + Should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for + details. + minItems: 1 + maxItems: 2 + + clocks: + items: + - description: mixer clock + - description: video frontend 0 clock + - description: video frontend 1 clock + - description: graphic frontend 0 clock + - description: graphic frontend 1 clock + - description: video backend clock + - description: autodownload and menuload clock + - description: video frontend 0 async clock + - description: video frontend 1 async clock + - description: graphic frontend 0 async clock + - description: graphic frontend 1 async clock + - description: video backend async clock + - description: ethdr top clock + + clock-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + - const: ethdr_top + + power-domains: + maxItems: 1 + + resets: + items: + - description: video frontend 0 async reset + - description: video frontend 1 async reset + - description: graphic frontend 0 async reset + - description: graphic frontend 1 async reset + - description: video backend async reset + + reset-names: + items: + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + + mediatek,gce-client-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: The register of display function block to be set by gce. + There are 4 arguments in this property, gce node, subsys id, offset and + register size. The subsys id is defined in the gce header of each chips + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the register of + display function block. + items: + items: + - description: phandle of GCE + - description: GCE subsys id + - description: register offset + - description: register size + minItems: 7 + maxItems: 7 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - power-domains + - resets + - 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/gce/mt8195-gce.h> + #include <dt-bindings/memory/mt8195-memory-port.h> + #include <dt-bindings/power/mt8195-power.h> + #include <dt-bindings/reset/mt8195-resets.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + disp_ethdr@1c114000 { + compatible = "mediatek,mt8195-disp-ethdr"; + reg = <0 0x1c114000 0 0x1000>, + <0 0x1c115000 0 0x1000>, + <0 0x1c117000 0 0x1000>, + <0 0x1c119000 0 0x1000>, + <0 0x1c11a000 0 0x1000>, + <0 0x1c11b000 0 0x1000>, + <0 0x1c11b000 0 0x1000>; + reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds"; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0x4000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x5000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x7000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x9000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xa000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xb000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xc000 0x1000>; + clocks = <&vdosys1 CLK_VDO1_DISP_MIXER>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE>, + <&vdosys1 CLK_VDO1_26M_SLOW>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE_DL_ASYNC>, + <&topckgen CLK_TOP_ETHDR>; + clock-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds", "vdo_fe0_async", "vdo_fe1_async", + "gfx_fe0_async", "gfx_fe1_async","vdo_be_async", + "ethdr_top"; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + iommus = <&iommu_vpp M4U_PORT_L3_HDR_DS>, + <&iommu_vpp M4U_PORT_L3_HDR_ADL>; + interrupts = <GIC_SPI 517 IRQ_TYPE_LEVEL_HIGH 0>; /* disp mixer */ + resets = <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC>; + reset-names = "vdo_fe0_async", "vdo_fe1_async", "gfx_fe0_async", + "gfx_fe1_async", "vdo_be_async"; + }; + }; +... -- 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] 90+ messages in thread
* [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 4:43 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 4:43 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, nancy.lin, linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno From: "Nancy.Lin" <nancy.lin@mediatek.com> Add vdosys1 ETHDR definition. Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> --- .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ 1 file changed, 191 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml new file mode 100644 index 000000000000..65f22fba9fed --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml @@ -0,0 +1,191 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Ethdr Device Tree Bindings + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: + ETHDR is designed for HDR video and graphics conversion in the external display path. + It handles multiple HDR input types and performs tone mapping, color space/color + format conversion, and then combine different layers, output the required HDR or + SDR signal to the subsequent display path. This engine is composed of two video + frontends, two graphic frontends, one video backend and a mixer. ETHDR has two + DMA function blocks, DS and ADL. These two function blocks read the pre-programmed + registers from DRAM and set them to HW in the v-blanking period. + +properties: + compatible: + items: + - const: mediatek,mt8195-disp-ethdr + + reg: + maxItems: 7 + + reg-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + + interrupts: + maxItems: 1 + + iommus: + description: The compatible property is DMA function blocks. + Should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for + details. + minItems: 1 + maxItems: 2 + + clocks: + items: + - description: mixer clock + - description: video frontend 0 clock + - description: video frontend 1 clock + - description: graphic frontend 0 clock + - description: graphic frontend 1 clock + - description: video backend clock + - description: autodownload and menuload clock + - description: video frontend 0 async clock + - description: video frontend 1 async clock + - description: graphic frontend 0 async clock + - description: graphic frontend 1 async clock + - description: video backend async clock + - description: ethdr top clock + + clock-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + - const: ethdr_top + + power-domains: + maxItems: 1 + + resets: + items: + - description: video frontend 0 async reset + - description: video frontend 1 async reset + - description: graphic frontend 0 async reset + - description: graphic frontend 1 async reset + - description: video backend async reset + + reset-names: + items: + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + + mediatek,gce-client-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: The register of display function block to be set by gce. + There are 4 arguments in this property, gce node, subsys id, offset and + register size. The subsys id is defined in the gce header of each chips + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the register of + display function block. + items: + items: + - description: phandle of GCE + - description: GCE subsys id + - description: register offset + - description: register size + minItems: 7 + maxItems: 7 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - power-domains + - resets + - 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/gce/mt8195-gce.h> + #include <dt-bindings/memory/mt8195-memory-port.h> + #include <dt-bindings/power/mt8195-power.h> + #include <dt-bindings/reset/mt8195-resets.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + disp_ethdr@1c114000 { + compatible = "mediatek,mt8195-disp-ethdr"; + reg = <0 0x1c114000 0 0x1000>, + <0 0x1c115000 0 0x1000>, + <0 0x1c117000 0 0x1000>, + <0 0x1c119000 0 0x1000>, + <0 0x1c11a000 0 0x1000>, + <0 0x1c11b000 0 0x1000>, + <0 0x1c11b000 0 0x1000>; + reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds"; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0x4000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x5000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x7000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x9000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xa000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xb000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xc000 0x1000>; + clocks = <&vdosys1 CLK_VDO1_DISP_MIXER>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE>, + <&vdosys1 CLK_VDO1_26M_SLOW>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE_DL_ASYNC>, + <&topckgen CLK_TOP_ETHDR>; + clock-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds", "vdo_fe0_async", "vdo_fe1_async", + "gfx_fe0_async", "gfx_fe1_async","vdo_be_async", + "ethdr_top"; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + iommus = <&iommu_vpp M4U_PORT_L3_HDR_DS>, + <&iommu_vpp M4U_PORT_L3_HDR_ADL>; + interrupts = <GIC_SPI 517 IRQ_TYPE_LEVEL_HIGH 0>; /* disp mixer */ + resets = <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC>; + reset-names = "vdo_fe0_async", "vdo_fe1_async", "gfx_fe0_async", + "gfx_fe1_async", "vdo_be_async"; + }; + }; +... -- 2.18.0 ^ permalink raw reply related [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 2022-05-09 4:43 ` Rex-BC Chen (?) (?) @ 2022-05-09 7:35 ` Krzysztof Kozlowski -1 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 7:35 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On 09/05/2022 06:43, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 ETHDR definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ > 1 file changed, 191 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > > diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > new file mode 100644 > index 000000000000..65f22fba9fed > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > @@ -0,0 +1,191 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek Ethdr Device Tree Bindings s/Device Tree Bindings// You need to add some description of a device. What is a Ethdr? > + > +maintainers: > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > + - Philipp Zabel <p.zabel@pengutronix.de> > + > +description: > + ETHDR is designed for HDR video and graphics conversion in the external display path. > + It handles multiple HDR input types and performs tone mapping, color space/color > + format conversion, and then combine different layers, output the required HDR or > + SDR signal to the subsequent display path. This engine is composed of two video > + frontends, two graphic frontends, one video backend and a mixer. ETHDR has two > + DMA function blocks, DS and ADL. These two function blocks read the pre-programmed > + registers from DRAM and set them to HW in the v-blanking period. Block does not look like wrapped at 80. > + > +properties: > + compatible: > + items: One item, so no items. > + - const: mediatek,mt8195-disp-ethdr > + > + reg: > + maxItems: 7 > + > + reg-names: > + items: > + - const: mixer > + - const: vdo_fe0 > + - const: vdo_fe1 > + - const: gfx_fe0 > + - const: gfx_fe1 > + - const: vdo_be > + - const: adl_ds > + > + interrupts: > + maxItems: 1 > + > + iommus: > + description: The compatible property is DMA function blocks. I don't understand this at all. > + Should point to the respective IOMMU block with master port as argument, > + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for > + details. Just skip the description, it's same everywhere. > + minItems: 1 > + maxItems: 2 > + > + clocks: > + items: > + - description: mixer clock > + - description: video frontend 0 clock > + - description: video frontend 1 clock > + - description: graphic frontend 0 clock > + - description: graphic frontend 1 clock > + - description: video backend clock > + - description: autodownload and menuload clock > + - description: video frontend 0 async clock > + - description: video frontend 1 async clock > + - description: graphic frontend 0 async clock > + - description: graphic frontend 1 async clock > + - description: video backend async clock > + - description: ethdr top clock > + > + clock-names: > + items: > + - const: mixer > + - const: vdo_fe0 > + - const: vdo_fe1 > + - const: gfx_fe0 > + - const: gfx_fe1 > + - const: vdo_be > + - const: adl_ds > + - const: vdo_fe0_async > + - const: vdo_fe1_async > + - const: gfx_fe0_async > + - const: gfx_fe1_async > + - const: vdo_be_async > + - const: ethdr_top > + > + power-domains: > + maxItems: 1 > + > + resets: > + items: > + - description: video frontend 0 async reset > + - description: video frontend 1 async reset > + - description: graphic frontend 0 async reset > + - description: graphic frontend 1 async reset > + - description: video backend async reset > + > + reset-names: > + items: > + - const: vdo_fe0_async > + - const: vdo_fe1_async > + - const: gfx_fe0_async > + - const: gfx_fe1_async > + - const: vdo_be_async > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: The register of display function block to be set by gce. > + There are 4 arguments in this property, gce node, subsys id, offset and > + register size. The subsys id is defined in the gce header of each chips > + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the register of > + display function block. > + items: > + items: > + - description: phandle of GCE > + - description: GCE subsys id > + - description: register offset > + - description: register size > + minItems: 7 > + maxItems: 7 > + > +required: > + - compatible > + - reg > + - clocks > + - clock-names > + - interrupts > + - power-domains > + - resets > + - 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/gce/mt8195-gce.h> > + #include <dt-bindings/memory/mt8195-memory-port.h> > + #include <dt-bindings/power/mt8195-power.h> > + #include <dt-bindings/reset/mt8195-resets.h> > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + disp_ethdr@1c114000 { No underscores in node name. Generic node names, so display-controller? Best regards, Krzysztof _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 7:35 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 7:35 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On 09/05/2022 06:43, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 ETHDR definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ > 1 file changed, 191 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > > diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > new file mode 100644 > index 000000000000..65f22fba9fed > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > @@ -0,0 +1,191 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek Ethdr Device Tree Bindings s/Device Tree Bindings// You need to add some description of a device. What is a Ethdr? > + > +maintainers: > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > + - Philipp Zabel <p.zabel@pengutronix.de> > + > +description: > + ETHDR is designed for HDR video and graphics conversion in the external display path. > + It handles multiple HDR input types and performs tone mapping, color space/color > + format conversion, and then combine different layers, output the required HDR or > + SDR signal to the subsequent display path. This engine is composed of two video > + frontends, two graphic frontends, one video backend and a mixer. ETHDR has two > + DMA function blocks, DS and ADL. These two function blocks read the pre-programmed > + registers from DRAM and set them to HW in the v-blanking period. Block does not look like wrapped at 80. > + > +properties: > + compatible: > + items: One item, so no items. > + - const: mediatek,mt8195-disp-ethdr > + > + reg: > + maxItems: 7 > + > + reg-names: > + items: > + - const: mixer > + - const: vdo_fe0 > + - const: vdo_fe1 > + - const: gfx_fe0 > + - const: gfx_fe1 > + - const: vdo_be > + - const: adl_ds > + > + interrupts: > + maxItems: 1 > + > + iommus: > + description: The compatible property is DMA function blocks. I don't understand this at all. > + Should point to the respective IOMMU block with master port as argument, > + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for > + details. Just skip the description, it's same everywhere. > + minItems: 1 > + maxItems: 2 > + > + clocks: > + items: > + - description: mixer clock > + - description: video frontend 0 clock > + - description: video frontend 1 clock > + - description: graphic frontend 0 clock > + - description: graphic frontend 1 clock > + - description: video backend clock > + - description: autodownload and menuload clock > + - description: video frontend 0 async clock > + - description: video frontend 1 async clock > + - description: graphic frontend 0 async clock > + - description: graphic frontend 1 async clock > + - description: video backend async clock > + - description: ethdr top clock > + > + clock-names: > + items: > + - const: mixer > + - const: vdo_fe0 > + - const: vdo_fe1 > + - const: gfx_fe0 > + - const: gfx_fe1 > + - const: vdo_be > + - const: adl_ds > + - const: vdo_fe0_async > + - const: vdo_fe1_async > + - const: gfx_fe0_async > + - const: gfx_fe1_async > + - const: vdo_be_async > + - const: ethdr_top > + > + power-domains: > + maxItems: 1 > + > + resets: > + items: > + - description: video frontend 0 async reset > + - description: video frontend 1 async reset > + - description: graphic frontend 0 async reset > + - description: graphic frontend 1 async reset > + - description: video backend async reset > + > + reset-names: > + items: > + - const: vdo_fe0_async > + - const: vdo_fe1_async > + - const: gfx_fe0_async > + - const: gfx_fe1_async > + - const: vdo_be_async > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: The register of display function block to be set by gce. > + There are 4 arguments in this property, gce node, subsys id, offset and > + register size. The subsys id is defined in the gce header of each chips > + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the register of > + display function block. > + items: > + items: > + - description: phandle of GCE > + - description: GCE subsys id > + - description: register offset > + - description: register size > + minItems: 7 > + maxItems: 7 > + > +required: > + - compatible > + - reg > + - clocks > + - clock-names > + - interrupts > + - power-domains > + - resets > + - 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/gce/mt8195-gce.h> > + #include <dt-bindings/memory/mt8195-memory-port.h> > + #include <dt-bindings/power/mt8195-power.h> > + #include <dt-bindings/reset/mt8195-resets.h> > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + disp_ethdr@1c114000 { No underscores in node name. Generic node names, so display-controller? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 7:35 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 7:35 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, jason-jh.lin, nancy.lin, devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On 09/05/2022 06:43, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 ETHDR definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ > 1 file changed, 191 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > > diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > new file mode 100644 > index 000000000000..65f22fba9fed > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > @@ -0,0 +1,191 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek Ethdr Device Tree Bindings s/Device Tree Bindings// You need to add some description of a device. What is a Ethdr? > + > +maintainers: > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > + - Philipp Zabel <p.zabel@pengutronix.de> > + > +description: > + ETHDR is designed for HDR video and graphics conversion in the external display path. > + It handles multiple HDR input types and performs tone mapping, color space/color > + format conversion, and then combine different layers, output the required HDR or > + SDR signal to the subsequent display path. This engine is composed of two video > + frontends, two graphic frontends, one video backend and a mixer. ETHDR has two > + DMA function blocks, DS and ADL. These two function blocks read the pre-programmed > + registers from DRAM and set them to HW in the v-blanking period. Block does not look like wrapped at 80. > + > +properties: > + compatible: > + items: One item, so no items. > + - const: mediatek,mt8195-disp-ethdr > + > + reg: > + maxItems: 7 > + > + reg-names: > + items: > + - const: mixer > + - const: vdo_fe0 > + - const: vdo_fe1 > + - const: gfx_fe0 > + - const: gfx_fe1 > + - const: vdo_be > + - const: adl_ds > + > + interrupts: > + maxItems: 1 > + > + iommus: > + description: The compatible property is DMA function blocks. I don't understand this at all. > + Should point to the respective IOMMU block with master port as argument, > + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for > + details. Just skip the description, it's same everywhere. > + minItems: 1 > + maxItems: 2 > + > + clocks: > + items: > + - description: mixer clock > + - description: video frontend 0 clock > + - description: video frontend 1 clock > + - description: graphic frontend 0 clock > + - description: graphic frontend 1 clock > + - description: video backend clock > + - description: autodownload and menuload clock > + - description: video frontend 0 async clock > + - description: video frontend 1 async clock > + - description: graphic frontend 0 async clock > + - description: graphic frontend 1 async clock > + - description: video backend async clock > + - description: ethdr top clock > + > + clock-names: > + items: > + - const: mixer > + - const: vdo_fe0 > + - const: vdo_fe1 > + - const: gfx_fe0 > + - const: gfx_fe1 > + - const: vdo_be > + - const: adl_ds > + - const: vdo_fe0_async > + - const: vdo_fe1_async > + - const: gfx_fe0_async > + - const: gfx_fe1_async > + - const: vdo_be_async > + - const: ethdr_top > + > + power-domains: > + maxItems: 1 > + > + resets: > + items: > + - description: video frontend 0 async reset > + - description: video frontend 1 async reset > + - description: graphic frontend 0 async reset > + - description: graphic frontend 1 async reset > + - description: video backend async reset > + > + reset-names: > + items: > + - const: vdo_fe0_async > + - const: vdo_fe1_async > + - const: gfx_fe0_async > + - const: gfx_fe1_async > + - const: vdo_be_async > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: The register of display function block to be set by gce. > + There are 4 arguments in this property, gce node, subsys id, offset and > + register size. The subsys id is defined in the gce header of each chips > + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the register of > + display function block. > + items: > + items: > + - description: phandle of GCE > + - description: GCE subsys id > + - description: register offset > + - description: register size > + minItems: 7 > + maxItems: 7 > + > +required: > + - compatible > + - reg > + - clocks > + - clock-names > + - interrupts > + - power-domains > + - resets > + - 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/gce/mt8195-gce.h> > + #include <dt-bindings/memory/mt8195-memory-port.h> > + #include <dt-bindings/power/mt8195-power.h> > + #include <dt-bindings/reset/mt8195-resets.h> > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + disp_ethdr@1c114000 { No underscores in node name. Generic node names, so display-controller? Best regards, Krzysztof _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 7:35 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 7:35 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, nancy.lin, linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno On 09/05/2022 06:43, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 ETHDR definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ > 1 file changed, 191 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > > diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > new file mode 100644 > index 000000000000..65f22fba9fed > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml > @@ -0,0 +1,191 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: MediaTek Ethdr Device Tree Bindings s/Device Tree Bindings// You need to add some description of a device. What is a Ethdr? > + > +maintainers: > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > + - Philipp Zabel <p.zabel@pengutronix.de> > + > +description: > + ETHDR is designed for HDR video and graphics conversion in the external display path. > + It handles multiple HDR input types and performs tone mapping, color space/color > + format conversion, and then combine different layers, output the required HDR or > + SDR signal to the subsequent display path. This engine is composed of two video > + frontends, two graphic frontends, one video backend and a mixer. ETHDR has two > + DMA function blocks, DS and ADL. These two function blocks read the pre-programmed > + registers from DRAM and set them to HW in the v-blanking period. Block does not look like wrapped at 80. > + > +properties: > + compatible: > + items: One item, so no items. > + - const: mediatek,mt8195-disp-ethdr > + > + reg: > + maxItems: 7 > + > + reg-names: > + items: > + - const: mixer > + - const: vdo_fe0 > + - const: vdo_fe1 > + - const: gfx_fe0 > + - const: gfx_fe1 > + - const: vdo_be > + - const: adl_ds > + > + interrupts: > + maxItems: 1 > + > + iommus: > + description: The compatible property is DMA function blocks. I don't understand this at all. > + Should point to the respective IOMMU block with master port as argument, > + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for > + details. Just skip the description, it's same everywhere. > + minItems: 1 > + maxItems: 2 > + > + clocks: > + items: > + - description: mixer clock > + - description: video frontend 0 clock > + - description: video frontend 1 clock > + - description: graphic frontend 0 clock > + - description: graphic frontend 1 clock > + - description: video backend clock > + - description: autodownload and menuload clock > + - description: video frontend 0 async clock > + - description: video frontend 1 async clock > + - description: graphic frontend 0 async clock > + - description: graphic frontend 1 async clock > + - description: video backend async clock > + - description: ethdr top clock > + > + clock-names: > + items: > + - const: mixer > + - const: vdo_fe0 > + - const: vdo_fe1 > + - const: gfx_fe0 > + - const: gfx_fe1 > + - const: vdo_be > + - const: adl_ds > + - const: vdo_fe0_async > + - const: vdo_fe1_async > + - const: gfx_fe0_async > + - const: gfx_fe1_async > + - const: vdo_be_async > + - const: ethdr_top > + > + power-domains: > + maxItems: 1 > + > + resets: > + items: > + - description: video frontend 0 async reset > + - description: video frontend 1 async reset > + - description: graphic frontend 0 async reset > + - description: graphic frontend 1 async reset > + - description: video backend async reset > + > + reset-names: > + items: > + - const: vdo_fe0_async > + - const: vdo_fe1_async > + - const: gfx_fe0_async > + - const: gfx_fe1_async > + - const: vdo_be_async > + > + mediatek,gce-client-reg: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: The register of display function block to be set by gce. > + There are 4 arguments in this property, gce node, subsys id, offset and > + register size. The subsys id is defined in the gce header of each chips > + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the register of > + display function block. > + items: > + items: > + - description: phandle of GCE > + - description: GCE subsys id > + - description: register offset > + - description: register size > + minItems: 7 > + maxItems: 7 > + > +required: > + - compatible > + - reg > + - clocks > + - clock-names > + - interrupts > + - power-domains > + - resets > + - 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/gce/mt8195-gce.h> > + #include <dt-bindings/memory/mt8195-memory-port.h> > + #include <dt-bindings/power/mt8195-power.h> > + #include <dt-bindings/reset/mt8195-resets.h> > + > + soc { > + #address-cells = <2>; > + #size-cells = <2>; > + > + disp_ethdr@1c114000 { No underscores in node name. Generic node names, so display-controller? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 2022-05-09 7:35 ` Krzysztof Kozlowski (?) (?) @ 2022-05-09 8:54 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 8:54 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno On Mon, 2022-05-09 at 15:35 +0800, Krzysztof Kozlowski wrote: > On 09/05/2022 06:43, Rex-BC Chen wrote: > > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > > > Add vdosys1 ETHDR definition. > > > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > > Reviewed-by: AngeloGioacchino Del Regno < > > angelogioacchino.delregno@collabora.com> > > --- > > .../display/mediatek/mediatek,ethdr.yaml | 191 > > ++++++++++++++++++ > > 1 file changed, 191 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.y > > aml > > > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > new file mode 100644 > > index 000000000000..65f22fba9fed > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > @@ -0,0 +1,191 @@ > > +# 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,ethdr.yaml*__;Iw!!CTRNKA9wMg0ARbw!0l-uil4PAknmCtuDbYhilIpDVA7jzpoeImD2nUauP75Bx1wg3O7BVgM4gJL1ckoqSq7r0276AvMSgzFjlPAag3Pv4Q$ > > > > +$schema: > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!0l-uil4PAknmCtuDbYhilIpDVA7jzpoeImD2nUauP75Bx1wg3O7BVgM4gJL1ckoqSq7r0276AvMSgzFjlPCRT1R8yg$ > > > > + > > +title: MediaTek Ethdr Device Tree Bindings > > s/Device Tree Bindings// Hello Krzysztof, Thanks for your review. We will remove "Device Tree Bindings" in next version. > > You need to add some description of a device. What is a Ethdr? > Ethdr device is described in the description section. Do I need to add anything else? > > + > > +maintainers: > > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > > + - Philipp Zabel <p.zabel@pengutronix.de> > > + > > +description: > > + ETHDR is designed for HDR video and graphics conversion in the > > external display path. > > + It handles multiple HDR input types and performs tone mapping, > > color space/color > > + format conversion, and then combine different layers, output the > > required HDR or > > + SDR signal to the subsequent display path. This engine is > > composed of two video > > + frontends, two graphic frontends, one video backend and a mixer. > > ETHDR has two > > + DMA function blocks, DS and ADL. These two function blocks read > > the pre-programmed > > + registers from DRAM and set them to HW in the v-blanking period. > > Block does not look like wrapped at 80. > ok, we will fix this in next version. > > + > > +properties: > > + compatible: > > + items: > > One item, so no items. ok, we will modofy like this: properties: compatible: - const: mediatek,mt8195-disp-ethdr > > > + - const: mediatek,mt8195-disp-ethdr > > + > > + reg: > > + maxItems: 7 > > + > > + reg-names: > > + items: > > + - const: mixer > > + - const: vdo_fe0 > > + - const: vdo_fe1 > > + - const: gfx_fe0 > > + - const: gfx_fe1 > > + - const: vdo_be > > + - const: adl_ds > > + > > + interrupts: > > + maxItems: 1 > > + > > + iommus: > > + description: The compatible property is DMA function blocks. > > I don't understand this at all. > > > + Should point to the respective IOMMU block with master port > > as argument, > > + see > > Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for > > + details. > > Just skip the description, it's same everywhere. OK, we will remove the whole description. > > > + minItems: 1 > > + maxItems: 2 > > + > > + clocks: > > + items: > > + - description: mixer clock > > + - description: video frontend 0 clock > > + - description: video frontend 1 clock > > + - description: graphic frontend 0 clock > > + - description: graphic frontend 1 clock > > + - description: video backend clock > > + - description: autodownload and menuload clock > > + - description: video frontend 0 async clock > > + - description: video frontend 1 async clock > > + - description: graphic frontend 0 async clock > > + - description: graphic frontend 1 async clock > > + - description: video backend async clock > > + - description: ethdr top clock > > + > > + clock-names: > > + items: > > + - const: mixer > > + - const: vdo_fe0 > > + - const: vdo_fe1 > > + - const: gfx_fe0 > > + - const: gfx_fe1 > > + - const: vdo_be > > + - const: adl_ds > > + - const: vdo_fe0_async > > + - const: vdo_fe1_async > > + - const: gfx_fe0_async > > + - const: gfx_fe1_async > > + - const: vdo_be_async > > + - const: ethdr_top > > + > > + power-domains: > > + maxItems: 1 > > + > > + resets: > > + items: > > + - description: video frontend 0 async reset > > + - description: video frontend 1 async reset > > + - description: graphic frontend 0 async reset > > + - description: graphic frontend 1 async reset > > + - description: video backend async reset > > + > > + reset-names: > > + items: > > + - const: vdo_fe0_async > > + - const: vdo_fe1_async > > + - const: gfx_fe0_async > > + - const: gfx_fe1_async > > + - const: vdo_be_async > > + > > + mediatek,gce-client-reg: > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > + description: The register of display function block to be set > > by gce. > > + There are 4 arguments in this property, gce node, subsys id, > > offset and > > + register size. The subsys id is defined in the gce header of > > each chips > > + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the > > register of > > + display function block. > > + items: > > + items: > > + - description: phandle of GCE > > + - description: GCE subsys id > > + - description: register offset > > + - description: register size > > + minItems: 7 > > + maxItems: 7 > > + > > +required: > > + - compatible > > + - reg > > + - clocks > > + - clock-names > > + - interrupts > > + - power-domains > > + - resets > > + - 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/gce/mt8195-gce.h> > > + #include <dt-bindings/memory/mt8195-memory-port.h> > > + #include <dt-bindings/power/mt8195-power.h> > > + #include <dt-bindings/reset/mt8195-resets.h> > > + > > + soc { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + disp_ethdr@1c114000 { > > No underscores in node name. Generic node names, so display- > controller? > OK, we will change the node name to ethdr like in dts like this: ethdr0: ethdr@1c114000 { ... } https://patchwork.kernel.org/project/linux-mediatek/patch/20220504091440.2052-26-nancy.lin@mediatek.com/ BRs, Rex > > Best regards, > Krzysztof ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 8:54 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 8:54 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On Mon, 2022-05-09 at 15:35 +0800, Krzysztof Kozlowski wrote: > On 09/05/2022 06:43, Rex-BC Chen wrote: > > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > > > Add vdosys1 ETHDR definition. > > > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > > Reviewed-by: AngeloGioacchino Del Regno < > > angelogioacchino.delregno@collabora.com> > > --- > > .../display/mediatek/mediatek,ethdr.yaml | 191 > > ++++++++++++++++++ > > 1 file changed, 191 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.y > > aml > > > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > new file mode 100644 > > index 000000000000..65f22fba9fed > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > @@ -0,0 +1,191 @@ > > +# 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,ethdr.yaml*__;Iw!!CTRNKA9wMg0ARbw!0l-uil4PAknmCtuDbYhilIpDVA7jzpoeImD2nUauP75Bx1wg3O7BVgM4gJL1ckoqSq7r0276AvMSgzFjlPAag3Pv4Q$ > > > > +$schema: > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!0l-uil4PAknmCtuDbYhilIpDVA7jzpoeImD2nUauP75Bx1wg3O7BVgM4gJL1ckoqSq7r0276AvMSgzFjlPCRT1R8yg$ > > > > + > > +title: MediaTek Ethdr Device Tree Bindings > > s/Device Tree Bindings// Hello Krzysztof, Thanks for your review. We will remove "Device Tree Bindings" in next version. > > You need to add some description of a device. What is a Ethdr? > Ethdr device is described in the description section. Do I need to add anything else? > > + > > +maintainers: > > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > > + - Philipp Zabel <p.zabel@pengutronix.de> > > + > > +description: > > + ETHDR is designed for HDR video and graphics conversion in the > > external display path. > > + It handles multiple HDR input types and performs tone mapping, > > color space/color > > + format conversion, and then combine different layers, output the > > required HDR or > > + SDR signal to the subsequent display path. This engine is > > composed of two video > > + frontends, two graphic frontends, one video backend and a mixer. > > ETHDR has two > > + DMA function blocks, DS and ADL. These two function blocks read > > the pre-programmed > > + registers from DRAM and set them to HW in the v-blanking period. > > Block does not look like wrapped at 80. > ok, we will fix this in next version. > > + > > +properties: > > + compatible: > > + items: > > One item, so no items. ok, we will modofy like this: properties: compatible: - const: mediatek,mt8195-disp-ethdr > > > + - const: mediatek,mt8195-disp-ethdr > > + > > + reg: > > + maxItems: 7 > > + > > + reg-names: > > + items: > > + - const: mixer > > + - const: vdo_fe0 > > + - const: vdo_fe1 > > + - const: gfx_fe0 > > + - const: gfx_fe1 > > + - const: vdo_be > > + - const: adl_ds > > + > > + interrupts: > > + maxItems: 1 > > + > > + iommus: > > + description: The compatible property is DMA function blocks. > > I don't understand this at all. > > > + Should point to the respective IOMMU block with master port > > as argument, > > + see > > Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for > > + details. > > Just skip the description, it's same everywhere. OK, we will remove the whole description. > > > + minItems: 1 > > + maxItems: 2 > > + > > + clocks: > > + items: > > + - description: mixer clock > > + - description: video frontend 0 clock > > + - description: video frontend 1 clock > > + - description: graphic frontend 0 clock > > + - description: graphic frontend 1 clock > > + - description: video backend clock > > + - description: autodownload and menuload clock > > + - description: video frontend 0 async clock > > + - description: video frontend 1 async clock > > + - description: graphic frontend 0 async clock > > + - description: graphic frontend 1 async clock > > + - description: video backend async clock > > + - description: ethdr top clock > > + > > + clock-names: > > + items: > > + - const: mixer > > + - const: vdo_fe0 > > + - const: vdo_fe1 > > + - const: gfx_fe0 > > + - const: gfx_fe1 > > + - const: vdo_be > > + - const: adl_ds > > + - const: vdo_fe0_async > > + - const: vdo_fe1_async > > + - const: gfx_fe0_async > > + - const: gfx_fe1_async > > + - const: vdo_be_async > > + - const: ethdr_top > > + > > + power-domains: > > + maxItems: 1 > > + > > + resets: > > + items: > > + - description: video frontend 0 async reset > > + - description: video frontend 1 async reset > > + - description: graphic frontend 0 async reset > > + - description: graphic frontend 1 async reset > > + - description: video backend async reset > > + > > + reset-names: > > + items: > > + - const: vdo_fe0_async > > + - const: vdo_fe1_async > > + - const: gfx_fe0_async > > + - const: gfx_fe1_async > > + - const: vdo_be_async > > + > > + mediatek,gce-client-reg: > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > + description: The register of display function block to be set > > by gce. > > + There are 4 arguments in this property, gce node, subsys id, > > offset and > > + register size. The subsys id is defined in the gce header of > > each chips > > + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the > > register of > > + display function block. > > + items: > > + items: > > + - description: phandle of GCE > > + - description: GCE subsys id > > + - description: register offset > > + - description: register size > > + minItems: 7 > > + maxItems: 7 > > + > > +required: > > + - compatible > > + - reg > > + - clocks > > + - clock-names > > + - interrupts > > + - power-domains > > + - resets > > + - 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/gce/mt8195-gce.h> > > + #include <dt-bindings/memory/mt8195-memory-port.h> > > + #include <dt-bindings/power/mt8195-power.h> > > + #include <dt-bindings/reset/mt8195-resets.h> > > + > > + soc { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + disp_ethdr@1c114000 { > > No underscores in node name. Generic node names, so display- > controller? > OK, we will change the node name to ethdr like in dts like this: ethdr0: ethdr@1c114000 { ... } https://patchwork.kernel.org/project/linux-mediatek/patch/20220504091440.2052-26-nancy.lin@mediatek.com/ BRs, Rex > > Best regards, > Krzysztof ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 8:54 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 8:54 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On Mon, 2022-05-09 at 15:35 +0800, Krzysztof Kozlowski wrote: > On 09/05/2022 06:43, Rex-BC Chen wrote: > > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > > > Add vdosys1 ETHDR definition. > > > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > > Reviewed-by: AngeloGioacchino Del Regno < > > angelogioacchino.delregno@collabora.com> > > --- > > .../display/mediatek/mediatek,ethdr.yaml | 191 > > ++++++++++++++++++ > > 1 file changed, 191 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.y > > aml > > > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > new file mode 100644 > > index 000000000000..65f22fba9fed > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > @@ -0,0 +1,191 @@ > > +# 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,ethdr.yaml*__;Iw!!CTRNKA9wMg0ARbw!0l-uil4PAknmCtuDbYhilIpDVA7jzpoeImD2nUauP75Bx1wg3O7BVgM4gJL1ckoqSq7r0276AvMSgzFjlPAag3Pv4Q$ > > > > +$schema: > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!0l-uil4PAknmCtuDbYhilIpDVA7jzpoeImD2nUauP75Bx1wg3O7BVgM4gJL1ckoqSq7r0276AvMSgzFjlPCRT1R8yg$ > > > > + > > +title: MediaTek Ethdr Device Tree Bindings > > s/Device Tree Bindings// Hello Krzysztof, Thanks for your review. We will remove "Device Tree Bindings" in next version. > > You need to add some description of a device. What is a Ethdr? > Ethdr device is described in the description section. Do I need to add anything else? > > + > > +maintainers: > > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > > + - Philipp Zabel <p.zabel@pengutronix.de> > > + > > +description: > > + ETHDR is designed for HDR video and graphics conversion in the > > external display path. > > + It handles multiple HDR input types and performs tone mapping, > > color space/color > > + format conversion, and then combine different layers, output the > > required HDR or > > + SDR signal to the subsequent display path. This engine is > > composed of two video > > + frontends, two graphic frontends, one video backend and a mixer. > > ETHDR has two > > + DMA function blocks, DS and ADL. These two function blocks read > > the pre-programmed > > + registers from DRAM and set them to HW in the v-blanking period. > > Block does not look like wrapped at 80. > ok, we will fix this in next version. > > + > > +properties: > > + compatible: > > + items: > > One item, so no items. ok, we will modofy like this: properties: compatible: - const: mediatek,mt8195-disp-ethdr > > > + - const: mediatek,mt8195-disp-ethdr > > + > > + reg: > > + maxItems: 7 > > + > > + reg-names: > > + items: > > + - const: mixer > > + - const: vdo_fe0 > > + - const: vdo_fe1 > > + - const: gfx_fe0 > > + - const: gfx_fe1 > > + - const: vdo_be > > + - const: adl_ds > > + > > + interrupts: > > + maxItems: 1 > > + > > + iommus: > > + description: The compatible property is DMA function blocks. > > I don't understand this at all. > > > + Should point to the respective IOMMU block with master port > > as argument, > > + see > > Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for > > + details. > > Just skip the description, it's same everywhere. OK, we will remove the whole description. > > > + minItems: 1 > > + maxItems: 2 > > + > > + clocks: > > + items: > > + - description: mixer clock > > + - description: video frontend 0 clock > > + - description: video frontend 1 clock > > + - description: graphic frontend 0 clock > > + - description: graphic frontend 1 clock > > + - description: video backend clock > > + - description: autodownload and menuload clock > > + - description: video frontend 0 async clock > > + - description: video frontend 1 async clock > > + - description: graphic frontend 0 async clock > > + - description: graphic frontend 1 async clock > > + - description: video backend async clock > > + - description: ethdr top clock > > + > > + clock-names: > > + items: > > + - const: mixer > > + - const: vdo_fe0 > > + - const: vdo_fe1 > > + - const: gfx_fe0 > > + - const: gfx_fe1 > > + - const: vdo_be > > + - const: adl_ds > > + - const: vdo_fe0_async > > + - const: vdo_fe1_async > > + - const: gfx_fe0_async > > + - const: gfx_fe1_async > > + - const: vdo_be_async > > + - const: ethdr_top > > + > > + power-domains: > > + maxItems: 1 > > + > > + resets: > > + items: > > + - description: video frontend 0 async reset > > + - description: video frontend 1 async reset > > + - description: graphic frontend 0 async reset > > + - description: graphic frontend 1 async reset > > + - description: video backend async reset > > + > > + reset-names: > > + items: > > + - const: vdo_fe0_async > > + - const: vdo_fe1_async > > + - const: gfx_fe0_async > > + - const: gfx_fe1_async > > + - const: vdo_be_async > > + > > + mediatek,gce-client-reg: > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > + description: The register of display function block to be set > > by gce. > > + There are 4 arguments in this property, gce node, subsys id, > > offset and > > + register size. The subsys id is defined in the gce header of > > each chips > > + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the > > register of > > + display function block. > > + items: > > + items: > > + - description: phandle of GCE > > + - description: GCE subsys id > > + - description: register offset > > + - description: register size > > + minItems: 7 > > + maxItems: 7 > > + > > +required: > > + - compatible > > + - reg > > + - clocks > > + - clock-names > > + - interrupts > > + - power-domains > > + - resets > > + - 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/gce/mt8195-gce.h> > > + #include <dt-bindings/memory/mt8195-memory-port.h> > > + #include <dt-bindings/power/mt8195-power.h> > > + #include <dt-bindings/reset/mt8195-resets.h> > > + > > + soc { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + disp_ethdr@1c114000 { > > No underscores in node name. Generic node names, so display- > controller? > OK, we will change the node name to ethdr like in dts like this: ethdr0: ethdr@1c114000 { ... } https://patchwork.kernel.org/project/linux-mediatek/patch/20220504091440.2052-26-nancy.lin@mediatek.com/ BRs, Rex > > Best regards, > Krzysztof _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 8:54 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-09 8:54 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On Mon, 2022-05-09 at 15:35 +0800, Krzysztof Kozlowski wrote: > On 09/05/2022 06:43, Rex-BC Chen wrote: > > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > > > Add vdosys1 ETHDR definition. > > > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > > Reviewed-by: AngeloGioacchino Del Regno < > > angelogioacchino.delregno@collabora.com> > > --- > > .../display/mediatek/mediatek,ethdr.yaml | 191 > > ++++++++++++++++++ > > 1 file changed, 191 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.y > > aml > > > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > new file mode 100644 > > index 000000000000..65f22fba9fed > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr > > .yaml > > @@ -0,0 +1,191 @@ > > +# 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,ethdr.yaml*__;Iw!!CTRNKA9wMg0ARbw!0l-uil4PAknmCtuDbYhilIpDVA7jzpoeImD2nUauP75Bx1wg3O7BVgM4gJL1ckoqSq7r0276AvMSgzFjlPAag3Pv4Q$ > > > > +$schema: > > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!0l-uil4PAknmCtuDbYhilIpDVA7jzpoeImD2nUauP75Bx1wg3O7BVgM4gJL1ckoqSq7r0276AvMSgzFjlPCRT1R8yg$ > > > > + > > +title: MediaTek Ethdr Device Tree Bindings > > s/Device Tree Bindings// Hello Krzysztof, Thanks for your review. We will remove "Device Tree Bindings" in next version. > > You need to add some description of a device. What is a Ethdr? > Ethdr device is described in the description section. Do I need to add anything else? > > + > > +maintainers: > > + - Chun-Kuang Hu <chunkuang.hu@kernel.org> > > + - Philipp Zabel <p.zabel@pengutronix.de> > > + > > +description: > > + ETHDR is designed for HDR video and graphics conversion in the > > external display path. > > + It handles multiple HDR input types and performs tone mapping, > > color space/color > > + format conversion, and then combine different layers, output the > > required HDR or > > + SDR signal to the subsequent display path. This engine is > > composed of two video > > + frontends, two graphic frontends, one video backend and a mixer. > > ETHDR has two > > + DMA function blocks, DS and ADL. These two function blocks read > > the pre-programmed > > + registers from DRAM and set them to HW in the v-blanking period. > > Block does not look like wrapped at 80. > ok, we will fix this in next version. > > + > > +properties: > > + compatible: > > + items: > > One item, so no items. ok, we will modofy like this: properties: compatible: - const: mediatek,mt8195-disp-ethdr > > > + - const: mediatek,mt8195-disp-ethdr > > + > > + reg: > > + maxItems: 7 > > + > > + reg-names: > > + items: > > + - const: mixer > > + - const: vdo_fe0 > > + - const: vdo_fe1 > > + - const: gfx_fe0 > > + - const: gfx_fe1 > > + - const: vdo_be > > + - const: adl_ds > > + > > + interrupts: > > + maxItems: 1 > > + > > + iommus: > > + description: The compatible property is DMA function blocks. > > I don't understand this at all. > > > + Should point to the respective IOMMU block with master port > > as argument, > > + see > > Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for > > + details. > > Just skip the description, it's same everywhere. OK, we will remove the whole description. > > > + minItems: 1 > > + maxItems: 2 > > + > > + clocks: > > + items: > > + - description: mixer clock > > + - description: video frontend 0 clock > > + - description: video frontend 1 clock > > + - description: graphic frontend 0 clock > > + - description: graphic frontend 1 clock > > + - description: video backend clock > > + - description: autodownload and menuload clock > > + - description: video frontend 0 async clock > > + - description: video frontend 1 async clock > > + - description: graphic frontend 0 async clock > > + - description: graphic frontend 1 async clock > > + - description: video backend async clock > > + - description: ethdr top clock > > + > > + clock-names: > > + items: > > + - const: mixer > > + - const: vdo_fe0 > > + - const: vdo_fe1 > > + - const: gfx_fe0 > > + - const: gfx_fe1 > > + - const: vdo_be > > + - const: adl_ds > > + - const: vdo_fe0_async > > + - const: vdo_fe1_async > > + - const: gfx_fe0_async > > + - const: gfx_fe1_async > > + - const: vdo_be_async > > + - const: ethdr_top > > + > > + power-domains: > > + maxItems: 1 > > + > > + resets: > > + items: > > + - description: video frontend 0 async reset > > + - description: video frontend 1 async reset > > + - description: graphic frontend 0 async reset > > + - description: graphic frontend 1 async reset > > + - description: video backend async reset > > + > > + reset-names: > > + items: > > + - const: vdo_fe0_async > > + - const: vdo_fe1_async > > + - const: gfx_fe0_async > > + - const: gfx_fe1_async > > + - const: vdo_be_async > > + > > + mediatek,gce-client-reg: > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > + description: The register of display function block to be set > > by gce. > > + There are 4 arguments in this property, gce node, subsys id, > > offset and > > + register size. The subsys id is defined in the gce header of > > each chips > > + include/include/dt-bindings/gce/<chip>-gce.h, mapping to the > > register of > > + display function block. > > + items: > > + items: > > + - description: phandle of GCE > > + - description: GCE subsys id > > + - description: register offset > > + - description: register size > > + minItems: 7 > > + maxItems: 7 > > + > > +required: > > + - compatible > > + - reg > > + - clocks > > + - clock-names > > + - interrupts > > + - power-domains > > + - resets > > + - 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/gce/mt8195-gce.h> > > + #include <dt-bindings/memory/mt8195-memory-port.h> > > + #include <dt-bindings/power/mt8195-power.h> > > + #include <dt-bindings/reset/mt8195-resets.h> > > + > > + soc { > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + disp_ethdr@1c114000 { > > No underscores in node name. Generic node names, so display- > controller? > OK, we will change the node name to ethdr like in dts like this: ethdr0: ethdr@1c114000 { ... } https://patchwork.kernel.org/project/linux-mediatek/patch/20220504091440.2052-26-nancy.lin@mediatek.com/ BRs, Rex > > Best regards, > Krzysztof _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 2022-05-09 8:54 ` Rex-BC Chen (?) (?) @ 2022-05-09 10:44 ` Krzysztof Kozlowski -1 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 10:44 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno On 09/05/2022 10:54, Rex-BC Chen wrote: >>> + soc { >>> + #address-cells = <2>; >>> + #size-cells = <2>; >>> + >>> + disp_ethdr@1c114000 { >> >> No underscores in node name. Generic node names, so display- >> controller? >> > > OK, we will change the node name to ethdr like in dts > like this: > ethdr0: ethdr@1c114000 { > ... > } Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ High Dynamic Range"? If yes, it also looks specific to Texas Instruments... Best regards, Krzysztof ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 10:44 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 10:44 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On 09/05/2022 10:54, Rex-BC Chen wrote: >>> + soc { >>> + #address-cells = <2>; >>> + #size-cells = <2>; >>> + >>> + disp_ethdr@1c114000 { >> >> No underscores in node name. Generic node names, so display- >> controller? >> > > OK, we will change the node name to ethdr like in dts > like this: > ethdr0: ethdr@1c114000 { > ... > } Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ High Dynamic Range"? If yes, it also looks specific to Texas Instruments... Best regards, Krzysztof ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 10:44 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 10:44 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On 09/05/2022 10:54, Rex-BC Chen wrote: >>> + soc { >>> + #address-cells = <2>; >>> + #size-cells = <2>; >>> + >>> + disp_ethdr@1c114000 { >> >> No underscores in node name. Generic node names, so display- >> controller? >> > > OK, we will change the node name to ethdr like in dts > like this: > ethdr0: ethdr@1c114000 { > ... > } Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ High Dynamic Range"? If yes, it also looks specific to Texas Instruments... Best regards, Krzysztof _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 10:44 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-09 10:44 UTC (permalink / raw) To: Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, angelogioacchino.delregno, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On 09/05/2022 10:54, Rex-BC Chen wrote: >>> + soc { >>> + #address-cells = <2>; >>> + #size-cells = <2>; >>> + >>> + disp_ethdr@1c114000 { >> >> No underscores in node name. Generic node names, so display- >> controller? >> > > OK, we will change the node name to ethdr like in dts > like this: > ethdr0: ethdr@1c114000 { > ... > } Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ High Dynamic Range"? If yes, it also looks specific to Texas Instruments... Best regards, Krzysztof _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 2022-05-09 10:44 ` Krzysztof Kozlowski (?) (?) @ 2022-05-09 10:50 ` AngeloGioacchino Del Regno -1 siblings, 0 replies; 90+ messages in thread From: AngeloGioacchino Del Regno @ 2022-05-09 10:50 UTC (permalink / raw) To: Krzysztof Kozlowski, Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group Il 09/05/22 12:44, Krzysztof Kozlowski ha scritto: > On 09/05/2022 10:54, Rex-BC Chen wrote: >>>> + soc { >>>> + #address-cells = <2>; >>>> + #size-cells = <2>; >>>> + >>>> + disp_ethdr@1c114000 { >>> >>> No underscores in node name. Generic node names, so display- >>> controller? >>> >> >> OK, we will change the node name to ethdr like in dts >> like this: >> ethdr0: ethdr@1c114000 { >> ... >> } > > Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ High > Dynamic Range"? If yes, it also looks specific to Texas Instruments... > > Best regards, > Krzysztof That's mediatek-drm, and this refers to the HDR block in the display IP... Though, I have no idea of what "ET" stands for in "ETHDR", so, it would be definitely nice if MediaTek can write the meaning in the description, like description: ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and ...blah Cheers, Angelo ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 10:50 ` AngeloGioacchino Del Regno 0 siblings, 0 replies; 90+ messages in thread From: AngeloGioacchino Del Regno @ 2022-05-09 10:50 UTC (permalink / raw) To: Krzysztof Kozlowski, Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group Il 09/05/22 12:44, Krzysztof Kozlowski ha scritto: > On 09/05/2022 10:54, Rex-BC Chen wrote: >>>> + soc { >>>> + #address-cells = <2>; >>>> + #size-cells = <2>; >>>> + >>>> + disp_ethdr@1c114000 { >>> >>> No underscores in node name. Generic node names, so display- >>> controller? >>> >> >> OK, we will change the node name to ethdr like in dts >> like this: >> ethdr0: ethdr@1c114000 { >> ... >> } > > Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ High > Dynamic Range"? If yes, it also looks specific to Texas Instruments... > > Best regards, > Krzysztof That's mediatek-drm, and this refers to the HDR block in the display IP... Though, I have no idea of what "ET" stands for in "ETHDR", so, it would be definitely nice if MediaTek can write the meaning in the description, like description: ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and ...blah Cheers, 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] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 10:50 ` AngeloGioacchino Del Regno 0 siblings, 0 replies; 90+ messages in thread From: AngeloGioacchino Del Regno @ 2022-05-09 10:50 UTC (permalink / raw) To: Krzysztof Kozlowski, Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel Il 09/05/22 12:44, Krzysztof Kozlowski ha scritto: > On 09/05/2022 10:54, Rex-BC Chen wrote: >>>> + soc { >>>> + #address-cells = <2>; >>>> + #size-cells = <2>; >>>> + >>>> + disp_ethdr@1c114000 { >>> >>> No underscores in node name. Generic node names, so display- >>> controller? >>> >> >> OK, we will change the node name to ethdr like in dts >> like this: >> ethdr0: ethdr@1c114000 { >> ... >> } > > Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ High > Dynamic Range"? If yes, it also looks specific to Texas Instruments... > > Best regards, > Krzysztof That's mediatek-drm, and this refers to the HDR block in the display IP... Though, I have no idea of what "ET" stands for in "ETHDR", so, it would be definitely nice if MediaTek can write the meaning in the description, like description: ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and ...blah Cheers, Angelo ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 10:50 ` AngeloGioacchino Del Regno 0 siblings, 0 replies; 90+ messages in thread From: AngeloGioacchino Del Regno @ 2022-05-09 10:50 UTC (permalink / raw) To: Krzysztof Kozlowski, Rex-BC Chen, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group Il 09/05/22 12:44, Krzysztof Kozlowski ha scritto: > On 09/05/2022 10:54, Rex-BC Chen wrote: >>>> + soc { >>>> + #address-cells = <2>; >>>> + #size-cells = <2>; >>>> + >>>> + disp_ethdr@1c114000 { >>> >>> No underscores in node name. Generic node names, so display- >>> controller? >>> >> >> OK, we will change the node name to ethdr like in dts >> like this: >> ethdr0: ethdr@1c114000 { >> ... >> } > > Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ High > Dynamic Range"? If yes, it also looks specific to Texas Instruments... > > Best regards, > Krzysztof That's mediatek-drm, and this refers to the HDR block in the display IP... Though, I have no idea of what "ET" stands for in "ETHDR", so, it would be definitely nice if MediaTek can write the meaning in the description, like description: ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and ...blah Cheers, Angelo _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 2022-05-09 10:50 ` AngeloGioacchino Del Regno (?) (?) @ 2022-05-10 1:46 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-10 1:46 UTC (permalink / raw) To: AngeloGioacchino Del Regno, Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On Mon, 2022-05-09 at 18:50 +0800, AngeloGioacchino Del Regno wrote: > Il 09/05/22 12:44, Krzysztof Kozlowski ha scritto: > > On 09/05/2022 10:54, Rex-BC Chen wrote: > > > > > + soc { > > > > > + #address-cells = <2>; > > > > > + #size-cells = <2>; > > > > > + > > > > > + disp_ethdr@1c114000 { > > > > > > > > No underscores in node name. Generic node names, so display- > > > > controller? > > > > > > > > > > OK, we will change the node name to ethdr like in dts > > > like this: > > > ethdr0: ethdr@1c114000 { > > > ... > > > } > > > > Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ > > High > > Dynamic Range"? If yes, it also looks specific to Texas > > Instruments... > > > > Best regards, > > Krzysztof > > > That's mediatek-drm, and this refers to the HDR block in the display > IP... > > Though, I have no idea of what "ET" stands for in "ETHDR", so, it > would be > definitely nice if MediaTek can write the meaning in the description, > like > > description: > ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and > ...blah > > Cheers, > Angelo Hello Krzysztof and Angelo, "ET" is actually meaningless. ET is one of mediatek departments and it's where the engine from. Therefore, I think we will add description like this: > ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and > designed for HDR video... BRs, Rex ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-10 1:46 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-10 1:46 UTC (permalink / raw) To: AngeloGioacchino Del Regno, Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On Mon, 2022-05-09 at 18:50 +0800, AngeloGioacchino Del Regno wrote: > Il 09/05/22 12:44, Krzysztof Kozlowski ha scritto: > > On 09/05/2022 10:54, Rex-BC Chen wrote: > > > > > + soc { > > > > > + #address-cells = <2>; > > > > > + #size-cells = <2>; > > > > > + > > > > > + disp_ethdr@1c114000 { > > > > > > > > No underscores in node name. Generic node names, so display- > > > > controller? > > > > > > > > > > OK, we will change the node name to ethdr like in dts > > > like this: > > > ethdr0: ethdr@1c114000 { > > > ... > > > } > > > > Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ > > High > > Dynamic Range"? If yes, it also looks specific to Texas > > Instruments... > > > > Best regards, > > Krzysztof > > > That's mediatek-drm, and this refers to the HDR block in the display > IP... > > Though, I have no idea of what "ET" stands for in "ETHDR", so, it > would be > definitely nice if MediaTek can write the meaning in the description, > like > > description: > ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and > ...blah > > Cheers, > Angelo Hello Krzysztof and Angelo, "ET" is actually meaningless. ET is one of mediatek departments and it's where the engine from. Therefore, I think we will add description like this: > ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and > designed for HDR video... BRs, Rex _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-10 1:46 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-10 1:46 UTC (permalink / raw) To: AngeloGioacchino Del Regno, Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel On Mon, 2022-05-09 at 18:50 +0800, AngeloGioacchino Del Regno wrote: > Il 09/05/22 12:44, Krzysztof Kozlowski ha scritto: > > On 09/05/2022 10:54, Rex-BC Chen wrote: > > > > > + soc { > > > > > + #address-cells = <2>; > > > > > + #size-cells = <2>; > > > > > + > > > > > + disp_ethdr@1c114000 { > > > > > > > > No underscores in node name. Generic node names, so display- > > > > controller? > > > > > > > > > > OK, we will change the node name to ethdr like in dts > > > like this: > > > ethdr0: ethdr@1c114000 { > > > ... > > > } > > > > Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ > > High > > Dynamic Range"? If yes, it also looks specific to Texas > > Instruments... > > > > Best regards, > > Krzysztof > > > That's mediatek-drm, and this refers to the HDR block in the display > IP... > > Though, I have no idea of what "ET" stands for in "ETHDR", so, it > would be > definitely nice if MediaTek can write the meaning in the description, > like > > description: > ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and > ...blah > > Cheers, > Angelo Hello Krzysztof and Angelo, "ET" is actually meaningless. ET is one of mediatek departments and it's where the engine from. Therefore, I think we will add description like this: > ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and > designed for HDR video... BRs, Rex ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-10 1:46 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-10 1:46 UTC (permalink / raw) To: AngeloGioacchino Del Regno, Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On Mon, 2022-05-09 at 18:50 +0800, AngeloGioacchino Del Regno wrote: > Il 09/05/22 12:44, Krzysztof Kozlowski ha scritto: > > On 09/05/2022 10:54, Rex-BC Chen wrote: > > > > > + soc { > > > > > + #address-cells = <2>; > > > > > + #size-cells = <2>; > > > > > + > > > > > + disp_ethdr@1c114000 { > > > > > > > > No underscores in node name. Generic node names, so display- > > > > controller? > > > > > > > > > > OK, we will change the node name to ethdr like in dts > > > like this: > > > ethdr0: ethdr@1c114000 { > > > ... > > > } > > > > Is "ethdr" a generic name? Is it an abbreviation of "EnergyTrace™ > > High > > Dynamic Range"? If yes, it also looks specific to Texas > > Instruments... > > > > Best regards, > > Krzysztof > > > That's mediatek-drm, and this refers to the HDR block in the display > IP... > > Though, I have no idea of what "ET" stands for in "ETHDR", so, it > would be > definitely nice if MediaTek can write the meaning in the description, > like > > description: > ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and > ...blah > > Cheers, > Angelo Hello Krzysztof and Angelo, "ET" is actually meaningless. ET is one of mediatek departments and it's where the engine from. Therefore, I think we will add description like this: > ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and > designed for HDR video... BRs, Rex _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 2022-05-10 1:46 ` Rex-BC Chen (?) (?) @ 2022-05-10 11:19 ` Krzysztof Kozlowski -1 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 11:19 UTC (permalink / raw) To: Rex-BC Chen, AngeloGioacchino Del Regno, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel On 10/05/2022 03:46, Rex-BC Chen wrote: >> >> >> That's mediatek-drm, and this refers to the HDR block in the display >> IP... >> >> Though, I have no idea of what "ET" stands for in "ETHDR", so, it >> would be >> definitely nice if MediaTek can write the meaning in the description, >> like >> >> description: >> ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and >> ...blah >> >> Cheers, >> Angelo > > Hello Krzysztof and Angelo, > > "ET" is actually meaningless. > ET is one of mediatek departments and it's where the engine from. > Therefore, I think we will add description like this: >> ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and >> designed for HDR video... Sure, sounds good, but then the node name should not have it. Please try to find some more generic name (DT spec gives examples). Could be display-controller, "hdr-engine", "isp". Best regards, Krzysztof ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-10 11:19 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 11:19 UTC (permalink / raw) To: Rex-BC Chen, AngeloGioacchino Del Regno, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On 10/05/2022 03:46, Rex-BC Chen wrote: >> >> >> That's mediatek-drm, and this refers to the HDR block in the display >> IP... >> >> Though, I have no idea of what "ET" stands for in "ETHDR", so, it >> would be >> definitely nice if MediaTek can write the meaning in the description, >> like >> >> description: >> ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and >> ...blah >> >> Cheers, >> Angelo > > Hello Krzysztof and Angelo, > > "ET" is actually meaningless. > ET is one of mediatek departments and it's where the engine from. > Therefore, I think we will add description like this: >> ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and >> designed for HDR video... Sure, sounds good, but then the node name should not have it. Please try to find some more generic name (DT spec gives examples). Could be display-controller, "hdr-engine", "isp". Best regards, Krzysztof _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-10 11:19 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 11:19 UTC (permalink / raw) To: Rex-BC Chen, AngeloGioacchino Del Regno, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On 10/05/2022 03:46, Rex-BC Chen wrote: >> >> >> That's mediatek-drm, and this refers to the HDR block in the display >> IP... >> >> Though, I have no idea of what "ET" stands for in "ETHDR", so, it >> would be >> definitely nice if MediaTek can write the meaning in the description, >> like >> >> description: >> ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and >> ...blah >> >> Cheers, >> Angelo > > Hello Krzysztof and Angelo, > > "ET" is actually meaningless. > ET is one of mediatek departments and it's where the engine from. > Therefore, I think we will add description like this: >> ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and >> designed for HDR video... Sure, sounds good, but then the node name should not have it. Please try to find some more generic name (DT spec gives examples). Could be display-controller, "hdr-engine", "isp". Best regards, Krzysztof _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-10 11:19 ` Krzysztof Kozlowski 0 siblings, 0 replies; 90+ messages in thread From: Krzysztof Kozlowski @ 2022-05-10 11:19 UTC (permalink / raw) To: Rex-BC Chen, AngeloGioacchino Del Regno, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On 10/05/2022 03:46, Rex-BC Chen wrote: >> >> >> That's mediatek-drm, and this refers to the HDR block in the display >> IP... >> >> Though, I have no idea of what "ET" stands for in "ETHDR", so, it >> would be >> definitely nice if MediaTek can write the meaning in the description, >> like >> >> description: >> ETHDR (E??? T??? High Dynamic Range) is designed for HDR video and >> ...blah >> >> Cheers, >> Angelo > > Hello Krzysztof and Angelo, > > "ET" is actually meaningless. > ET is one of mediatek departments and it's where the engine from. > Therefore, I think we will add description like this: >> ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and >> designed for HDR video... Sure, sounds good, but then the node name should not have it. Please try to find some more generic name (DT spec gives examples). Could be display-controller, "hdr-engine", "isp". Best regards, Krzysztof ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 2022-05-10 11:19 ` Krzysztof Kozlowski (?) (?) @ 2022-05-11 2:29 ` Rex-BC Chen -1 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-11 2:29 UTC (permalink / raw) To: Krzysztof Kozlowski, AngeloGioacchino Del Regno, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On Tue, 2022-05-10 at 19:19 +0800, Krzysztof Kozlowski wrote: > On 10/05/2022 03:46, Rex-BC Chen wrote: > > > > > > > > > That's mediatek-drm, and this refers to the HDR block in the > > > display > > > IP... > > > > > > Though, I have no idea of what "ET" stands for in "ETHDR", so, it > > > would be > > > definitely nice if MediaTek can write the meaning in the > > > description, > > > like > > > > > > description: > > > ETHDR (E??? T??? High Dynamic Range) is designed for HDR video > > > and > > > ...blah > > > > > > Cheers, > > > Angelo > > > > Hello Krzysztof and Angelo, > > > > "ET" is actually meaningless. > > ET is one of mediatek departments and it's where the engine from. > > Therefore, I think we will add description like this: > > > ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine > > > and > > > designed for HDR video... > > Sure, sounds good, but then the node name should not have it. Please > try > to find some more generic name (DT spec gives examples). Could be > display-controller, "hdr-engine", "isp". > > > Best regards, > Krzysztof Hello Krzysztof, Thanks for your suggestion. We will use hdr-engine to name this node. Thanks! BRs, Rex ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-11 2:29 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-11 2:29 UTC (permalink / raw) To: Krzysztof Kozlowski, AngeloGioacchino Del Regno, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On Tue, 2022-05-10 at 19:19 +0800, Krzysztof Kozlowski wrote: > On 10/05/2022 03:46, Rex-BC Chen wrote: > > > > > > > > > That's mediatek-drm, and this refers to the HDR block in the > > > display > > > IP... > > > > > > Though, I have no idea of what "ET" stands for in "ETHDR", so, it > > > would be > > > definitely nice if MediaTek can write the meaning in the > > > description, > > > like > > > > > > description: > > > ETHDR (E??? T??? High Dynamic Range) is designed for HDR video > > > and > > > ...blah > > > > > > Cheers, > > > Angelo > > > > Hello Krzysztof and Angelo, > > > > "ET" is actually meaningless. > > ET is one of mediatek departments and it's where the engine from. > > Therefore, I think we will add description like this: > > > ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine > > > and > > > designed for HDR video... > > Sure, sounds good, but then the node name should not have it. Please > try > to find some more generic name (DT spec gives examples). Could be > display-controller, "hdr-engine", "isp". > > > Best regards, > Krzysztof Hello Krzysztof, Thanks for your suggestion. We will use hdr-engine to name this node. Thanks! BRs, Rex _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-11 2:29 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-11 2:29 UTC (permalink / raw) To: Krzysztof Kozlowski, AngeloGioacchino Del Regno, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: devicetree, airlied, Jason-JH Lin (林睿祥), linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, Nancy Lin (林欣螢), linux-mediatek, matthias.bgg, linux-arm-kernel On Tue, 2022-05-10 at 19:19 +0800, Krzysztof Kozlowski wrote: > On 10/05/2022 03:46, Rex-BC Chen wrote: > > > > > > > > > That's mediatek-drm, and this refers to the HDR block in the > > > display > > > IP... > > > > > > Though, I have no idea of what "ET" stands for in "ETHDR", so, it > > > would be > > > definitely nice if MediaTek can write the meaning in the > > > description, > > > like > > > > > > description: > > > ETHDR (E??? T??? High Dynamic Range) is designed for HDR video > > > and > > > ...blah > > > > > > Cheers, > > > Angelo > > > > Hello Krzysztof and Angelo, > > > > "ET" is actually meaningless. > > ET is one of mediatek departments and it's where the engine from. > > Therefore, I think we will add description like this: > > > ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine > > > and > > > designed for HDR video... > > Sure, sounds good, but then the node name should not have it. Please > try > to find some more generic name (DT spec gives examples). Could be > display-controller, "hdr-engine", "isp". > > > Best regards, > Krzysztof Hello Krzysztof, Thanks for your suggestion. We will use hdr-engine to name this node. Thanks! BRs, Rex ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-11 2:29 ` Rex-BC Chen 0 siblings, 0 replies; 90+ messages in thread From: Rex-BC Chen @ 2022-05-11 2:29 UTC (permalink / raw) To: Krzysztof Kozlowski, AngeloGioacchino Del Regno, robh+dt, krzysztof.kozlowski+dt, chunkuang.hu, p.zabel Cc: airlied, matthias.bgg, Jason-JH Lin (林睿祥), Nancy Lin (林欣螢), devicetree, linux-kernel, dri-devel, linux-mediatek, linux-arm-kernel, Project_Global_Chrome_Upstream_Group On Tue, 2022-05-10 at 19:19 +0800, Krzysztof Kozlowski wrote: > On 10/05/2022 03:46, Rex-BC Chen wrote: > > > > > > > > > That's mediatek-drm, and this refers to the HDR block in the > > > display > > > IP... > > > > > > Though, I have no idea of what "ET" stands for in "ETHDR", so, it > > > would be > > > definitely nice if MediaTek can write the meaning in the > > > description, > > > like > > > > > > description: > > > ETHDR (E??? T??? High Dynamic Range) is designed for HDR video > > > and > > > ...blah > > > > > > Cheers, > > > Angelo > > > > Hello Krzysztof and Angelo, > > > > "ET" is actually meaningless. > > ET is one of mediatek departments and it's where the engine from. > > Therefore, I think we will add description like this: > > > ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine > > > and > > > designed for HDR video... > > Sure, sounds good, but then the node name should not have it. Please > try > to find some more generic name (DT spec gives examples). Could be > display-controller, "hdr-engine", "isp". > > > Best regards, > Krzysztof Hello Krzysztof, Thanks for your suggestion. We will use hdr-engine to name this node. Thanks! BRs, Rex _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 2022-05-09 4:43 ` Rex-BC Chen (?) (?) @ 2022-05-09 12:20 ` Rob Herring -1 siblings, 0 replies; 90+ messages in thread From: Rob Herring @ 2022-05-09 12:20 UTC (permalink / raw) To: Rex-BC Chen Cc: airlied, chunkuang.hu, nancy.lin, krzysztof.kozlowski+dt, linux-arm-kernel, robh+dt, p.zabel, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, angelogioacchino.delregno, linux-mediatek, matthias.bgg, devicetree On Mon, 09 May 2022 12:43:02 +0800, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 ETHDR definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ > 1 file changed, 191 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.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,ethdr.example.dts:26:18: fatal error: dt-bindings/memory/mt8195-memory-port.h: No such file or directory 26 | #include <dt-bindings/memory/mt8195-memory-port.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.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. ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 12:20 ` Rob Herring 0 siblings, 0 replies; 90+ messages in thread From: Rob Herring @ 2022-05-09 12:20 UTC (permalink / raw) To: Rex-BC Chen Cc: airlied, chunkuang.hu, nancy.lin, krzysztof.kozlowski+dt, linux-arm-kernel, robh+dt, p.zabel, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, angelogioacchino.delregno, linux-mediatek, matthias.bgg, devicetree On Mon, 09 May 2022 12:43:02 +0800, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 ETHDR definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ > 1 file changed, 191 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.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,ethdr.example.dts:26:18: fatal error: dt-bindings/memory/mt8195-memory-port.h: No such file or directory 26 | #include <dt-bindings/memory/mt8195-memory-port.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.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. _______________________________________________ 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] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 12:20 ` Rob Herring 0 siblings, 0 replies; 90+ messages in thread From: Rob Herring @ 2022-05-09 12:20 UTC (permalink / raw) To: Rex-BC Chen Cc: airlied, chunkuang.hu, nancy.lin, krzysztof.kozlowski+dt, linux-arm-kernel, robh+dt, p.zabel, jason-jh.lin, linux-kernel, dri-devel, Project_Global_Chrome_Upstream_Group, angelogioacchino.delregno, linux-mediatek, matthias.bgg, devicetree On Mon, 09 May 2022 12:43:02 +0800, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 ETHDR definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ > 1 file changed, 191 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.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,ethdr.example.dts:26:18: fatal error: dt-bindings/memory/mt8195-memory-port.h: No such file or directory 26 | #include <dt-bindings/memory/mt8195-memory-port.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.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. _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 @ 2022-05-09 12:20 ` Rob Herring 0 siblings, 0 replies; 90+ messages in thread From: Rob Herring @ 2022-05-09 12:20 UTC (permalink / raw) To: Rex-BC Chen Cc: chunkuang.hu, devicetree, airlied, jason-jh.lin, linux-kernel, robh+dt, Project_Global_Chrome_Upstream_Group, nancy.lin, linux-mediatek, dri-devel, krzysztof.kozlowski+dt, matthias.bgg, linux-arm-kernel, angelogioacchino.delregno On Mon, 09 May 2022 12:43:02 +0800, Rex-BC Chen wrote: > From: "Nancy.Lin" <nancy.lin@mediatek.com> > > Add vdosys1 ETHDR definition. > > Signed-off-by: Nancy.Lin <nancy.lin@mediatek.com> > Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../display/mediatek/mediatek,ethdr.yaml | 191 ++++++++++++++++++ > 1 file changed, 191 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.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,ethdr.example.dts:26:18: fatal error: dt-bindings/memory/mt8195-memory-port.h: No such file or directory 26 | #include <dt-bindings/memory/mt8195-memory-port.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[1]: *** [scripts/Makefile.lib:364: Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.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. ^ permalink raw reply [flat|nested] 90+ messages in thread
end of thread, other threads:[~2022-06-02 4:02 UTC | newest] Thread overview: 90+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-09 4:42 [PATCH v2 0/3] MediaTek MT8195 display binding Rex-BC Chen 2022-05-09 4:42 ` Rex-BC Chen 2022-05-09 4:42 ` Rex-BC Chen 2022-05-09 4:42 ` Rex-BC Chen 2022-05-09 4:43 ` [PATCH v2 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 Rex-BC Chen 2022-05-09 4:43 ` Rex-BC Chen 2022-05-09 4:43 ` Rex-BC Chen 2022-05-09 4:43 ` Rex-BC Chen 2022-05-09 7:31 ` Krzysztof Kozlowski 2022-05-09 7:31 ` Krzysztof Kozlowski 2022-05-09 7:31 ` Krzysztof Kozlowski 2022-05-09 7:31 ` Krzysztof Kozlowski 2022-05-09 8:45 ` Rex-BC Chen 2022-05-09 8:45 ` Rex-BC Chen 2022-05-09 8:45 ` Rex-BC Chen 2022-05-09 8:45 ` Rex-BC Chen 2022-05-10 2:23 ` Rex-BC Chen 2022-05-10 2:23 ` Rex-BC Chen 2022-05-10 10:28 ` Krzysztof Kozlowski 2022-05-10 10:28 ` Krzysztof Kozlowski 2022-05-10 10:28 ` Krzysztof Kozlowski 2022-05-10 10:28 ` Krzysztof Kozlowski 2022-05-10 10:37 ` Chen-Yu Tsai 2022-05-10 10:37 ` Chen-Yu Tsai 2022-05-10 10:37 ` Chen-Yu Tsai 2022-05-10 10:37 ` Chen-Yu Tsai 2022-05-10 10:57 ` Krzysztof Kozlowski 2022-05-10 10:57 ` Krzysztof Kozlowski 2022-05-10 10:57 ` Krzysztof Kozlowski 2022-05-10 10:57 ` Krzysztof Kozlowski 2022-05-11 2:26 ` Rex-BC Chen 2022-05-11 2:26 ` Rex-BC Chen 2022-05-11 2:26 ` Rex-BC Chen 2022-05-11 2:26 ` Rex-BC Chen 2022-05-11 7:21 ` Krzysztof Kozlowski 2022-05-11 7:21 ` Krzysztof Kozlowski 2022-05-11 7:21 ` Krzysztof Kozlowski 2022-05-11 7:21 ` Krzysztof Kozlowski 2022-05-09 12:20 ` Rob Herring 2022-05-09 12:20 ` Rob Herring 2022-05-09 12:20 ` Rob Herring 2022-05-09 12:20 ` Rob Herring 2022-05-30 7:06 ` Pavel Machek 2022-05-30 7:06 ` Pavel Machek 2022-05-30 7:06 ` Pavel Machek 2022-05-30 7:06 ` Pavel Machek 2022-06-02 3:53 ` Rex-BC Chen 2022-06-02 3:53 ` Rex-BC Chen 2022-06-02 3:53 ` Rex-BC Chen 2022-06-02 3:53 ` Rex-BC Chen 2022-05-09 4:43 ` [PATCH v2 2/3] dt-bindings: reset: mt8195: add vdosys1 reset control bit Rex-BC Chen 2022-05-09 4:43 ` Rex-BC Chen 2022-05-09 4:43 ` Rex-BC Chen 2022-05-09 4:43 ` Rex-BC Chen 2022-05-09 4:43 ` [PATCH v2 3/3] dt-bindings: mediatek: add ethdr definition for mt8195 Rex-BC Chen 2022-05-09 4:43 ` Rex-BC Chen 2022-05-09 4:43 ` Rex-BC Chen 2022-05-09 4:43 ` Rex-BC Chen 2022-05-09 7:35 ` Krzysztof Kozlowski 2022-05-09 7:35 ` Krzysztof Kozlowski 2022-05-09 7:35 ` Krzysztof Kozlowski 2022-05-09 7:35 ` Krzysztof Kozlowski 2022-05-09 8:54 ` Rex-BC Chen 2022-05-09 8:54 ` Rex-BC Chen 2022-05-09 8:54 ` Rex-BC Chen 2022-05-09 8:54 ` Rex-BC Chen 2022-05-09 10:44 ` Krzysztof Kozlowski 2022-05-09 10:44 ` Krzysztof Kozlowski 2022-05-09 10:44 ` Krzysztof Kozlowski 2022-05-09 10:44 ` Krzysztof Kozlowski 2022-05-09 10:50 ` AngeloGioacchino Del Regno 2022-05-09 10:50 ` AngeloGioacchino Del Regno 2022-05-09 10:50 ` AngeloGioacchino Del Regno 2022-05-09 10:50 ` AngeloGioacchino Del Regno 2022-05-10 1:46 ` Rex-BC Chen 2022-05-10 1:46 ` Rex-BC Chen 2022-05-10 1:46 ` Rex-BC Chen 2022-05-10 1:46 ` Rex-BC Chen 2022-05-10 11:19 ` Krzysztof Kozlowski 2022-05-10 11:19 ` Krzysztof Kozlowski 2022-05-10 11:19 ` Krzysztof Kozlowski 2022-05-10 11:19 ` Krzysztof Kozlowski 2022-05-11 2:29 ` Rex-BC Chen 2022-05-11 2:29 ` Rex-BC Chen 2022-05-11 2:29 ` Rex-BC Chen 2022-05-11 2:29 ` Rex-BC Chen 2022-05-09 12:20 ` Rob Herring 2022-05-09 12:20 ` Rob Herring 2022-05-09 12:20 ` Rob Herring 2022-05-09 12:20 ` Rob Herring
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.