| Message ID | 20200807082754.6790-2-linux@fw-web.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] arm: dts: mt7623: move more display-related nodes to mt7623n.dtsi | expand |
Hi, as i made a mistake in cover-letter, it is not assigned to the series. to show its content, i send it here as comment (instead of resending the whole series): based on series from David Woodhouse [1] i moved more display-nodes out of mt7623.dtsi to new mt7623n.dtsi and changed last part from my series [2] to add these nodes to this new dtsi the depency of dtsi-dtsi-dts is already done for mt7623a, so i guess it's a good way to use it for mt7623n too. this first set is an RFC if all nodes are in right order and if it is wanted to move them out as i have no technical document about mt7623a/n which describes which parts are available on both or only on one of them added MTK DRM Maintainer CK Hu, Ryder Lee and Sean Wang, maybe they can give me some advice how to proceed further here [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=329209 [2] https://patchwork.kernel.org/patch/11700699/
Hi, Frank: Frank Wunderlich <frank-w@public-files.de> 於 2020年8月8日 週六 下午8:27寫道： > > Hi, > > as i made a mistake in cover-letter, it is not assigned to the series. > > to show its content, i send it here as comment (instead of resending the whole series): > > based on series from David Woodhouse [1] > i moved more display-nodes out of mt7623.dtsi to new mt7623n.dtsi > and changed last part from my series [2] to add these nodes to this new dtsi > > the depency of dtsi-dtsi-dts is already done for mt7623a, so i guess it's a good > way to use it for mt7623n too. > > this first set is an RFC if all nodes are in right order and if it is wanted to move > them out as i have no technical document about mt7623a/n which describes which parts > are available on both or only on one of them > > added MTK DRM Maintainer CK Hu, Ryder Lee and Sean Wang, maybe they can give me some advice > how to proceed further here > > [1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=329209 > [2] https://patchwork.kernel.org/patch/11700699/ I would like to put all device in mt7623.dtsi with some device's status is "disabled" and change its status in platform dtsi. I would like to see all device in mt7623.dtsi because of its name. If you move some device to platform dtsi, we would trace all platform dtsi to find out how many device in mt7623. One day a new platform enable different devices, you would reorganize all these platform dtsi? Regards, Chun-Kuang.
Am 9. August 2020 02:16:59 MESZ schrieb Chun-Kuang Hu <chunkuang.hu@kernel.org>: > >I would like to put all device in mt7623.dtsi with some device's >status is "disabled" and change its status in platform dtsi. >I would like to see all device in mt7623.dtsi because of its name. If >you move some device to platform dtsi, we would trace all platform >dtsi to find out how many device in mt7623. One day a new platform >enable different devices, you would reorganize all these platform >dtsi? Ok,then i change the dts-patch from hdmi-series to disable all nodes and enabling them in bpi-r2 dts. Do they need to be in alphabetical order (or any other)? Is the tmds Patch ok? (because review missing) https://patchwork.kernel.org/patch/11700679/ Just to know before reposting series as v5 :) regards Frank
Hi, Frank: Frank Wunderlich <frank-w@public-files.de> 於 2020年8月9日 週日 下午3:22寫道： > > > > Am 9. August 2020 02:16:59 MESZ schrieb Chun-Kuang Hu <chunkuang.hu@kernel.org>: > > > >I would like to put all device in mt7623.dtsi with some device's > >status is "disabled" and change its status in platform dtsi. > >I would like to see all device in mt7623.dtsi because of its name. If > >you move some device to platform dtsi, we would trace all platform > >dtsi to find out how many device in mt7623. One day a new platform > >enable different devices, you would reorganize all these platform > >dtsi? > > Ok,then i change the dts-patch from hdmi-series to disable all nodes and enabling them in bpi-r2 dts. Do they need to be in alphabetical order (or any other)? Alphabetical order is better. > > Is the tmds Patch ok? (because review missing) https://patchwork.kernel.org/patch/11700679/ That patch looks really like a hack patch. I would wait for a long time to see whether any one has comment for this. Or you could have a better explain for it. I could apply other patches first. Regards, Chun-Kuang. > > Just to know before reposting series as v5 :) > regards Frank
Am 10. August 2020 02:06:27 MESZ schrieb Chun-Kuang Hu <chunkuang.hu@kernel.org>: >Alphabetical order is better. In dts there is alphabetical order but not yet in dtsi...i try to fix this. >> Is the tmds Patch ok? (because review missing) >https://patchwork.kernel.org/patch/11700679/ > >That patch looks really like a hack patch. I would wait for a long >time to see whether any one has comment for this. Or you could have a >better explain for it. As i have documentation for mt7623 and there were no further comments on old series (https://patchwork.kernel.org/patch/10903303/) i guess i cannot fix this. I only know it is needed to get clear image on my 1280x1024 display with this Patch I adressed Ryder and Bibby directly maybe they can help here >I could apply other patches first. I guess i need to fix order in dtsi first...afair any hdmi node creates an serial device moved the others +1. So maybe nodes need to be added after uartx (or at least the one if i found out which). regards Frank
On Sun, 2020-08-09 at 08:16 +0800, Chun-Kuang Hu wrote: > I would like to put all device in mt7623.dtsi with some device's > status is "disabled" and change its status in platform dtsi. > I would like to see all device in mt7623.dtsi because of its name. If > you move some device to platform dtsi, we would trace all platform > dtsi to find out how many device in mt7623. One day a new platform > enable different devices, you would reorganize all these platform > dtsi? No, this isn't "platform dtsi", surely? This is mt7623a and mt7623n dtsi for the two different SoCs, and platforms then just include mt7623a.dtsi or mt7623n.dtsi as appropriate for the SoC they are using. If you really want *all* the nodes for both MT7623A and MT7623N chips in a single mt7623.dtsi but disabled, could we still have mt7623a.dtsi and mt7623n.dtsi for the chips, enabling the nodes that are only-for-A or only-for-N, so that each platform doesn't have to do that for itself? Although putting those nodes that exist only in one chip or the other directly into the mt7623[an].dtsi still seems to make more sense to me.
Hi, David: David Woodhouse <dwmw2@infradead.org> 於 2020年8月10日 週一 下午3:48寫道： > > On Sun, 2020-08-09 at 08:16 +0800, Chun-Kuang Hu wrote: > > I would like to put all device in mt7623.dtsi with some device's > > status is "disabled" and change its status in platform dtsi. > > I would like to see all device in mt7623.dtsi because of its name. If > > you move some device to platform dtsi, we would trace all platform > > dtsi to find out how many device in mt7623. One day a new platform > > enable different devices, you would reorganize all these platform > > dtsi? > > No, this isn't "platform dtsi", surely? This is mt7623a and mt7623n > dtsi for the two different SoCs, and platforms then just include > mt7623a.dtsi or mt7623n.dtsi as appropriate for the SoC they are using. > > If you really want *all* the nodes for both MT7623A and MT7623N chips > in a single mt7623.dtsi but disabled, could we still have mt7623a.dtsi > and mt7623n.dtsi for the chips, enabling the nodes that are only-for-A > or only-for-N, so that each platform doesn't have to do that for > itself? > > Although putting those nodes that exist only in one chip or the other > directly into the mt7623[an].dtsi still seems to make more sense to > me. Sorry I does not notice that mt7623a and mt7623n are different SoC. Because they are different SoC, I think the first step is to upstream mt7623a.dtsi and mt7623n.dtsi independently. That means in each dtsi, it include all devices of its SoC. After both dtsi is upsteamed, we could find out what is the common part, then we create a common dtsi these two SoC, for example mt7623a_mt7623n_common.dtsi. (Maybe there is a SoC's name is exactly 'mt7623', so I prefer mt7623.dtsi is reserved for that SoC, and mt7623_common.dtsi is not preferred because I don't know there are how many mt7623 family SoC and mt7623_common.dtsi should be use for all mt7623 family) Regards, Chun-Kuang.
Hi Am 11. August 2020 01:28:25 MESZ schrieb Chun-Kuang Hu <chunkuang.hu@kernel.org>: >Sorry I does not notice that mt7623a and mt7623n are different SoC. >Because they are different SoC, I think the first step is to upstream >mt7623a.dtsi and mt7623n.dtsi independently. That means in each dtsi, >it include all devices of its SoC. After both dtsi is upsteamed, we >could find out what is the common part, then we create a common dtsi >these two SoC, for example mt7623a_mt7623n_common.dtsi. (Maybe there >is a SoC's name is exactly 'mt7623', so I prefer mt7623.dtsi is >reserved for that SoC, and mt7623_common.dtsi is not preferred because >I don't know there are how many mt7623 family SoC and >mt7623_common.dtsi should be use for all mt7623 family) Afair there is only mt7623a and mt7623n. Mt7623a uses mt7623.dtsi as common part. These 2 soc are released 5 years ago...and only these 2 from that family). https://www.mediatek.com/news-events/press-releases/mediatek-launches-the-mt7623-and-mt7683-multi-standard-iot-gateways-with-high-speed-wlan-to-lan-to-drive-the-secure-smart-home So from my current pov the best way (to no more delay my hdmi series) is to move display related stuff in new mt7623n.dtsi and keep mt7623.dtsi as common. So we can avoid touching mt7623a.dtsi for now (can be done later if really needed). regards Frank
On Tue, 2020-08-11 at 10:41 +0200, Frank Wunderlich wrote: > Afair there is only mt7623a and mt7623n. Mt7623a uses mt7623.dtsi as > common part. These 2 soc are released 5 years ago...and only these 2 > from that family). > > https://www.mediatek.com/news-events/press-releases/mediatek-launches-the-mt7623-and-mt7683-multi-standard-iot-gateways-with-high-speed-wlan-to-lan-to-drive-the-secure-smart-home > > So from my current pov the best way (to no more delay my hdmi series) > is to move display related stuff in new mt7623n.dtsi and keep > mt7623.dtsi as common. So we can avoid touching mt7623a.dtsi for now > (can be done later if really needed). Agreed. I see all three (now I added U7623) MT7623A platforms add the built-in Ethernet switch for themselves, so I'll probably move that to mt7623a.dtsi on top of the series that we're already using. But that can come later.
Hi, i rebased changes to 5.9-rc1 [1] and include parts from Davids Series in my one. David: is it ok to squash your mali-commit with mine moving the other display-related nodes and use me as author? CK Hu/Matthias/Ryder/Sean: is the structure of DTS ok now? regards Frank [1] https://github.com/frank-w/BPI-R2-4.14/commits/5.9-hdmi > Gesendet: Montag, 10. August 2020 um 09:48 Uhr > Von: "David Woodhouse" <dwmw2@infradead.org> > Betreff: Re: [PATCH 1/2] arm: dts: mt7623: move more display-related nodes to mt7623n.dtsi > > On Sun, 2020-08-09 at 08:16 +0800, Chun-Kuang Hu wrote: > > I would like to put all device in mt7623.dtsi with some device's > > status is "disabled" and change its status in platform dtsi. > > I would like to see all device in mt7623.dtsi because of its name. If > > you move some device to platform dtsi, we would trace all platform > > dtsi to find out how many device in mt7623. One day a new platform > > enable different devices, you would reorganize all these platform > > dtsi? > > No, this isn't "platform dtsi", surely? This is mt7623a and mt7623n > dtsi for the two different SoCs, and platforms then just include > mt7623a.dtsi or mt7623n.dtsi as appropriate for the SoC they are using. > > If you really want *all* the nodes for both MT7623A and MT7623N chips > in a single mt7623.dtsi but disabled, could we still have mt7623a.dtsi > and mt7623n.dtsi for the chips, enabling the nodes that are only-for-A > or only-for-N, so that each platform doesn't have to do that for > itself? > > Although putting those nodes that exist only in one chip or the other > directly into the mt7623[an].dtsi still seems to make more sense to > me.
On 18 August 2020 08:16:27 BST, Frank Wunderlich <frank-w@public-files.de> wrote: >Hi, > >i rebased changes to 5.9-rc1 [1] and include parts from Davids Series >in my one. > >David: is it ok to squash your mali-commit with mine moving the other >display-related nodes and use me as author? Absolutely. Can the U7623 patch go along for the ride too? Was there anything else you weren't including?
> Gesendet: Dienstag, 18. August 2020 um 09:36 Uhr > Von: "David Woodhouse" <dwmw2@infradead.org> > >David: is it ok to squash your mali-commit with mine moving the other > >display-related nodes and use me as author? > > Absolutely. Can the U7623 patch go along for the ride too? Was there anything else you weren't including? i did not included the mt7623a-patches because they are not related to my hdmi-series ;) but it should be easy to add them on top/separately regards Frank
diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi index d94f24eb7f43..d09b5671c91b 100644 --- a/arch/arm/boot/dts/mt7623.dtsi +++ b/arch/arm/boot/dts/mt7623.dtsi @@ -14,7 +14,6 @@ #include <dt-bindings/power/mt2701-power.h> #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/phy/phy.h> -#include <dt-bindings/memory/mt2701-larb-port.h> #include <dt-bindings/reset/mt2701-resets.h> #include <dt-bindings/thermal/thermal.h> @@ -297,17 +296,6 @@ timer: timer@10008000 { clock-names = "system-clk", "rtc-clk"; }; - smi_common: smi@1000c000 { - compatible = "mediatek,mt7623-smi-common", - "mediatek,mt2701-smi-common"; - reg = <0 0x1000c000 0 0x1000>; - clocks = <&infracfg CLK_INFRA_SMI>, - <&mmsys CLK_MM_SMI_COMMON>, - <&infracfg CLK_INFRA_SMI>; - clock-names = "apb", "smi", "async"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>; - }; - pwrap: pwrap@1000d000 { compatible = "mediatek,mt7623-pwrap", "mediatek,mt2701-pwrap"; @@ -339,17 +327,6 @@ sysirq: interrupt-controller@10200100 { reg = <0 0x10200100 0 0x1c>; }; - iommu: mmsys_iommu@10205000 { - compatible = "mediatek,mt7623-m4u", - "mediatek,mt2701-m4u"; - reg = <0 0x10205000 0 0x1000>; - interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>; - clocks = <&infracfg CLK_INFRA_M4U>; - clock-names = "bclk"; - mediatek,larbs = <&larb0 &larb1 &larb2>; - #iommu-cells = <1>; - }; - efuse: efuse@10206000 { compatible = "mediatek,mt7623-efuse", "mediatek,mt8173-efuse"; @@ -725,70 +702,6 @@ mmc0: mmc@11230000 { status = "disabled"; }; - g3dsys: syscon@13000000 { - compatible = "mediatek,mt7623-g3dsys", - "mediatek,mt2701-g3dsys", - "syscon"; - reg = <0 0x13000000 0 0x200>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - mmsys: syscon@14000000 { - compatible = "mediatek,mt7623-mmsys", - "mediatek,mt2701-mmsys", - "syscon"; - reg = <0 0x14000000 0 0x1000>; - #clock-cells = <1>; - }; - - larb0: larb@14010000 { - compatible = "mediatek,mt7623-smi-larb", - "mediatek,mt2701-smi-larb"; - reg = <0 0x14010000 0 0x1000>; - mediatek,smi = <&smi_common>; - mediatek,larb-id = <0>; - clocks = <&mmsys CLK_MM_SMI_LARB0>, - <&mmsys CLK_MM_SMI_LARB0>; - clock-names = "apb", "smi"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>; - }; - - imgsys: syscon@15000000 { - compatible = "mediatek,mt7623-imgsys", - "mediatek,mt2701-imgsys", - "syscon"; - reg = <0 0x15000000 0 0x1000>; - #clock-cells = <1>; - }; - - larb2: larb@15001000 { - compatible = "mediatek,mt7623-smi-larb", - "mediatek,mt2701-smi-larb"; - reg = <0 0x15001000 0 0x1000>; - mediatek,smi = <&smi_common>; - mediatek,larb-id = <2>; - clocks = <&imgsys CLK_IMG_SMI_COMM>, - <&imgsys CLK_IMG_SMI_COMM>; - clock-names = "apb", "smi"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; - }; - - jpegdec: jpegdec@15004000 { - compatible = "mediatek,mt7623-jpgdec", - "mediatek,mt2701-jpgdec"; - reg = <0 0x15004000 0 0x1000>; - interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_LOW>; - clocks = <&imgsys CLK_IMG_JPGDEC_SMI>, - <&imgsys CLK_IMG_JPGDEC>; - clock-names = "jpgdec-smi", - "jpgdec"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; - mediatek,larb = <&larb2>; - iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>, - <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>; - }; - vdecsys: syscon@16000000 { compatible = "mediatek,mt7623-vdecsys", "mediatek,mt2701-vdecsys", @@ -797,18 +710,6 @@ vdecsys: syscon@16000000 { #clock-cells = <1>; }; - larb1: larb@16010000 { - compatible = "mediatek,mt7623-smi-larb", - "mediatek,mt2701-smi-larb"; - reg = <0 0x16010000 0 0x1000>; - mediatek,smi = <&smi_common>; - mediatek,larb-id = <1>; - clocks = <&vdecsys CLK_VDEC_CKGEN>, - <&vdecsys CLK_VDEC_LARB>; - clock-names = "apb", "smi"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>; - }; - hifsys: syscon@1a000000 { compatible = "mediatek,mt7623-hifsys", "mediatek,mt2701-hifsys", diff --git a/arch/arm/boot/dts/mt7623n.dtsi b/arch/arm/boot/dts/mt7623n.dtsi index 7724a4d05b89..a47e82468895 100644 --- a/arch/arm/boot/dts/mt7623n.dtsi +++ b/arch/arm/boot/dts/mt7623n.dtsi @@ -7,8 +7,18 @@ */ #include "mt7623.dtsi" +#include <dt-bindings/memory/mt2701-larb-port.h> / { + g3dsys: syscon@13000000 { + compatible = "mediatek,mt7623-g3dsys", + "mediatek,mt2701-g3dsys", + "syscon"; + reg = <0 0x13000000 0 0x200>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + mali: gpu@13040000 { compatible = "mediatek,mt7623-mali", "arm,mali-450"; reg = <0 0x13040000 0 0x30000>; @@ -32,4 +42,93 @@ mali: gpu@13040000 { power-domains = <&scpsys MT2701_POWER_DOMAIN_MFG>; resets = <&g3dsys MT2701_G3DSYS_CORE_RST>; }; + + mmsys: syscon@14000000 { + compatible = "mediatek,mt7623-mmsys", + "mediatek,mt2701-mmsys", + "syscon"; + reg = <0 0x14000000 0 0x1000>; + #clock-cells = <1>; + }; + + larb0: larb@14010000 { + compatible = "mediatek,mt7623-smi-larb", + "mediatek,mt2701-smi-larb"; + reg = <0 0x14010000 0 0x1000>; + mediatek,smi = <&smi_common>; + mediatek,larb-id = <0>; + clocks = <&mmsys CLK_MM_SMI_LARB0>, + <&mmsys CLK_MM_SMI_LARB0>; + clock-names = "apb", "smi"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>; + }; + + larb1: larb@16010000 { + compatible = "mediatek,mt7623-smi-larb", + "mediatek,mt2701-smi-larb"; + reg = <0 0x16010000 0 0x1000>; + mediatek,smi = <&smi_common>; + mediatek,larb-id = <1>; + clocks = <&vdecsys CLK_VDEC_CKGEN>, + <&vdecsys CLK_VDEC_LARB>; + clock-names = "apb", "smi"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>; + }; + + larb2: larb@15001000 { + compatible = "mediatek,mt7623-smi-larb", + "mediatek,mt2701-smi-larb"; + reg = <0 0x15001000 0 0x1000>; + mediatek,smi = <&smi_common>; + mediatek,larb-id = <2>; + clocks = <&imgsys CLK_IMG_SMI_COMM>, + <&imgsys CLK_IMG_SMI_COMM>; + clock-names = "apb", "smi"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; + }; + + imgsys: syscon@15000000 { + compatible = "mediatek,mt7623-imgsys", + "mediatek,mt2701-imgsys", + "syscon"; + reg = <0 0x15000000 0 0x1000>; + #clock-cells = <1>; + }; + + iommu: mmsys_iommu@10205000 { + compatible = "mediatek,mt7623-m4u", + "mediatek,mt2701-m4u"; + reg = <0 0x10205000 0 0x1000>; + interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>; + clocks = <&infracfg CLK_INFRA_M4U>; + clock-names = "bclk"; + mediatek,larbs = <&larb0 &larb1 &larb2>; + #iommu-cells = <1>; + }; + + jpegdec: jpegdec@15004000 { + compatible = "mediatek,mt7623-jpgdec", + "mediatek,mt2701-jpgdec"; + reg = <0 0x15004000 0 0x1000>; + interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_LOW>; + clocks = <&imgsys CLK_IMG_JPGDEC_SMI>, + <&imgsys CLK_IMG_JPGDEC>; + clock-names = "jpgdec-smi", + "jpgdec"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; + mediatek,larb = <&larb2>; + iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>, + <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>; + }; + + smi_common: smi@1000c000 { + compatible = "mediatek,mt7623-smi-common", + "mediatek,mt2701-smi-common"; + reg = <0 0x1000c000 0 0x1000>; + clocks = <&infracfg CLK_INFRA_SMI>, + <&mmsys CLK_MM_SMI_COMMON>, + <&infracfg CLK_INFRA_SMI>; + clock-names = "apb", "smi", "async"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>; + }; };