mbox series

[0/3] arm64: dts: allwinner: h5: Add device tree for Bananapi M2 Plus H5

Message ID 20180830080926.15027-1-wens@csie.org (mailing list archive)
Headers show
Series arm64: dts: allwinner: h5: Add device tree for Bananapi M2 Plus H5 | expand

Message

Chen-Yu Tsai Aug. 30, 2018, 8:09 a.m. UTC
Hi,

Allwinner's H5 SoC is pin compatible with the H3 SoC. As such, some
vendors produce H3 and H5 variants for the same device. Such is the
case with Libre Computer's ALL-H3-CC, and the Bananapi M2 Plus.

This series follows that of the ALL-H3-CC, splitting out a common
board dtsi, and then two SoC-specific dts files that include the
SoC level and common board dtsi's, as well as putting in the board
name. The first patch is a minor fix that I think should be done
before the migration.

Please have a look.

Also, on a related matter, Bananapi recently released revision v1.2
of the M2 Plus. The original commercially available version was v1.1.
v1.2 adds a GPIO control that can change the CPU cores' supply voltage
between 1.1V and 1.3V. Do we want two extra dts files for this? Put
them in the existing dts files regardless? Or let people handle this
via overlays?

Thanks
ChenYu


Chen-Yu Tsai (3):
  ARM: dts: sun8i: h3: bpi-m2-plus: Fix address for external RGMII
    Ethernet PHY
  ARM: dts: sun8i: h3: Split out non-SoC-specific parts of Bananapi M2
    Plus
  arm64: dts: allwinner: h5: Add device tree for Bananapi M2 Plus H5

 .../boot/dts/sun8i-h3-bananapi-m2-plus.dts    | 190 +-----------------
 ...2-plus.dts => sunxi-bananapi-m2-plus.dtsi} |   7 +-
 arch/arm64/boot/dts/allwinner/Makefile        |   1 +
 .../allwinner/sun50i-h5-bananapi-m2-plus.dts  |  11 +
 4 files changed, 15 insertions(+), 194 deletions(-)
 copy arch/arm/boot/dts/{sun8i-h3-bananapi-m2-plus.dts => sunxi-bananapi-m2-plus.dtsi} (97%)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus.dts

Comments

Maxime Ripard Aug. 31, 2018, 10:17 a.m. UTC | #1
On Thu, Aug 30, 2018 at 04:09:23PM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> Allwinner's H5 SoC is pin compatible with the H3 SoC. As such, some
> vendors produce H3 and H5 variants for the same device. Such is the
> case with Libre Computer's ALL-H3-CC, and the Bananapi M2 Plus.
> 
> This series follows that of the ALL-H3-CC, splitting out a common
> board dtsi, and then two SoC-specific dts files that include the
> SoC level and common board dtsi's, as well as putting in the board
> name. The first patch is a minor fix that I think should be done
> before the migration.
> 
> Please have a look.

Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

> Also, on a related matter, Bananapi recently released revision v1.2
> of the M2 Plus. The original commercially available version was v1.1.
> v1.2 adds a GPIO control that can change the CPU cores' supply voltage
> between 1.1V and 1.3V. Do we want two extra dts files for this? Put
> them in the existing dts files regardless? Or let people handle this
> via overlays?

If that the sole change, I'd be inclined to merge it as a separate DT
for that particular version. Is there any way to detect it at runtime?

Maxime
Chen-Yu Tsai Sept. 3, 2018, 3:05 a.m. UTC | #2
On Fri, Aug 31, 2018 at 6:17 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Thu, Aug 30, 2018 at 04:09:23PM +0800, Chen-Yu Tsai wrote:
> > Hi,
> >
> > Allwinner's H5 SoC is pin compatible with the H3 SoC. As such, some
> > vendors produce H3 and H5 variants for the same device. Such is the
> > case with Libre Computer's ALL-H3-CC, and the Bananapi M2 Plus.
> >
> > This series follows that of the ALL-H3-CC, splitting out a common
> > board dtsi, and then two SoC-specific dts files that include the
> > SoC level and common board dtsi's, as well as putting in the board
> > name. The first patch is a minor fix that I think should be done
> > before the migration.
> >
> > Please have a look.
>
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> > Also, on a related matter, Bananapi recently released revision v1.2
> > of the M2 Plus. The original commercially available version was v1.1.
> > v1.2 adds a GPIO control that can change the CPU cores' supply voltage
> > between 1.1V and 1.3V. Do we want two extra dts files for this? Put
> > them in the existing dts files regardless? Or let people handle this
> > via overlays?
>
> If that the sole change, I'd be inclined to merge it as a separate DT
> for that particular version. Is there any way to detect it at runtime?

It seems there isn't. The pin in both new and old revisions have an
external pull-up with the same value, so it isn't possible to detect
whether the pin is used or not. And there are no other changes between
the two.

ChenYu
Chen-Yu Tsai Sept. 3, 2018, 3:08 a.m. UTC | #3
On Mon, Sep 3, 2018 at 11:05 AM Chen-Yu Tsai <wens@csie.org> wrote:
>
> On Fri, Aug 31, 2018 at 6:17 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Thu, Aug 30, 2018 at 04:09:23PM +0800, Chen-Yu Tsai wrote:
> > > Hi,
> > >
> > > Allwinner's H5 SoC is pin compatible with the H3 SoC. As such, some
> > > vendors produce H3 and H5 variants for the same device. Such is the
> > > case with Libre Computer's ALL-H3-CC, and the Bananapi M2 Plus.
> > >
> > > This series follows that of the ALL-H3-CC, splitting out a common
> > > board dtsi, and then two SoC-specific dts files that include the
> > > SoC level and common board dtsi's, as well as putting in the board
> > > name. The first patch is a minor fix that I think should be done
> > > before the migration.
> > >
> > > Please have a look.
> >
> > Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

Applied.

> > > Also, on a related matter, Bananapi recently released revision v1.2
> > > of the M2 Plus. The original commercially available version was v1.1.
> > > v1.2 adds a GPIO control that can change the CPU cores' supply voltage
> > > between 1.1V and 1.3V. Do we want two extra dts files for this? Put
> > > them in the existing dts files regardless? Or let people handle this
> > > via overlays?
> >
> > If that the sole change, I'd be inclined to merge it as a separate DT
> > for that particular version. Is there any way to detect it at runtime?
>
> It seems there isn't. The pin in both new and old revisions have an
> external pull-up with the same value, so it isn't possible to detect
> whether the pin is used or not. And there are no other changes between
> the two.
>
> ChenYu