[PATCH v1 0/5] add mt8195 SoC DRM binding

List overview All Threads
Download

newer

older

[PATCH v2] drm/i915/selftests:...

[PATCH] drm/msm/dsi: Fix DSI and...

jason-jh.lin

22 Jul 2021 22 Jul '21

9:26 a.m.

Add mt8195 SoC DRM binding 1. Due to the 2 display hardware path in mt8195 SoC, we need to add vdosys0 and vdosys1 into mmsys binding document. 2. DSC and MERGE is used in vdosys0, so we need to add DSC binding file and additional MERGE description into original disp binding document.

jason-jh.lin (5): dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding dt-bindings: mediatek: display: Change format to yaml dt-bindings: mediatek: display: add MERGE additional description dt-bindings: mediatek: add mediatek,dsc.yaml for mt8195 SoC binding dt-bindings: mediatek: display: add mt8195 SoC binding

.../bindings/arm/mediatek/mediatek,mmsys.yaml | 2 + .../display/mediatek/mediatek,disp.txt | 219 --------- .../display/mediatek/mediatek,disp.yaml | 464 ++++++++++++++++++ .../display/mediatek/mediatek,dsc.yaml | 73 +++ 4 files changed, 539 insertions(+), 219 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml

-- 2.18.0

Show replies by date

jason-jh.lin

22 Jul 22 Jul

9:26 a.m.

New subject: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

There are 2 display hardware path in mt8195, namely vdosys0 and vdosys1, so add their definition in mtk-mmsys documentation.

Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com --- this patch is base on [1][2]

[1] dt-bindings: arm: mediatek: mmsys: convert to YAML format - https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.374... [2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding - https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.374... --- .../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index 2d4ff0ce387b..0789a9614f12 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -30,6 +30,8 @@ properties: - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys - mediatek,mt8365-mmsys + - mediatek,mt8195-vdosys0 + - mediatek,mt8195-vdosys1 - const: syscon - items: - const: mediatek,mt7623-mmsys

-- 2.18.0

Enric Balletbo Serra

23 Jul 23 Jul

11:13 a.m.

New subject: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

Hi Jason,

Thank you for your patch.

Missatge de jason-jh.lin jason-jh.lin@mediatek.com del dia dj., 22 de jul. 2021 a les 11:26:

...

There are 2 display hardware path in mt8195, namely vdosys0 and vdosys1, so add their definition in mtk-mmsys documentation.

Just having 2 display hardware paths is not a reason to have two compatibles, isn't the IP block the same? Why do you need to introduce the two compatibles?

Thanks, Enric

...

Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com

this patch is base on [1][2]

[1] dt-bindings: arm: mediatek: mmsys: convert to YAML format

https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.374...

[2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding

https://patchwork.kernel.org/project/linux-mediatek/patch/20210519161847.374...

.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index 2d4ff0ce387b..0789a9614f12 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -30,6 +30,8 @@ properties: - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys - mediatek,mt8365-mmsys
         - mediatek,mt8195-vdosys0
         - mediatek,mt8195-vdosys1
     - const: syscon
 - items:
     - const: mediatek,mt7623-mmsys
-- 2.18.0

Jason-JH Lin

26 Jul 26 Jul

7:02 a.m.

New subject: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:

...

Hi Jason,

Thank you for your patch.

Missatge de jason-jh.lin jason-jh.lin@mediatek.com del dia dj., 22 de jul. 2021 a les 11:26:

...
There are 2 display hardware path in mt8195, namely vdosys0 and vdosys1, so add their definition in mtk-mmsys documentation.

Just having 2 display hardware paths is not a reason to have two compatibles, isn't the IP block the same? Why do you need to introduce the two compatibles?

Thanks, Enric

Hi Enric,

Thanks for reviewing my patch.

The reason for using two compatibles is that vdosys0 and vdosys1 are different IP blocks.

Because mmsys provides clock control, other display function blocks may use them as clock provider.

E.g. 1. mmsys with compatible="mediatek,mt8195-vdosys0" [v4,1/6] arm64: dts: mt8195: add display node for vdosys0

https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.240...

ovl0: disp_ovl@1c000000 { ... clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; ... };

2. mmsys with compatible="mediatek,mt8195-vdosys1" [v2,06/14] arm64: dts: mt8195: add display node for vdosys1

https://patchwork.kernel.org/project/linux-mediatek/patch/20210722094551.152...

vdo1_rdma0: vdo1_rdma@1c104000 { ... clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; ... };

Regards, Jason-JH.Lin

...

...
Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com

this patch is base on [1][2]

[1] dt-bindings: arm: mediatek: mmsys: convert to YAML format

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

[2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam l b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam l index 2d4ff0ce387b..0789a9614f12 100644

a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam l +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam l @@ -30,6 +30,8 @@ properties: - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys - mediatek,mt8365-mmsys
         - mediatek,mt8195-vdosys0
         - mediatek,mt8195-vdosys1
     - const: syscon
 - items:
     - const: mediatek,mt7623-mmsys
-- 2.18.0

Enric Balletbo Serra

10:08 a.m.

New subject: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

Hi Jason,

Missatge de Jason-JH Lin jason-jh.lin@mediatek.com del dia dl., 26 de jul. 2021 a les 9:02:

...

On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:

...
Hi Jason,

Thank you for your patch.

Missatge de jason-jh.lin jason-jh.lin@mediatek.com del dia dj., 22 de jul. 2021 a les 11:26:

...
There are 2 display hardware path in mt8195, namely vdosys0 and vdosys1, so add their definition in mtk-mmsys documentation.

Just having 2 display hardware paths is not a reason to have two compatibles, isn't the IP block the same? Why do you need to introduce the two compatibles?

Thanks, Enric

Hi Enric,

Thanks for reviewing my patch.

The reason for using two compatibles is that vdosys0 and vdosys1 are different IP blocks.

With that there are different IP blocks, what do you mean? Do you mean that there are two completely different blocks with completely different functionalities?

Or that there is the same IP block twice? I mean, of course, the registers are different but has exactly the same functionality.

...

Because mmsys provides clock control, other display function blocks may use them as clock provider.

E.g.

mmsys with compatible="mediatek,mt8195-vdosys0"

[v4,1/6] arm64: dts: mt8195: add display node for vdosys0

https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.240...

ovl0: disp_ovl@1c000000 { ... clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; ... };

mmsys with compatible="mediatek,mt8195-vdosys1"

[v2,06/14] arm64: dts: mt8195: add display node for vdosys1

https://patchwork.kernel.org/project/linux-mediatek/patch/20210722094551.152...

vdo1_rdma0: vdo1_rdma@1c104000 { ... clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; ... };

Note that I am talking without knowing the hardware in detail, but I am wondering why I can't have something like this, where every mmsys is a clock and reset controller provider.

vdosys0: syscon@14000000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x14000000 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>; };

vdosys1: syscon@15000000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x15000000 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>; };

ovl0: disp_ovl@1c000000 { ... clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; ... };

vdo1_rdma0: vdo1_rdma@1c104000 { ... clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; ... };

What are the differences between vdosys0 and vdosys1 from a hardware point of view?

Cheers, Enric

...

Regards, Jason-JH.Lin

...
...
Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com

this patch is base on [1][2]

[1] dt-bindings: arm: mediatek: mmsys: convert to YAML format

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

[2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam l b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam l index 2d4ff0ce387b..0789a9614f12 100644

a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam l +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam l @@ -30,6 +30,8 @@ properties: - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys - mediatek,mt8365-mmsys
         - mediatek,mt8195-vdosys0
         - mediatek,mt8195-vdosys1
     - const: syscon
 - items:
     - const: mediatek,mt7623-mmsys
-- 2.18.0
--

Jason-JH Lin

27 Jul 27 Jul

2:53 a.m.

New subject: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

Hi Enric,

On Mon, 2021-07-26 at 12:08 +0200, Enric Balletbo Serra wrote:

...

Hi Jason,

Missatge de Jason-JH Lin jason-jh.lin@mediatek.com del dia dl., 26 de jul. 2021 a les 9:02:

...
On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:

...
Hi Jason,

Thank you for your patch.

Missatge de jason-jh.lin jason-jh.lin@mediatek.com del dia dj., 22 de jul. 2021 a les 11:26:

...
There are 2 display hardware path in mt8195, namely vdosys0 and vdosys1, so add their definition in mtk-mmsys documentation.

Just having 2 display hardware paths is not a reason to have two compatibles, isn't the IP block the same? Why do you need to introduce the two compatibles?

Thanks, Enric

Hi Enric,

Thanks for reviewing my patch.

The reason for using two compatibles is that vdosys0 and vdosys1 are different IP blocks.

With that there are different IP blocks, what do you mean? Do you mean that there are two completely different blocks with completely different functionalities?

Or that there is the same IP block twice? I mean, of course, the registers are different but has exactly the same functionality.

They are not the same IP block twice. Although both vdosys0 and vdosys1 will probe meiatek-drm driver, but the components on their hardware path are different and their output panel are also different.

...

...
Because mmsys provides clock control, other display function blocks may use them as clock provider.

E.g.

mmsys with compatible="mediatek,mt8195-vdosys0"

[v4,1/6] arm64: dts: mt8195: add display node for vdosys0

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
ovl0: disp_ovl@1c000000 { ... clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; ... };

mmsys with compatible="mediatek,mt8195-vdosys1"

[v2,06/14] arm64: dts: mt8195: add display node for vdosys1

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
vdo1_rdma0: vdo1_rdma@1c104000 { ... clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; ... };

Note that I am talking without knowing the hardware in detail, but I am wondering why I can't have something like this, where every mmsys is a clock and reset controller provider.

vdosys0: syscon@14000000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x14000000 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>; };

vdosys1: syscon@15000000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x15000000 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>; };

ovl0: disp_ovl@1c000000 { ... clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; ... };

vdo1_rdma0: vdo1_rdma@1c104000 { ... clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; ... };

What are the differences between vdosys0 and vdosys1 from a hardware point of view?

Cheers, Enric

...
Regards, Jason-JH.Lin

From a hardware point of view, the components and the ouptut panel of vdosys0 and vdosys1: 1. The components on meiatek-drm of vdosys0 are OVL0, RDMA0, COLOR0, CCORR, AAL0, GAMMA, DITHER, DSC0, MERGE0, DP_INTF0 and its output panel is eDP.

2. The components on meiatek-drm of vdosys1 are PSEUDO_OVL, MERGE5, DP_INTF1 and its ouptut panel is DP.

The resaon for using two compatibales is that we use different driver data in mtk-mmsys.c and mtk_drm_drv.c to identify the corresponding mmsys is vdosys0 or vdosys1.

Their driver data in mtk_drm_drv.c is defined here: [v4,4/6] drm/mediatek: add mediatek-drm of vdosys0 support for mt8195

https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.240... [v2,14/14] drm/mediatek: add mediatek-drm of vdosys1 support for MT8195

https://patchwork.kernel.org/project/linux-mediatek/patch/20210722094551.152...

I think using the same compatible is unable to do this. Or do you have other suggestions to do this with the same compatibe?

Regards, Jason-JH.Lin

...

...
...
...
Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com

this patch is base on [1][2]

[1] dt-bindings: arm: mediatek: mmsys: convert to YAML format

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
...
...
[2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
...
...
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys .yam l b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys .yam l index 2d4ff0ce387b..0789a9614f12 100644

a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys .yam l +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys .yam l @@ -30,6 +30,8 @@ properties: - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys - mediatek,mt8365-mmsys
         - mediatek,mt8195-vdosys0
         - mediatek,mt8195-vdosys1
     - const: syscon
 - items:
     - const: mediatek,mt7623-mmsys
-- 2.18.0
--

-- Jason-JH Lin jason-jh.lin@mediatek.com

Enric Balletbo Serra

28 Jul 28 Jul

10:56 a.m.

New subject: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

Hi Jason,

Missatge de Jason-JH Lin jason-jh.lin@mediatek.com del dia dt., 27 de jul. 2021 a les 4:53:

...

Hi Enric,

On Mon, 2021-07-26 at 12:08 +0200, Enric Balletbo Serra wrote:

...
Hi Jason,

Missatge de Jason-JH Lin jason-jh.lin@mediatek.com del dia dl., 26 de jul. 2021 a les 9:02:

...
On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:

...
Hi Jason,

Thank you for your patch.

Missatge de jason-jh.lin jason-jh.lin@mediatek.com del dia dj., 22 de jul. 2021 a les 11:26:

...
There are 2 display hardware path in mt8195, namely vdosys0 and vdosys1, so add their definition in mtk-mmsys documentation.

Just having 2 display hardware paths is not a reason to have two compatibles, isn't the IP block the same? Why do you need to introduce the two compatibles?

Thanks, Enric

Hi Enric,

Thanks for reviewing my patch.

The reason for using two compatibles is that vdosys0 and vdosys1 are different IP blocks.

With that there are different IP blocks, what do you mean? Do you mean that there are two completely different blocks with completely different functionalities?

Or that there is the same IP block twice? I mean, of course, the registers are different but has exactly the same functionality.

They are not the same IP block twice. Although both vdosys0 and vdosys1 will probe meiatek-drm driver, but the components on their hardware path are different and their output panel are also different.

...
...
Because mmsys provides clock control, other display function blocks may use them as clock provider.

E.g.

mmsys with compatible="mediatek,mt8195-vdosys0"

[v4,1/6] arm64: dts: mt8195: add display node for vdosys0

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...
...
ovl0: disp_ovl@1c000000 { ... clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; ... };

mmsys with compatible="mediatek,mt8195-vdosys1"

[v2,06/14] arm64: dts: mt8195: add display node for vdosys1

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...
...
vdo1_rdma0: vdo1_rdma@1c104000 { ... clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; ... };

Note that I am talking without knowing the hardware in detail, but I am wondering why I can't have something like this, where every mmsys is a clock and reset controller provider.

vdosys0: syscon@14000000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x14000000 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>; };

vdosys1: syscon@15000000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x15000000 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>; };

ovl0: disp_ovl@1c000000 { ... clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; ... };

vdo1_rdma0: vdo1_rdma@1c104000 { ... clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; ... };

What are the differences between vdosys0 and vdosys1 from a hardware point of view?

Cheers, Enric

...
Regards, Jason-JH.Lin

From a hardware point of view, the components and the ouptut panel of vdosys0 and vdosys1:

The components on meiatek-drm of vdosys0 are OVL0, RDMA0, COLOR0,

CCORR, AAL0, GAMMA, DITHER, DSC0, MERGE0, DP_INTF0 and its output panel is eDP.

The components on meiatek-drm of vdosys1 are PSEUDO_OVL, MERGE5,

DP_INTF1 and its ouptut panel is DP.

The resaon for using two compatibales is that we use different driver data in mtk-mmsys.c and mtk_drm_drv.c to identify the corresponding mmsys is vdosys0 or vdosys1.

So IIUC the two mmsys block ares basically the same, they provide the same, a reset controller, a clock controller and being able to write to the routing registers, and what you only need to identify is which one is is vdosys0 and which one is vdosys1 to apply different routing tables? Can these routing tables change at runtime? Or are they hardware fixed?

Regards, Enric

...

Their driver data in mtk_drm_drv.c is defined here: [v4,4/6] drm/mediatek: add mediatek-drm of vdosys0 support for mt8195

https://patchwork.kernel.org/project/linux-mediatek/patch/20210723090233.240... [v2,14/14] drm/mediatek: add mediatek-drm of vdosys1 support for MT8195

https://patchwork.kernel.org/project/linux-mediatek/patch/20210722094551.152...

I think using the same compatible is unable to do this. Or do you have other suggestions to do this with the same compatibe?

Regards, Jason-JH.Lin

...
...
...
...
Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com

this patch is base on [1][2]

[1] dt-bindings: arm: mediatek: mmsys: convert to YAML format

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...
...
...
...
[2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...
...
...
...
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys .yam l b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys .yam l index 2d4ff0ce387b..0789a9614f12 100644

a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys .yam l +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys .yam l @@ -30,6 +30,8 @@ properties: - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys - mediatek,mt8365-mmsys
         - mediatek,mt8195-vdosys0
         - mediatek,mt8195-vdosys1
     - const: syscon
 - items:
     - const: mediatek,mt7623-mmsys
-- 2.18.0
--
-- Jason-JH Lin jason-jh.lin@mediatek.com

Jason-JH Lin

29 Jul 29 Jul

9:31 a.m.

New subject: [PATCH v1 1/5] dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding

Hi Enric,

Thanks for your review.

On Wed, 2021-07-28 at 12:56 +0200, Enric Balletbo Serra wrote:

...

Hi Jason,

Missatge de Jason-JH Lin jason-jh.lin@mediatek.com del dia dt., 27 de jul. 2021 a les 4:53:

...
Hi Enric,

On Mon, 2021-07-26 at 12:08 +0200, Enric Balletbo Serra wrote:

...
Hi Jason,

Missatge de Jason-JH Lin jason-jh.lin@mediatek.com del dia dl., 26 de jul. 2021 a les 9:02:

...
On Fri, 2021-07-23 at 13:13 +0200, Enric Balletbo Serra wrote:

...
Hi Jason,

Thank you for your patch.

Missatge de jason-jh.lin jason-jh.lin@mediatek.com del dia dj., 22 de jul. 2021 a les 11:26:

...
There are 2 display hardware path in mt8195, namely vdosys0 and vdosys1, so add their definition in mtk-mmsys documentation.

Just having 2 display hardware paths is not a reason to have two compatibles, isn't the IP block the same? Why do you need to introduce the two compatibles?

Thanks, Enric

Hi Enric,

Thanks for reviewing my patch.

The reason for using two compatibles is that vdosys0 and vdosys1 are different IP blocks.

With that there are different IP blocks, what do you mean? Do you mean that there are two completely different blocks with completely different functionalities?

Or that there is the same IP block twice? I mean, of course, the registers are different but has exactly the same functionality.

They are not the same IP block twice. Although both vdosys0 and vdosys1 will probe meiatek-drm driver, but the components on their hardware path are different and their output panel are also different.

...
...
Because mmsys provides clock control, other display function blocks may use them as clock provider.

E.g.

mmsys with compatible="mediatek,mt8195-vdosys0"

[v4,1/6] arm64: dts: mt8195: add display node for vdosys0

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
...
...
ovl0: disp_ovl@1c000000 { ... clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; ... };

mmsys with compatible="mediatek,mt8195-vdosys1"

[v2,06/14] arm64: dts: mt8195: add display node for vdosys1

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
...
...
vdo1_rdma0: vdo1_rdma@1c104000 { ... clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; ... };

Note that I am talking without knowing the hardware in detail, but I am wondering why I can't have something like this, where every mmsys is a clock and reset controller provider.

vdosys0: syscon@14000000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x14000000 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>; };

vdosys1: syscon@15000000 { compatible = "mediatek,mt8195-mmsys", "syscon"; reg = <0 0x15000000 0 0x1000>; #clock-cells = <1>; #reset-cells = <1>; };

ovl0: disp_ovl@1c000000 { ... clocks = <&vdosys0 CLK_VDO0_DISP_OVL0>; ... };

vdo1_rdma0: vdo1_rdma@1c104000 { ... clocks = <&vdosys1 CLK_VDO1_MDP_RDMA0>; ... };

What are the differences between vdosys0 and vdosys1 from a hardware point of view?

Cheers, Enric

...
Regards, Jason-JH.Lin

From a hardware point of view, the components and the ouptut panel of vdosys0 and vdosys1:

The components on meiatek-drm of vdosys0 are OVL0, RDMA0,

COLOR0, CCORR, AAL0, GAMMA, DITHER, DSC0, MERGE0, DP_INTF0 and its output panel is eDP.

The components on meiatek-drm of vdosys1 are PSEUDO_OVL, MERGE5,

DP_INTF1 and its ouptut panel is DP.

The resaon for using two compatibales is that we use different driver data in mtk-mmsys.c and mtk_drm_drv.c to identify the corresponding mmsys is vdosys0 or vdosys1.

So IIUC the two mmsys block ares basically the same, they provide the same, a reset controller, a clock controller and being able to write to the routing registers, and what you only need to identify is which one is is vdosys0 and which one is vdosys1 to apply different routing tables? Can these routing tables change at runtime? Or are they hardware fixed?

Regards, Enric

In the case of vdosys1 DP_TX switch to HDMI_TX, routing tables will change at runtime.

Refer to mt8173.dtsi:

https://elixir.bootlin.com/linux/latest/source/arch/arm64/boot/dts/mediatek/... I forgot to put the power domain property in vdosys0 dts node. So I'll add this into DRM vdosys0 series at the next version: vdosys0: syscon@1c01a000 { compatible = "mediatek,mt8195-vdosys0", "syscon"; reg = <0 0x1c01a000 0 0x1000>; power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; ... }; I'll also tell Nancy to add this: vdosys1: syscon@1c100000 { compatible = "mediatek,mt8195-vdosys1", "syscon"; reg = <0 0x1c100000 0 0x1000>; power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; ... }; I'll also add the power-domian description into this yaml. 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.

In the SoC before, such as mt8173, it has 2 pipelines binding to one mmsys with the same clock driver and the same power domain.

In mt8195, 2 pipelines are binding to different mmsys, such as vdosys0 and vdosys1. Each mmsys uses different clock drivers and different power domain. So I think it is more appropriate to use 2 compatibles to identify which mmsys represents the pipeline.

Regards, Jason-JH.Lin

...

...
Their driver data in mtk_drm_drv.c is defined here: [v4,4/6] drm/mediatek: add mediatek-drm of vdosys0 support for mt8195

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
[v2,14/14] drm/mediatek: add mediatek-drm of vdosys1 support for MT8195

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
I think using the same compatible is unable to do this. Or do you have other suggestions to do this with the same compatibe?

Regards, Jason-JH.Lin

...
...
...
...
Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com

this patch is base on [1][2]

[1] dt-bindings: arm: mediatek: mmsys: convert to YAML format

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
...
...
...
...
[2] dt-bindings: arm: mediatek: mmsys: add MT8365 SoC binding

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-media...

...

...
...
...
...
...
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,m msys .yam l b/Documentation/devicetree/bindings/arm/mediatek/mediatek,m msys .yam l index 2d4ff0ce387b..0789a9614f12 100644

a/Documentation/devicetree/bindings/arm/mediatek/mediatek,m msys .yam l +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,m msys .yam l @@ -30,6 +30,8 @@ properties: - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys - mediatek,mt8365-mmsys
         - mediatek,mt8195-vdosys0
         - mediatek,mt8195-vdosys1
     - const: syscon
 - items:
     - const: mediatek,mt7623-mmsys
-- 2.18.0
--
-- Jason-JH Lin jason-jh.lin@mediatek.com

-- Jason-JH Lin jason-jh.lin@mediatek.com

jason-jh.lin

22 Jul 22 Jul

9:26 a.m.

New subject: [PATCH v1 2/5] dt-bindings: mediatek: display: Change format to yaml

Change mediatek,dislpay.txt to mediatek,display.yaml

Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com --- .../display/mediatek/mediatek,disp.txt | 219 --------- .../display/mediatek/mediatek,disp.yaml | 432 ++++++++++++++++++ 2 files changed, 432 insertions(+), 219 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt deleted file mode 100644 index fbb59c9ddda6..000000000000 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ /dev/null @@ -1,219 +0,0 @@ -Mediatek display subsystem -========================== - -The Mediatek display subsystem consists of various DISP function blocks in the -MMSYS register space. The connections between them can be configured by output -and input selectors in the MMSYS_CONFIG register space. Pixel clock and start -of frame signal are distributed to the other function blocks by a DISP_MUTEX -function block. - -All DISP device tree nodes 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.txt. - -DISP function blocks -==================== - -A display stream starts at a source function block that reads pixel data from -memory and ends with a sink function block that drives pixels on a display -interface, or writes pixels back to memory. All DISP function blocks have -their own register space, interrupt, and clock gate. The blocks that can -access memory additionally have to list the IOMMU and local arbiter they are -connected to. - -For a description of the display interface sink function blocks, see -Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt and -Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml. - -Required properties (all function blocks): -- compatible: "mediatek,<chip>-disp-<function>", one of - "mediatek,<chip>-disp-ovl" - overlay (4 layers, blending, csc) - "mediatek,<chip>-disp-ovl-2l" - overlay (2 layers, blending, csc) - "mediatek,<chip>-disp-rdma" - read DMA / line buffer - "mediatek,<chip>-disp-wdma" - write DMA - "mediatek,<chip>-disp-ccorr" - color correction - "mediatek,<chip>-disp-color" - color processor - "mediatek,<chip>-disp-dither" - dither - "mediatek,<chip>-disp-aal" - adaptive ambient light controller - "mediatek,<chip>-disp-gamma" - gamma correction - "mediatek,<chip>-disp-merge" - merge streams from two RDMA sources - "mediatek,<chip>-disp-postmask" - control round corner for display frame - "mediatek,<chip>-disp-split" - split stream to two encoders - "mediatek,<chip>-disp-ufoe" - data compression engine - "mediatek,<chip>-dsi" - DSI controller, see mediatek,dsi.txt - "mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt - "mediatek,<chip>-disp-mutex" - display mutex - "mediatek,<chip>-disp-od" - overdrive - the supported chips are mt2701, mt7623, mt2712, mt8167, mt8173, mt8183 and mt8192. -- reg: Physical base address and length of the function block register space -- interrupts: The interrupt signal from the function block (required, except for - merge and split function blocks). -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. - For most function blocks this is just a single clock input. Only the DSI and - DPI controller nodes have multiple clock inputs. These are documented in - mediatek,dsi.txt and mediatek,dpi.txt, respectively. - An exception is that the mt8183 mutex is always free running with no clocks property. - -Required properties (DMA function blocks): -- compatible: Should be one of - "mediatek,<chip>-disp-ovl" - "mediatek,<chip>-disp-rdma" - "mediatek,<chip>-disp-wdma" - the supported chips are mt2701, mt8167 and mt8173. -- larb: Should contain a phandle pointing to the local arbiter device as defined - in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml -- iommus: Should point to the respective IOMMU block with master port as - argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml - for details. - -Optional properties (RDMA function blocks): -- mediatek,rdma-fifo-size: rdma fifo size may be different even in same SOC, add this - property to the corresponding rdma - the value is the Max value which defined in hardware data sheet. - mediatek,rdma-fifo-size of mt8173-rdma0 is 8K - mediatek,rdma-fifo-size of mt8183-rdma0 is 5K - mediatek,rdma-fifo-size of mt8183-rdma1 is 2K - -Examples: - -mmsys: clock-controller@14000000 { - compatible = "mediatek,mt8173-mmsys", "syscon"; - reg = <0 0x14000000 0 0x1000>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - #clock-cells = <1>; -}; - -ovl0: ovl@1400c000 { - compatible = "mediatek,mt8173-disp-ovl"; - reg = <0 0x1400c000 0 0x1000>; - interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OVL0>; - iommus = <&iommu M4U_PORT_DISP_OVL0>; - mediatek,larb = <&larb0>; -}; - -ovl1: ovl@1400d000 { - compatible = "mediatek,mt8173-disp-ovl"; - reg = <0 0x1400d000 0 0x1000>; - interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OVL1>; - iommus = <&iommu M4U_PORT_DISP_OVL1>; - mediatek,larb = <&larb4>; -}; - -rdma0: rdma@1400e000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x1400e000 0 0x1000>; - interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA0>; - iommus = <&iommu M4U_PORT_DISP_RDMA0>; - mediatek,larb = <&larb0>; - mediatek,rdma-fifosize = <8192>; -}; - -rdma1: rdma@1400f000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x1400f000 0 0x1000>; - interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA1>; - iommus = <&iommu M4U_PORT_DISP_RDMA1>; - mediatek,larb = <&larb4>; -}; - -rdma2: rdma@14010000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x14010000 0 0x1000>; - interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA2>; - iommus = <&iommu M4U_PORT_DISP_RDMA2>; - mediatek,larb = <&larb4>; -}; - -wdma0: wdma@14011000 { - compatible = "mediatek,mt8173-disp-wdma"; - reg = <0 0x14011000 0 0x1000>; - interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_WDMA0>; - iommus = <&iommu M4U_PORT_DISP_WDMA0>; - mediatek,larb = <&larb0>; -}; - -wdma1: wdma@14012000 { - compatible = "mediatek,mt8173-disp-wdma"; - reg = <0 0x14012000 0 0x1000>; - interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_WDMA1>; - iommus = <&iommu M4U_PORT_DISP_WDMA1>; - mediatek,larb = <&larb4>; -}; - -color0: color@14013000 { - compatible = "mediatek,mt8173-disp-color"; - reg = <0 0x14013000 0 0x1000>; - interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_COLOR0>; -}; - -color1: color@14014000 { - compatible = "mediatek,mt8173-disp-color"; - reg = <0 0x14014000 0 0x1000>; - interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_COLOR1>; -}; - -aal@14015000 { - compatible = "mediatek,mt8173-disp-aal"; - reg = <0 0x14015000 0 0x1000>; - interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_AAL>; -}; - -gamma@14016000 { - compatible = "mediatek,mt8173-disp-gamma"; - reg = <0 0x14016000 0 0x1000>; - interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_GAMMA>; -}; - -ufoe@1401a000 { - compatible = "mediatek,mt8173-disp-ufoe"; - reg = <0 0x1401a000 0 0x1000>; - interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_UFOE>; -}; - -dsi0: dsi@1401b000 { - /* See mediatek,dsi.txt for details */ -}; - -dpi0: dpi@1401d000 { - /* See mediatek,dpi.txt for details */ -}; - -mutex: mutex@14020000 { - compatible = "mediatek,mt8173-disp-mutex"; - reg = <0 0x14020000 0 0x1000>; - interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_MUTEX_32K>; -}; - -od@14023000 { - compatible = "mediatek,mt8173-disp-od"; - reg = <0 0x14023000 0 0x1000>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OD>; -}; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml new file mode 100644 index 000000000000..f01ecf7fcbde --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml @@ -0,0 +1,432 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,disp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: mediatek Display Subsystem Device Tree Bindings + +maintainers: + - CK Hu ck.hu@mediatek.com + - Jason-JH Lin jason-jh.lin@mediatek.com + +description: | + The Mediatek display subsystem consists of various DISP function blocks in the + MMSYS register space. The connections between them can be configured by output + and input selectors in the MMSYS_CONFIG register space. Pixel clock and start + of frame signal are distributed to the other function blocks by a DISP_MUTEX + function block. + All DISP device tree nodes 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. + + DISP function blocks + ==================== + A display stream starts at a source function block that reads pixel data from + memory and ends with a sink function block that drives pixels on a display + interface, or writes pixels back to memory. All DISP function blocks have + their own register space, interrupt, and clock gate. The blocks that can + access memory additionally have to list the IOMMU and local arbiter they are + connected to. + +properties: + compatible: + description: | + If the display function block of different soc have the same function, + you can use the same compatible name after it. + For example, if mt8183 COLOR function is the same as mt8173, then the + compatible of mt8183 cholud be set as: + compatible = "mediatek,mt8183-disp-color", "mediatek,mt8173-disp-color"; + oneOf: + # OVL: overlay (4 layers, blending, csc) + - items: + - const: mediatek,mt2701-disp-ovl + - items: + - const: mediatek,mt8173-disp-ovl + - items: + - const: mediatek,mt8183-disp-ovl + - items: + - enum: + - mediatek,mt7623-disp-ovl + - mediatek,mt2712-disp-ovl + - enum: + - mediatek,mt2701-disp-ovl + - items: + - enum: + - mediatek,mt8192-disp-ovl + - enum: + - mediatek,mt8183-disp-ovl + + # OVL2L: overlay (2 layers, blending, csc) + - items: + - const: mediatek,mt8183-disp-ovl-2l + - items: + - enum: + - mediatek,mt8192-disp-ovl-2l + - enum: + - mediatek,mt8183-disp-ovl-2l + + # RDMA: read DMA / line buffer + - items: + - const: mediatek,mt2701-disp-rdma + - items: + - const: mediatek,mt8173-disp-rdma + - items: + - const: mediatek,mt8183-disp-rdma + - items: + - enum: + - mediatek,mt7623-disp-rdma + - mediatek,mt2712-disp-rdma + - enum: + - mediatek,mt2701-disp-rdma + - items: + - enum: + - mediatek,mt8192-disp-rdma + - enum: + - mediatek,mt8183-disp-rdma + + # WDMA: write DMA + - items: + - const: mediatek,mt8173-disp-wdma + + # CCORR: color correction + - items: + - const: mediatek,mt8183-disp-ccorr + - items: + - enum: + - mediatek,mt8192-disp-ccorr + - enum: + - mediatek,mt8183-disp-ccorr + + # COLOR: color processor + - items: + - const: mediatek,mt2701-disp-color + - items: + - const: mediatek,mt8167-disp-color + - items: + - const: mediatek,mt8173-disp-color + - items: + - enum: + - mediatek,mt7623-disp-color + - mediatek,mt2712-disp-color + - enum: + - mediatek,mt2701-disp-color + - items: + - enum: + - mediatek,mt8183-disp-color + - mediatek,mt8192-disp-color + - enum: + - mediatek,mt8173-disp-color + + # DITHER + - items: + - const: mediatek,mt8183-disp-dither + - items: + - enum: + - mediatek,mt8192-disp-dither + - enum: + - mediatek,mt8183-disp-dither + + # AAL: adaptive ambient light controller + - items: + - const: mediatek,mt8173-disp-aal + - items: + - enum: + - mediatek,mt2712-disp-aal + - mediatek,mt8183-disp-aal + - mediatek,mt8192-disp-aal + - enum: + - mediatek,mt8173-disp-aal + + # GAMMA: gamma correction + - items: + - const: mediatek,mt8173-disp-gamma + - items: + - const: mediatek,mt8183-disp-gamma + - items: + - enum: + - mediatek,mt8192-disp-gamma + - enum: + - mediatek,mt8183-disp-gamma + + # MERGE: merge streams from two RDMA sources + + # POSTMASK: control round corner for display frame + - items: + - const: mediatek,mt8192-disp-postmask + + # SPLIT: split stream to two encoders + + # UFOE: data compression engine + - items: + - const: mediatek,mt8173-disp-ufoe + + # DSI: see Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt for details. + - items: + - const: mediatek,mt2701-disp-dsi + - items: + - const: mediatek,mt8173-disp-dsi + - items: + - const: mediatek,mt8183-disp-dsi + - items: + - enum: + - mediatek,mt7623-disp-dsi + - mediatek,mt2712-disp-dsi + - enum: + - mediatek,mt2701-disp-dsi + - items: + - enum: + - mediatek,mt8192-disp-dsi + - enum: + - mediatek,mt8183-disp-dsi + + # DPI: see Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml for details. + - items: + - const: mediatek,mt2701-disp-dpi + - items: + - const: mediatek,mt8173-disp-dpi + - items: + - const: mediatek,mt8183-disp-dpi + - items: + - const: mediatek,mt8192-disp-dpi + - items: + - enum: + - mediatek,mt7623-disp-dpi + - mediatek,mt2712-disp-dpi + - enum: + - mediatek,mt2701-disp-dpi + + # MUTEX: display mutex + - items: + - const: mediatek,mt2701-disp-mutex + - items: + - const: mediatek,mt2712-disp-mutex + - items: + - const: mediatek,mt8167-disp-mutex + - items: + - const: mediatek,mt8173-disp-mutex + - items: + - const: mediatek,mt8183-disp-mutex + - items: + - const: mediatek,mt8192-disp-mutex + + # OD: overdrive + - items: + - const: mediatek,mt2712-disp-od + - items: + - const: mediatek,mt8173-disp-od + + reg: + description: Physical base address and length of the function block register space. + + interrupts: + description: The interrupt signal from the function block required, + except for merge and split function blocks. + + clocks: + description: clock drivers + See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. + For most function blocks this is just a single clock input. + Only the DSI and DPI controller nodes have multiple clock inputs. These are documented + in mediatek,dsi.txt and mediatek,dpi.yaml, respectively. + An exception is that the mt8183 mutex is always free running with no clocks property. + + mediatek,larb: + description: The compatible property should be one of DMA function blocks, + such as "mediatek,<chip>-disp-ovl", "mediatek,<chip>-disp-rdma" or + "mediatek,<chip>-disp-wdma". The supported chips are mt2701, mt8167 and mt8173. + Should contain a phandle pointing to the local arbiter device as defined in + Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml. + It must sort according to the local arbiter index, like larb0, larb1, larb2... + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 32 + + iommus: + description: The compatible property should be one of DMA function blocks, + such as "mediatek,<chip>-disp-ovl", "mediatek,<chip>-disp-rdma" or + "mediatek,<chip>-disp-wdma". The supported chips are mt2701, mt8167 and mt8173. + Should point to the respective IOMMU block with master port as argument, see + Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,rdma-fifo-size: + description: RDMA function blocks + rdma fifo size may be different even in same SOC, add this property to the + corresponding rdma. + The value below is the Max value which defined in hardware data sheet + mediatek,rdma-fifo-size of mt8173-rdma0 is 8K + mediatek,rdma-fifo-size of mt8183-rdma0 is 5K + mediatek,rdma-fifo-size of mt8183-rdma1 is 2K + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8*1024, 5*1024, 2*1024] + + 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. + + mediatek,gce-client-reg: + description: The register of display function block to be set by gce. + There are 4 arguments in this property, 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. + For example, The mediatek,gce-client-reg property of OVL in mt8173 is + <&gce SUBSYS_1400XXXX 0xc000 0x1000>. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + + ovl0: ovl@1400c000 { + compatible = "mediatek,mt8173-disp-ovl"; + reg = <0 0x1400c000 0 0x1000>; + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_OVL0>; + iommus = <&iommu M4U_PORT_DISP_OVL0>; + mediatek,larb = <&larb0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>; + }; + + ovl1: ovl@1400d000 { + compatible = "mediatek,mt8173-disp-ovl"; + reg = <0 0x1400d000 0 0x1000>; + interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_OVL1>; + iommus = <&iommu M4U_PORT_DISP_OVL1>; + mediatek,larb = <&larb4>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xd000 0x1000>; + }; + + rdma0: rdma@1400e000 { + compatible = "mediatek,mt8173-disp-rdma"; + reg = <0 0x1400e000 0 0x1000>; + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_RDMA0>; + iommus = <&iommu M4U_PORT_DISP_RDMA0>; + mediatek,larb = <&larb0>; + mediatek,rdma-fifosize = <8192>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xe000 0x1000>; + }; + + rdma1: rdma@1400f000 { + compatible = "mediatek,mt8173-disp-rdma"; + reg = <0 0x1400f000 0 0x1000>; + interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_RDMA1>; + iommus = <&iommu M4U_PORT_DISP_RDMA1>; + mediatek,larb = <&larb4>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xf000 0x1000>; + }; + + rdma2: rdma@14010000 { + compatible = "mediatek,mt8173-disp-rdma"; + reg = <0 0x14010000 0 0x1000>; + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_RDMA2>; + iommus = <&iommu M4U_PORT_DISP_RDMA2>; + mediatek,larb = <&larb4>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0 0x1000>; + }; + + wdma0: wdma@14011000 { + compatible = "mediatek,mt8173-disp-wdma"; + reg = <0 0x14011000 0 0x1000>; + interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_WDMA0>; + iommus = <&iommu M4U_PORT_DISP_WDMA0>; + mediatek,larb = <&larb0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x1000 0x1000>; + }; + + wdma1: wdma@14012000 { + compatible = "mediatek,mt8173-disp-wdma"; + reg = <0 0x14012000 0 0x1000>; + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_WDMA1>; + iommus = <&iommu M4U_PORT_DISP_WDMA1>; + mediatek,larb = <&larb4>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x2000 0x1000>; + }; + + color0: color@14013000 { + compatible = "mediatek,mt8173-disp-color"; + reg = <0 0x14013000 0 0x1000>; + interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_COLOR0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x3000 0x1000>; + }; + + color1: color@14014000 { + compatible = "mediatek,mt8173-disp-color"; + reg = <0 0x14014000 0 0x1000>; + interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_COLOR1>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x4000 0x1000>; + }; + + aal@14015000 { + compatible = "mediatek,mt8173-disp-aal"; + reg = <0 0x14015000 0 0x1000>; + interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_AAL>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>; + }; + + gamma@14016000 { + compatible = "mediatek,mt8173-disp-gamma"; + reg = <0 0x14016000 0 0x1000>; + interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_GAMMA>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x6000 0x1000>; + }; + + ufoe@1401a000 { + compatible = "mediatek,mt8173-disp-ufoe"; + reg = <0 0x1401a000 0 0x1000>; + interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_UFOE>; + }; + + dsi0: dsi@1401b000 { + /* See mediatek,dsi.txt for details */ + }; + + dpi0: dpi@1401d000 { + /* See mediatek,dpi.yaml for details */ + }; + + mutex: mutex@14020000 { + compatible = "mediatek,mt8173-disp-mutex"; + reg = <0 0x14020000 0 0x1000>; + interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_MUTEX_32K>; + }; + + od@14023000 { + compatible = "mediatek,mt8173-disp-od"; + reg = <0 0x14023000 0 0x1000>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_OD>; + };

-- 2.18.0

jason-jh.lin

9:26 a.m.

New subject: [PATCH v1 3/5] dt-bindings: mediatek: display: add MERGE additional description

1. clock drivers of MERGE The MERGE controller may have 2 clock inputs. The second clock of MERGE is async clock which is controlling the async buffer between MERGE and other display function blocks.

2. MERGE fifo settings enable The setting of merge fifo is mainly provided for the display latency buffer. To ensure that the back-end panel display data will not be underrun, a little more data is needed in the fifo. According to the merge fifo settings, when the water level is detected to be insufficient, it will trigger RDMA sending ultra and preulra command to SMI to speed up the data rate.

Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com --- .../bindings/display/mediatek/mediatek,disp.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml index f01ecf7fcbde..f16ee592735d 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.yaml @@ -227,6 +227,9 @@ properties: description: clock drivers See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. For most function blocks this is just a single clock input. + The MERGE controller may have 2 clock inputs. The second clock of MERGE is async clock, + which is controlling the synchronous process between MERGE and other display function + blocks cross clock domain. Only the DSI and DPI controller nodes have multiple clock inputs. These are documented in mediatek,dsi.txt and mediatek,dpi.yaml, respectively. An exception is that the mt8183 mutex is always free running with no clocks property. @@ -260,6 +263,15 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 enum: [8*1024, 5*1024, 2*1024]

+ mediatek,merge-fifo-en: + description: MERGE fifo settings enable + The setting of merge fifo is mainly provided for the display latency buffer. + To ensure that the back-end panel display data will not be underrun, + a little more data is needed in the fifo. According to the merge fifo settings, + when the water level is detected to be insufficient, it will trigger RDMA sending + ultra and preulra command to SMI to speed up the data rate. + type: boolean + power-domains: description: A phandle and PM domain specifier as defined by bindings of the power controller specified by phandle. See

-- 2.18.0

jason-jh.lin

9:26 a.m.

New subject: [PATCH v1 4/5] dt-bindings: mediatek: add mediatek, dsc.yaml for mt8195 SoC binding

1. Add mediatek,dsc.yaml to decribe DSC module in details. 2. Add mt8195 SoC binding to mediatek,dsc.yaml.

Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com --- .../display/mediatek/mediatek,dsc.yaml | 73 +++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml new file mode 100644 index 000000000000..f575532bfb21 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: mediatek DSC Controller Device Tree Bindings + +maintainers: + - CK Hu ck.hu@mediatek.com + - Jitao shi jitao.shi@mediatek.com + - Jason-JH Lin jason-jh.lin@mediatek.com + +description: | + The DSC standard is a specification of the algorithms used for + compressing and decompressing image display streams, including + the specification of the syntax and semantics of the compressed + video bit stream. DSC is designed for real-time systems with + real-time compression, transmission, decompression and Display. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8195-disp-dsc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: DSC Wrapper Clock + + 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. + + mediatek,gce-client-reg: + description: The register of display function block to be set by gce. + There are 4 arguments in this property, 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. + For example, The mediatek,gce-client-reg property of OVL in mt8173 is + <&gce SUBSYS_1400XXXX 0xc000 0x1000>. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + dsc0: disp_dsc_wrap@1c009000 { + compatible = "mediatek,mt8195-disp-dsc"; + reg = <0 0x1c009000 0 0x1000>; + interrupts = <GIC_SPI 645 IRQ_TYPE_LEVEL_HIGH 0>; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DSC_WRAP0>; + mediatek,gce-client-reg = + <&gce1 SUBSYS_1c00XXXX 0x9000 0x1000>; + }; + +...

-- 2.18.0

jason-jh.lin

9:26 a.m.

New subject: [PATCH v1 5/5] dt-bindings: mediatek: display: add mt8195 SoC binding

Add mt8195 SoC display binding.

Signed-off-by: jason-jh.lin jason-jh.lin@mediatek.com --- .../display/mediatek/mediatek,disp.yaml | 24 +++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-)

@@ -73,6 +74,8 @@ properties: - const: mediatek,mt8173-disp-rdma - items: - const: mediatek,mt8183-disp-rdma + - items: + - const: mediatek,mt8195-disp-rdma - items: - enum: - mediatek,mt7623-disp-rdma @@ -95,6 +98,7 @@ properties: - items: - enum: - mediatek,mt8192-disp-ccorr + - mediatek,mt8195-disp-ccorr - enum: - mediatek,mt8183-disp-ccorr

@@ -115,6 +119,7 @@ properties: - enum: - mediatek,mt8183-disp-color - mediatek,mt8192-disp-color + - mediatek,mt8195-disp-color - enum: - mediatek,mt8173-disp-color

@@ -124,6 +129,7 @@ properties: - items: - enum: - mediatek,mt8192-disp-dither + - mediatek,mt8195-disp-dither - enum: - mediatek,mt8183-disp-dither

@@ -135,6 +141,7 @@ properties: - mediatek,mt2712-disp-aal - mediatek,mt8183-disp-aal - mediatek,mt8192-disp-aal + - mediatek,mt8195-disp-aal - enum: - mediatek,mt8173-disp-aal

@@ -146,10 +153,17 @@ properties: - items: - enum: - mediatek,mt8192-disp-gamma + - mediatek,mt8195-disp-gamma - enum: - mediatek,mt8183-disp-gamma

+ # DSC: see Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml for details. + - items: + - const: mediatek,mt8195-disp-dsc + # MERGE: merge streams from two RDMA sources + - items: + - const: mediatek,mt8195-disp-merge

# POSTMASK: control round corner for display frame - items: @@ -209,6 +223,8 @@ properties: - const: mediatek,mt8183-disp-mutex - items: - const: mediatek,mt8192-disp-mutex + - items: + - const: mediatek,mt8195-disp-mutex

# OD: overdrive - items: @@ -237,7 +253,7 @@ properties: mediatek,larb: description: The compatible property should be one of DMA function blocks, such as "mediatek,<chip>-disp-ovl", "mediatek,<chip>-disp-rdma" or - "mediatek,<chip>-disp-wdma". The supported chips are mt2701, mt8167 and mt8173. + "mediatek,<chip>-disp-wdma". The supported chips are mt2701, mt8167, mt8173 and mt8195. Should contain a phandle pointing to the local arbiter device as defined in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml. It must sort according to the local arbiter index, like larb0, larb1, larb2... @@ -248,7 +264,7 @@ properties: iommus: description: The compatible property should be one of DMA function blocks, such as "mediatek,<chip>-disp-ovl", "mediatek,<chip>-disp-rdma" or - "mediatek,<chip>-disp-wdma". The supported chips are mt2701, mt8167 and mt8173. + "mediatek,<chip>-disp-wdma". The supported chips are mt2701, mt8167, mt8173 and mt8195. Should point to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.

@@ -442,3 +458,7 @@ examples: power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DISP_OD>; }; + + dsc0: disp_dsc_wrap@1c009000 { + /* See mediatek,dsc.yaml for details */ + };

-- 2.18.0

1378

Age (days ago)

1385

Last active (days ago)

dri-devel@lists.freedesktop.org

11 comments

3 participants

tags (0)

participants (3)

Enric Balletbo Serra
Jason-JH Lin
jason-jh.lin