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

[Arnd Bergmann]

On Thu, Feb 4, 2021 at 9:39 PM Hector Martin <marcan at marcan.st> wrote:

> +/ {
> +       model = "Apple Mac Mini M1 2020";
> +       compatible = "AAPL,j274", "AAPL,m1", "AAPL,arm-platform";
> +       #address-cells = <2>;
> +       #size-cells = <2>;
> +
> +       chosen {
> +               #address-cells = <2>;
> +               #size-cells = <2>;
> +               ranges;
> +
> +               bootargs = "earlycon";
> +               stdout-path = "serial0:1500000";
> +
> +               framebuffer0: framebuffer at 0 {
> +                       compatible = "AAPL,simple-framebuffer", "simple-framebuffer";
> +                       reg = <0 0 0 0>; // To be filled by loader
> +                       // Format properties will be added by loader
> +                       status = "disabled";
> +               };
> +       };
> +
> +       memory at 800000000 {
> +               device_type = "memory";
> +               reg = <0 0 0 0>; // To be filled by loader
> +       };
> +
> +       aliases {
> +               serial0 = &serial0;
> +       };

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.

> +       cpus {
> +               #address-cells = <2>;
> +               #size-cells = <0>;
> +
> +               cpu0: cpu at 0 {
> +                       compatible = "AAPL,icestorm";
> +                       device_type = "cpu";
> +                       reg = <0x0 0x0>;
> +                       enable-method = "spin-table";
> +                       cpu-release-addr = <0 0>; // To be filled by loader
> +               };

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?

There are a few open questions about what that would look like in the
end, but Ard has come up with a prototype for the kernel side of it
(obviously untested), which would interface either into the UEFI side
of u-boot, or a simple already-instantiated version that could be
kept inside of m1n1 and stay resident in memory.

I would like to see that model get adopted here eventually. If
we manage to get the other patches ready for an initial merge in
v5.12, we can probably start out with spin-table and move to that
in a following release though.

        Arnd