Aw: Re: Re: [PATCH v4 6/6] arm: dts: mt7623: add display subsystem related device nodes
CC Rob Herring + devicetree List + Sean
> Gesendet: Dienstag, 04. August 2020 um 20:02 Uhr
> Von: "David Woodhouse"
> On Tue, 2020-08-04 at 19:40 +0200, Frank Wunderlich wrote:
> > > Gesendet: Dienstag, 04. August 2020 um 19:24 Uhr
> > > Von: "David Woodhouse"
> > > > + mipi_tx0: mipi-dphy@1001 {
> > > > + compatible = "mediatek,mt7623-mipi-tx",
> > > > +"mediatek,mt2701-mipi-tx";
> > > > + reg = <0 0x1001 0 0x90>;
> > > > + clocks = <>;
> > > > + clock-output-names = "mipi_tx0_pll";
> > > > + #clock-cells = <0>;
> > > > + #phy-cells = <0>;
> > > > + };
> > >
> > > Doesn't this (and some others) also need status="disabled" since
> > > they're not present on MT7623A? Or maybe it's time to split
> > > mt7623.dtsi
> > > into a mt7623n.dtsi which includes mt7623a.dtsi and adds the extra
> > > components?
any opinions about this? should i disable all new nodes and enable them in the
dts for specific board (bpi-r2/mt7623n-rfb)?
have prepared it here [1]
> > do you have a MT7623A board for testing? is there any list which
> > components are existing on mt7623a? or should i disable all of them
> > and re-enable them in bpi-r2 dts?
>
> The UniElec U7623 board (which is supported in OpenWrt) is MT7623A.
>
> I was told that MT7623N has GPU and HDMI, while the MT7623A has a
> built-in mt7530 switch. Does that imply the switch on the MT7623N
> boards is *external*?
yes, bananapi r2 has external mt7530 switch connected to gmacs 0+1 with its
ports 6+5
> If so, that means that mt7623n.dtsi maybe shouldn't just include
> mt7623a.dtsi because it's not a strict superset; maybe they should both
> include a common mt7623.dtsi that has the parts that are truly common?
>
> I also suspect the switch definition from the UniElec U7623 dts should
> probably move to this new mt7623a.dtsi? That's not upstream yet though.
or should we split dtsi to have a common part (mt7623.dtsi), and one for
soc (mt7623n.dtsi/mt7623a.dtsi)?
mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not existing yet,
openwrt seems to use a board-specific dtsi)
regards Frank
[1] https://github.com/frank-w/BPI-R2-4.14/commits/5.8-hdmi4mainline
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Aw: Re: Re: Re: [PATCH v4 6/6] arm: dts: mt7623: add display subsystem related device nodes
> Gesendet: Mittwoch, 05. August 2020 um 10:36 Uhr > Von: "David Woodhouse" > > mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts > > mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not existing yet, > > openwrt seems to use a board-specific dtsi) > > Yes, I think we should. i want to see what MTK/DT owner says to this... my current way will be still adding the nodes to existing mt7623.dtsi (like ryder lee did it in original patch) but disabling them to not break mt7623a and splitting it afterwards. > I'll create mt7623a.dtsi and upstream the U7623 support; I think that > can happen without conflicting with anything you do. > > I note that the GPU node has been added to mt7623.dtsi in 5.8 too; > that'll want to move to the new mt7623n.dtsi that you create, along > with your other new additions. i guess mali-node also needs to be moved to mt7623n.dtsi, so my current way seems right... but it's decision of MTK/DT owner. if they make a note i squash the disabling-commit into this and post v5 regards Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aw: Re: Re: Re: [PATCH v4 6/6] arm: dts: mt7623: add display subsystem related device nodes
On Wed, 2020-08-05 at 10:49 +0200, Frank Wunderlich wrote: > > Gesendet: Mittwoch, 05. August 2020 um 10:36 Uhr > > Von: "David Woodhouse" > > > mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts > > > mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not > > > existing yet, > > > openwrt seems to use a board-specific dtsi) > > > > Yes, I think we should. > > i want to see what MTK/DT owner says to this... > my current way will be still adding the nodes to existing mt7623.dtsi > (like ryder lee did it in original patch) > but disabling them to not break mt7623a and splitting it afterwards. > > > I'll create mt7623a.dtsi and upstream the U7623 support; I think that > > can happen without conflicting with anything you do. > > > > I note that the GPU node has been added to mt7623.dtsi in 5.8 too; > > that'll want to move to the new mt7623n.dtsi that you create, along > > with your other new additions. > > i guess mali-node also needs to be moved to mt7623n.dtsi, so my > current way seems right... > but it's decision of MTK/DT owner. if they make a note i squash the > disabling-commit into this and post v5 Yes, the mali node needs moving too. I've pushed an untested series to http://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/mt7623 which does that and adds the UniElec board. smime.p7s Description: S/MIME cryptographic signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aw: Re: Re: [PATCH v4 6/6] arm: dts: mt7623: add display subsystem related device nodes
On Wed, 2020-08-05 at 09:27 +0200, Frank Wunderlich wrote: > or should we split dtsi to have a common part (mt7623.dtsi), and one for > soc (mt7623n.dtsi/mt7623a.dtsi)? > > mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts > mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not existing yet, > openwrt seems to use a board-specific dtsi) Yes, I think we should. I'll create mt7623a.dtsi and upstream the U7623 support; I think that can happen without conflicting with anything you do. I note that the GPU node has been added to mt7623.dtsi in 5.8 too; that'll want to move to the new mt7623n.dtsi that you create, along with your other new additions. Does that seem reasonable? smime.p7s Description: S/MIME cryptographic signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Aw: Re: [PATCH v4 6/6] arm: dts: mt7623: add display subsystem related device nodes
> Gesendet: Dienstag, 04. August 2020 um 19:24 Uhr
> Von: "David Woodhouse"
> > + mipi_tx0: mipi-dphy@1001 {
> > + compatible = "mediatek,mt7623-mipi-tx",
> > +"mediatek,mt2701-mipi-tx";
> > + reg = <0 0x1001 0 0x90>;
> > + clocks = <>;
> > + clock-output-names = "mipi_tx0_pll";
> > + #clock-cells = <0>;
> > + #phy-cells = <0>;
> > + };
>
> Doesn't this (and some others) also need status="disabled" since
> they're not present on MT7623A? Or maybe it's time to split mt7623.dtsi
> into a mt7623n.dtsi which includes mt7623a.dtsi and adds the extra
> components?
do you have a MT7623A board for testing? is there any list which components are
existing on mt7623a? or should i disable all of them and re-enable them in
bpi-r2 dts?
regards Frank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/6] arm: dts: mt7623: add display subsystem related device nodes
From: Ryder Lee
Add display subsystem related device nodes for MT7623.
Cc: CK Hu
Signed-off-by: chunhui dai
Signed-off-by: Bibby Hsieh
Signed-off-by: Ryder Lee
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
changed
v3->v4:
drop display_components which is duplicate of existing mmsys
v2->v3:
drop bls to dpi routing
---
arch/arm/boot/dts/mt7623.dtsi | 170 ++
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 72
arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 72
3 files changed, 314 insertions(+)
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index a106c0d90a52..f2cb44a69454 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -24,6 +24,11 @@ / {
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ rdma0 =
+ rdma1 =
+ };
+
cpu_opp_table: opp-table {
compatible = "operating-points-v2";
opp-shared;
@@ -321,6 +326,25 @@ pwrap: pwrap@1000d000 {
clock-names = "spi", "wrap";
};
+ mipi_tx0: mipi-dphy@1001 {
+ compatible = "mediatek,mt7623-mipi-tx",
+"mediatek,mt2701-mipi-tx";
+ reg = <0 0x1001 0 0x90>;
+ clocks = <>;
+ clock-output-names = "mipi_tx0_pll";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
+
+ cec: cec@10012000 {
+ compatible = "mediatek,mt7623-cec",
+"mediatek,mt8173-cec";
+ reg = <0 0x10012000 0 0xbc>;
+ interrupts = ;
+ clocks = < CLK_INFRA_CEC>;
+ status = "disabled";
+ };
+
cir: cir@10013000 {
compatible = "mediatek,mt7623-cir";
reg = <0 0x10013000 0 0x1000>;
@@ -369,6 +393,18 @@ apmixedsys: syscon@10209000 {
#clock-cells = <1>;
};
+ hdmi_phy: phy@10209100 {
+ compatible = "mediatek,mt7623-hdmi-phy",
+"mediatek,mt2701-hdmi-phy";
+ reg = <0 0x10209100 0 0x24>;
+ clocks = < CLK_APMIXED_HDMI_REF>;
+ clock-names = "pll_ref";
+ clock-output-names = "hdmitx_dig_cts";
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
rng: rng@1020f000 {
compatible = "mediatek,mt7623-rng";
reg = <0 0x1020f000 0 0x1000>;
@@ -568,6 +604,16 @@ bch: ecc@1100e000 {
status = "disabled";
};
+ hdmiddc0: i2c@11013000 {
+ compatible = "mediatek,mt7623-hdmi-ddc",
+"mediatek,mt8173-hdmi-ddc";
+ interrupts = ;
+ reg = <0 0x11013000 0 0x1C>;
+ clocks = < CLK_PERI_I2C3>;
+ clock-names = "ddc-i2c";
+ status = "disabled";
+ };
+
nor_flash: spi@11014000 {
compatible = "mediatek,mt7623-nor",
"mediatek,mt8173-nor";
@@ -766,6 +812,77 @@ mmsys: syscon@1400 {
#clock-cells = <1>;
};
+ ovl@14007000 {
+ compatible = "mediatek,mt7623-disp-ovl",
+"mediatek,mt2701-disp-ovl";
+ reg = <0 0x14007000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_MM_DISP_OVL>;
+ iommus = < MT2701_M4U_PORT_DISP_OVL_0>;
+ mediatek,larb = <>;
+ };
+
+ rdma0: rdma@14008000 {
+ compatible = "mediatek,mt7623-disp-rdma",
+"mediatek,mt2701-disp-rdma";
+ reg = <0 0x14008000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_MM_DISP_RDMA>;
+ iommus = < MT2701_M4U_PORT_DISP_RDMA>;
+ mediatek,larb = <>;
+ };
+
+ wdma@14009000 {
+ compatible = "mediatek,mt7623-disp-wdma",
+"mediatek,mt2701-disp-wdma";
+ reg = <0 0x14009000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_MM_DISP_WDMA>;
+ iommus = < MT2701_M4U_PORT_DISP_WDMA>;
+ mediatek,larb = <>;
+ };
+
+ bls: pwm@1400a000 {
+ compatible = "mediatek,mt7623-disp-pwm",
+"mediatek,mt2701-disp-pwm";
+ reg = <0 0x1400a000 0 0x1000>;
+ #pwm-cells = <2>;
+ clocks = < CLK_MM_MDP_BLS_26M>,
+< CLK_MM_DISP_BLS>;
+ clock-names = "main", "mm";
+ status = "disabled";
+ };
+
+ color@1400b000 {
+ compatible = "mediatek,mt7623-disp-color",
+"mediatek,mt2701-disp-color";
+ reg = <0
Re: Aw: Re: [PATCH v4 6/6] arm: dts: mt7623: add display subsystem related device nodes
On Tue, 2020-08-04 at 19:40 +0200, Frank Wunderlich wrote:
> > Gesendet: Dienstag, 04. August 2020 um 19:24 Uhr
> > Von: "David Woodhouse"
> > > + mipi_tx0: mipi-dphy@1001 {
> > > + compatible = "mediatek,mt7623-mipi-tx",
> > > + "mediatek,mt2701-mipi-tx";
> > > + reg = <0 0x1001 0 0x90>;
> > > + clocks = <>;
> > > + clock-output-names = "mipi_tx0_pll";
> > > + #clock-cells = <0>;
> > > + #phy-cells = <0>;
> > > + };
> >
> > Doesn't this (and some others) also need status="disabled" since
> > they're not present on MT7623A? Or maybe it's time to split
> > mt7623.dtsi
> > into a mt7623n.dtsi which includes mt7623a.dtsi and adds the extra
> > components?
>
> do you have a MT7623A board for testing? is there any list which
> components are existing on mt7623a? or should i disable all of them
> and re-enable them in bpi-r2 dts?
The UniElec U7623 board (which is supported in OpenWrt) is MT7623A.
I was told that MT7623N has GPU and HDMI, while the MT7623A has a
built-in mt7530 switch. Does that imply the switch on the MT7623N
boards is *external*?
If so, that means that mt7623n.dtsi maybe shouldn't just include
mt7623a.dtsi because it's not a strict superset; maybe they should both
include a common mt7623.dtsi that has the parts that are truly common?
I also suspect the switch definition from the UniElec U7623 dts should
probably move to this new mt7623a.dtsi? That's not upstream yet though.
smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 6/6] arm: dts: mt7623: add display subsystem related device nodes
On Tue, 2020-08-04 at 18:55 +0200, Frank Wunderlich wrote:
> From: Ryder Lee
>
> Add display subsystem related device nodes for MT7623.
>
> Cc: CK Hu
> Signed-off-by: chunhui dai
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Ryder Lee
> Signed-off-by: Frank Wunderlich
> Tested-by: Frank Wunderlich
> ---
> changed
> v3->v4:
> drop display_components which is duplicate of existing mmsys
> v2->v3:
> drop bls to dpi routing
> ---
> arch/arm/boot/dts/mt7623.dtsi | 170 ++
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 72
> arch/arm/boot/dts/mt7623n-rfb-emmc.dts| 72
> 3 files changed, 314 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> index a106c0d90a52..f2cb44a69454 100644
> --- a/arch/arm/boot/dts/mt7623.dtsi
> +++ b/arch/arm/boot/dts/mt7623.dtsi
> @@ -24,6 +24,11 @@ / {
> #address-cells = <2>;
> #size-cells = <2>;
>
> + aliases {
> + rdma0 =
> + rdma1 =
> + };
> +
> cpu_opp_table: opp-table {
> compatible = "operating-points-v2";
> opp-shared;
> @@ -321,6 +326,25 @@ pwrap: pwrap@1000d000 {
> clock-names = "spi", "wrap";
> };
>
> + mipi_tx0: mipi-dphy@1001 {
> + compatible = "mediatek,mt7623-mipi-tx",
> + "mediatek,mt2701-mipi-tx";
> + reg = <0 0x1001 0 0x90>;
> + clocks = <>;
> + clock-output-names = "mipi_tx0_pll";
> + #clock-cells = <0>;
> + #phy-cells = <0>;
> + };
Doesn't this (and some others) also need status="disabled" since
they're not present on MT7623A? Or maybe it's time to split mt7623.dtsi
into a mt7623n.dtsi which includes mt7623a.dtsi and adds the extra
components?
smime.p7s
Description: S/MIME cryptographic signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
