Re: [PATCH] arm64: dts: rockchip: Split rk3399-roc-pc for with and without mezzanine board.

[Jagan Teki]

On Mon, Nov 18, 2019 at 5:31 PM Heiko StÃbner <heiko@xxxxxxxxx> wrote:
>
> Am Montag, 18. November 2019, 12:57:16 CET schrieb Markus Reichl:
> > Hi Jagan,
> >
> > Am 18.11.19 um 12:44 schrieb Jagan Teki:
> > > On Mon, Nov 4, 2019 at 5:42 PM Heiko StÃbner <heiko@xxxxxxxxx> wrote:
> > >>
> > >> Hi Markus,
> > >>
> > >> Am Freitag, 1. November 2019, 17:54:23 CET schrieb Markus Reichl:
> > >> > For rk3399-roc-pc is a mezzanine board available that carries M.2 and
> > >> > POE interfaces. Use it with a separate dts.
> > >> >
> > >> > Signed-off-by: Markus Reichl <m.reichl@xxxxxxxxxxxxx>
> > >> > ---
> > >> >  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
> > >> >  .../boot/dts/rockchip/rk3399-roc-pc-mezz.dts  |  52 ++
> > >> >  .../arm64/boot/dts/rockchip/rk3399-roc-pc.dts | 757 +----------------
> > >> >  .../boot/dts/rockchip/rk3399-roc-pc.dtsi      | 767 ++++++++++++++++++
> > >> >  4 files changed, 821 insertions(+), 756 deletions(-)
> > >> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-roc-pc-mezz.dts
> > >> >  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dtsi
> > >> >
> > >> > diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> > >> > index a959434ad46e..80ee9f1fc5f5 100644
> > >> > --- a/arch/arm64/boot/dts/rockchip/Makefile
> > >> > +++ b/arch/arm64/boot/dts/rockchip/Makefile
> > >> > @@ -28,6 +28,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
> > >> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
> > >> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
> > >> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
> > >> > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc-mezz.dtb
> > >> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4.dtb
> > >> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
> > >> >  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
> > >> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc-mezz.dts b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc-mezz.dts
> > >> > new file mode 100644
> > >> > index 000000000000..ee77677d2cf2
> > >> > --- /dev/null
> > >> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc-mezz.dts
> > >> > @@ -0,0 +1,52 @@
> > >> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > >> > +/*
> > >> > + * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
> > >> > + * Copyright (c) 2019 Markus Reichl <m.reichl@xxxxxxxxxxxxx>
> > >> > + */
> > >> > +
> > >> > +/dts-v1/;
> > >> > +#include "rk3399-roc-pc.dtsi"
> > >> > +
> > >> > +/ {
> > >> > +     model = "Firefly ROC-RK3399-PC Mezzanine Board";
> > >> > +     compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
> > >>
> > >> different board with same compatible isn't possible, so
> > >> you'll need a new compatible for it and add a new line to
> > >> the roc-pc entry in
> > >>         Documentation/devicetree/bindings/arm/rockchip.yaml
> > >>
> > >> Either you see it as
> > >> - a board + hat, using dt overlay and same compatible
> > >> - a completely separate board, which needs a separate
> > >>   compatible as well
> > >>
> > >> And as discussed in the previous thread
> > >> http://lists.infradead.org/pipermail/linux-rockchip/2019-November/027592.html
> > >> but also in Jagan's response that really is somehow a grey area
> > >> for something relatively static as the M.2 extension.
> > >
> > > Sorry for late response on this. I still think that the "overlay would
> > > be a better suite" than having separate dts, since it is HAT which is
> > > optional to insert and have possibility of having another HAT if it
> > > really fit into it.
> > >
> > > Comments?
> > Presently no other extension board does exist, I don't expect one.
> >
> > I use it with rootfs on NVME on the mezzanine board.
> > It is convenient to have the NVME up before going to user space.
>
> And that is exactly the reason while I think it's sane to have this
> as a separate board. For more common hats with random
> extended functionality this might be different.
>
> But people attaching the nvme-"hat" will in most all cases do so quite
> permanently as well ;-) .

I did understand this completely and I do agree this point and use-case.

But what if we have overlay, and give tendency to use it at bootloader
level for nvme-"hat" so it can satisfy both common and random HAT
functionalities.