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

2020-08-06 Thread Frank Wunderlich
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


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

2020-08-05 Thread David Woodhouse
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