On Wed, 2018-09-26 at 10:50 +0200, Matthias Brugger wrote: > > On 26/09/2018 07:21, CK Hu wrote: > > Hi, Ryder: > > > > On Wed, 2018-09-26 at 10:38 +0800, Ryder Lee wrote: > >> On Wed, 2018-09-26 at 09:37 +0800, CK Hu wrote: > >>> Hi, Ryder: > >>> > >>> On Wed, 2018-09-05 at 22:09 +0800, Ryder Lee wrote: > >>>> Add display subsystem related device nodes for MT7623. > >>>> > >>>> Cc: CK Hu <ck.hu@xxxxxxxxxxxx> > >>>> Signed-off-by: chunhui dai <chunhui.dai@xxxxxxxxxxxx> > >>>> Signed-off-by: Bibby Hsieh <bibby.hsieh@xxxxxxxxxxxx> > >>>> Signed-off-by: Ryder Lee <ryder.lee@xxxxxxxxxxxx> > >>>> --- > >>>> I forgot to sort nodes in my previous mail. Sorry for the inconvenience. > >>>> > >>>> This patch depends on the series: https://lkml.org/lkml/2018/9/5/223 > >>>> > >>>> @Matthias, > >>>> I know you're working on broken MMSYS - just want to ask whether it's possible > >>>> to let the patch to go to your tree (if others are okay with it), and send a > >>>> fixup one for MT7623 MMSYS later? > >>>> --- > >>>> arch/arm/boot/dts/mt7623.dtsi | 177 ++++++++++++++++++++++++++ > >>>> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 83 ++++++++++++ > >>>> arch/arm/boot/dts/mt7623n-rfb-emmc.dts | 83 ++++++++++++ > >>>> 3 files changed, 343 insertions(+) > >>>> > >>>> diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi > >>>> index d01bdee..fdf9078 100644 > >>>> --- a/arch/arm/boot/dts/mt7623.dtsi > >>>> +++ b/arch/arm/boot/dts/mt7623.dtsi > >>>> @@ -23,6 +23,11 @@ > >>>> #address-cells = <2>; > >>>> #size-cells = <2>; > >>>> > >>>> + aliases { > >>>> + rdma0 = &rdma0; > >>>> + rdma1 = &rdma1; > >>>> + }; > >>>> + > >>>> cpu_opp_table: opp-table { > >>>> compatible = "operating-points-v2"; > >>>> opp-shared; > >>>> @@ -311,6 +316,25 @@ > >>>> clock-names = "spi", "wrap"; > >>>> }; > >>>> > >>>> + mipi_tx0: mipi-dphy@10010000 { > >>>> + compatible = "mediatek,mt7623-mipi-tx", > >>>> + "mediatek,mt2701-mipi-tx"; > >>>> + reg = <0 0x10010000 0 0x90>; > >>>> + clocks = <&clk26m>; > >>>> + 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 = <GIC_SPI 182 IRQ_TYPE_LEVEL_LOW>; > >>>> + clocks = <&infracfg CLK_INFRA_CEC>; > >>>> + status = "disabled"; > >>>> + }; > >>>> + > >>>> cir: cir@10013000 { > >>>> compatible = "mediatek,mt7623-cir"; > >>>> reg = <0 0x10013000 0 0x1000>; > >>>> @@ -359,6 +383,18 @@ > >>>> #clock-cells = <1>; > >>>> }; > >>>> > >>>> + hdmi_phy: phy@10209100 { > >>>> + compatible = "mediatek,mt7623-hdmi-phy", > >>>> + "mediatek,mt2701-hdmi-phy"; > >>>> + reg = <0 0x10209100 0 0x24>; > >>>> + clocks = <&apmixedsys 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>; > >>>> @@ -558,6 +594,16 @@ > >>>> status = "disabled"; > >>>> }; > >>>> > >>>> + hdmiddc0: i2c@11013000 { > >>>> + compatible = "mediatek,mt7623-hdmi-ddc", > >>>> + "mediatek,mt8173-hdmi-ddc"; > >>>> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>; > >>>> + reg = <0 0x11013000 0 0x1C>; > >>>> + clocks = <&pericfg CLK_PERI_I2C3>; > >>>> + clock-names = "ddc-i2c"; > >>>> + status = "disabled"; > >>>> + }; > >>>> + > >>>> nor_flash: spi@11014000 { > >>>> compatible = "mediatek,mt7623-nor", > >>>> "mediatek,mt8173-nor"; > >>>> @@ -732,6 +778,84 @@ > >>>> #clock-cells = <1>; > >>>> }; > >>>> > >>>> + display_components: dispsys@14000000 { > >>>> + compatible = "mediatek,mt7623-mmsys", > >>> > >>> Checkpatch warning: > >>> > >>> WARNING: DT compatible string "mediatek,mt7623-mmsys" appears > >>> un-documented -- check ./Documentation/devicetree/bindings/ > >>> #101: FILE: arch/arm/boot/dts/mt7623.dtsi:782: > >>> + compatible = "mediatek,mt7623-mmsys", > >>> > >>> > >>>> + "mediatek,mt2701-mmsys"; > >>>> + reg = <0 0x14000000 0 0x1000>; > >>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>; > >>>> + }; > >>>> + > >>>> + ovl@14007000 { > >>>> + compatible = "mediatek,mt7623-disp-ovl", > >>> > >>> I think this is also un-documented, but I don't know why checkpatch does > >>> not show any warning. > >>> > >>> Regards, > >>> CK > >>>> + "mediatek,mt2701-disp-ovl"; > >>>> + reg = <0 0x14007000 0 0x1000>; > >>>> + interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_LOW>; > >>>> + clocks = <&mmsys CLK_MM_DISP_OVL>; > >>>> + iommus = <&iommu MT2701_M4U_PORT_DISP_OVL_0>; > >>>> + mediatek,larb = <&larb0>; > >>>> + }; > >>>> + > >> > >> I fallback to use the MT2701's compatible string here and there, but I > >> could add a new one for MT7623. > >> > >> BTW, I've had this question for a long time - should I add a new > >> compatible for the very same IPs, or could we just use the old one in > >> DTS? > >> > >> Ryder > >> > > > > From [1], there is a description for the multiple compatible string > > scheme: > > > > ==== > > The reasoning behind this scheme is the observation that in the majority > > of cases, a single machine_desc can support a large number of boards > > if they all use the same SoC, or same family of SoCs. However, > > invariably there will be some exceptions where a specific board will > > require special setup code that is not useful in the generic case. > > Special cases could be handled by explicitly checking for the > > troublesome board(s) in generic setup code, but doing so very quickly > > becomes ugly and/or unmaintainable if it is more than just a couple of > > cases. > > > > Instead, the compatible list allows a generic machine_desc to provide > > support for a wide common set of boards by specifying "less > > compatible" values in the dt_compat list. In the example above, > > generic board support can claim compatibility with "ti,omap3" or > > "ti,omap3450". If a bug was discovered on the original beagleboard > > that required special workaround code during early boot, then a new > > machine_desc could be added which implements the workarounds and only > > matches on "ti,omap3-beagleboard". > > ==== > > > > I don't know would there be a problem happened only in MT7623 even > > though this hardware is identical in both MT2701 and MT7623. Maybe the > > system-wide configuration would influence this driver. So the easy way > > is to add the compatible string for MT7623. If you could prove that > > this driver would never be influenced by system-wide configuration, > > using only MT2701 compatible string is acceptable for me. > > > > This is my opinion, but the most important is maintainer's opinion. > > > > The compatible string looks good. But you should update the binding documentation :) Okay, I will update it. > Regards, > Matthias
