Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree

From: Arnd Bergmann <arnd@kernel.org>
To: "Hector Martin 'marcan'" <marcan@marcan.st>
Cc: DTML <devicetree@vger.kernel.org>, Marc Zyngier <maz@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	SoC Team <soc@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Olof Johansson <olof@lixom.net>, Ard Biesheuvel <ardb@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree
Date: Fri, 5 Feb 2021 00:08:07 +0100	[thread overview]
Message-ID: <CAK8P3a2DawQA-PD5aqbkVPB7UxuohN0oe9mJPe8488pUryotJQ@mail.gmail.com> (raw)
In-Reply-To: <de236d0c-579d-c0d9-8d60-77f30889f50c@marcan.st>

On Thu, Feb 4, 2021 at 10:44 PM Hector Martin 'marcan' <marcan@marcan.st> wrote:
> On 05/02/2021 06.29, Arnd Bergmann wrote:
> > On Thu, Feb 4, 2021 at 9:39 PM Hector Martin <marcan@marcan.st> wrote:
> >
> > We tend to split the dts file into one file per SoC and one for the
> > specific board. I guess in this case the split can be slightly different,
> > but it does feel better to be prepared for sharing a lot of the contents
> > between the different products.
> >
> > In most cases, you'd want the 'aliases' and 'chosen' nodes to be
> > in the board specific file.
>
> I thought about that, but wasn't sure if splitting it up at this early
> stage made much sense since I'm not sure what the split should be, given
> all supported hardware is the same for all 3 released devices.
>
> I'm happy to throw the aliases/chosen nodes into board specific files if
> you think that's a good starting point. Perhaps /memory too? Those
> properties are filled in/patched by the bootloader anyway...

Yes, I think that would help make it more consistent with other
platforms even if we don't care too much here.

> There are also DT overlays; I was wondering if we could use those to
> keep the hierarchy and avoid having many duplicate trees in a
> hypothetical bootloader that embeds support for a large set of hardware,
> having it construct the final devicetree on the fly from SoC + a board
> overlay (and possibly further levels); but I'm not sure how that ties in
> with the device trees that live in the Linux tree. Do you have any
> pointers about this?

We don't really have overlays in the kernel sources (yet), though it
is something that keeps coming up. For the moment, I'd just
assume you can have one .dts file for each thing you want to
support and keep the shared bits in .dtsi files.

> >
> > Did you see the discussion on the #armlinux channel about the possibility
> > of moving the cpu-enable method to PSCI based on a UEFI runtime
> > interface?
...
>
> I saw it go by but need to review it again; I've been missing too much
> sleep this week :) thanks for the reminder.
>
> I think we might want to start with spin-table for now, given that there
> are no kernel changes needed anyway, but I'm happy to take the protoype
> for a spin (:)) and try implementing it in m1n1.
>
> I do think it's valuable for whatever we do, at this stage, to not
> require u-boot; having that be an integral part of the boot chain is
> perfectly fine in the future but right now it helps to have a simple
> boot chain while we work out the early bring-up, and while u-boot grows
> the required support.

Agreed.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel