[PATCH 00/18] Apple M1 SoC platform bring-up

[Arnd Bergmann]

On Thu, Feb 4, 2021 at 9:39 PM Hector Martin <marcan at marcan.st> wrote:
>
> This series brings up initial support for the Apple M1 SoC, used in the
> 2020 Mac Mini, MacBook Pro, and MacBook Air models.

I like this a lot overall, great work!

As you probably know, the timing would be really tight for a merge
in 5.12, but if we can work out a solution for the FIQ and MMIO
problems quickly and you get Ack's from the relevant maintainers
(arch/arm64, serial, irqchip), I'd be happy to merge all of it through
the soc tree even fairly late this cycle.

> The following features are supported in this initial port:
>
> - UART (samsung-style) with earlycon support
> - Interrupts, including affinity and IPIs (Apple Interrupt Controller)
> - SMP (through standard spin-table support)
> - simplefb-based framebuffer

Side note about simplefb: Ard mentioned on IRC that there is
earlycon support in efifb but not in simplefb. Once we have
a u-boot based boot flow, it would be a great help for boot-time
debugging to use earlycon on the framebuffer for those that don't
have a special uart cable.

An alternative would be to rework the simplefb driver in some
form to allow earlycon without efifb. The earlycon support there
is actually fairly simple, but doing this would raise the question
of whether it can be shared between the two and possibly the
drm/kms based drivers.

> - Devicetree for the Mac Mini (should work for the others too at this
>   stage)
>
> The primary pain points of this port are:
>
> - Apple SoCs require FIQs, as the timers and "fast" IPIs are hardwired
>   to the FIQ interrupt line. This patchset introduces FIQ support through
>   the alternatives mechanism, so as to not affect other platforms,
>   implemented as simply merging IRQs and FIQs. The AIC driver takes care
>   of discriminating and routing IRQs to the right users.
>
> - These SoCs blackhole nGnRE writes to internal MMIO ranges, and require
>   nGnRnE. There is no obvious right solution to solve this. I do not
>   expect the two patches for that in this series to be merged as-is, but
>   the commit messages describe the problem and potential solutions. I
>   hope we can have a discussion and converge on the right approach to
>   solve this problem in the sanest way.

I would add here the cpu enable-method as a third point that needs to
be decided on before we can consider merging it. As I commented
in patch 18, staying with spin-table would be the easiest way to start,
but that means the risk of an incompatible DT change later on.

        Arnd