Aw: Re: [PATCH v4 6/6] arm: dts: mt7623: add display subsystem related device nodes

[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" <dwmw2 at infradead.org>
> > > +	mipi_tx0: mipi-dphy at 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>;
> > > +	};
> > 
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5174 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20200804/78bd4a9d/attachment.bin>