On Thu, Sep 04, 2025 at 12:41:58PM +0200, Ulf Hansson wrote:
> On Thu, 28 Aug 2025 at 16:01, Janne Grunau <j@xxxxxxxxxx> wrote:
> >
> > This series adds device trees for Apple's M2 Pro, Max and Ultra based
> > devices. The M2 Pro (t6020), M2 Max (t6021) and M2 Ultra (t6022) SoCs
> > follow design of the t600x family so copy the structure of SoC *.dtsi
> > files.
> >
> > t6020 is a cut-down version of t6021, so the former just includes the
> > latter and disables the missing bits.
> >
> > t6022 is two connected t6021 dies. The implementation seems to use
> > t6021 and disables blocks based on whether it is useful to carry
> > multiple instances. The disabled blocks are mostly on the second die.
> > MMIO addresses on the second die have a constant offset. The interrupt
> > controller is multi-die aware. This setup can be represented in the
> > device tree with two top level "soc" nodes. The MMIO offset is applied
> > via "ranges" and devices are included with preprocessor macros to make
> > the node labels unique and to specify the die number for the interrupt
> > definition.
> >
> > The devices itself are very similar to their M1 Pro, M1 Max and M1 Ultra
> > counterparts. The existing device templates are SoC agnostic so the new
> > devices can reuse them and include their t602{0,1,2}.dtsi file. The
> > minor differences in pinctrl and gpio numbers can be easily adjusted.
> >
> > With the t602x SoC family Apple introduced two new devices:
> >
> > The M2 Pro Mac mini is similar to the larger M1 and M2 Max Mac Studio. The
> > missing SDHCI card reader and two front USB3.1 type-c ports and their
> > internal USB hub can be easily deleted.
> >
> > The M2 Ultra Mac Pro (tower and rack-mount cases) differs from all other
> > devices but may share some bits with the M2 Ultra Mac Studio. The PCIe
> > implementation on the M2 Ultra in the Mac Pro differs slightly. Apple
> > calls the PCIe controller "apcie-ge" in their device tree. The
> > implementation seems to be mostly compatible with the base t6020 PCIe
> > controller. The main difference is that there is only a single port with
> > with 8 or 16 PCIe Gen4 lanes. These ports connect to a Microchip
> > Switchtec PCIe switch with 100 lanes to which all internal PCIe devices
> > and PCIe slots connect too.
> >
> > This series does not include PCIe support for the Mac Pro for two
> > reasons:
> > - the linux switchtec driver fails to probe and the downstream PCIe
> > connections come up as PCIe Gen1
> > - some of the internal devices require PERST# and power control to come
> > up. Since the device are connected via the PCIe switch the PCIe
> > controller can not do this. The PCI slot pwrctrl can be utilized for
> > power control but misses integration with PERST# as proposed in [1].
> >
> > This series depends on "[PATCH v2 0/5] Apple device tree sync from
> > downstream kernel" [2] due to the reuse of the t600x device templates
> > (patch dependencies and DT compilation) and 4 page table level support
> > in apple-dart and io-pgtable-dart [3] since the dart instances report
> > 42-bit IAS (IOMMU device attach fails without the series).
> >
> > After discussion with the devicetree maintainers we agreed to not extend
> > lists with the generic compatibles anymore [1]. Instead either the first
> > compatible SoC or t8103 is used as fallback compatible supported by the
> > drivers. t8103 is used as default since most drivers and bindings were
> > initially written for M1 based devices.
> >
> > The series adds those fallback compatibles to drivers where necessary,
> > annotates the SoC lists for generic compatibles as "do not extend" and
> > adds t6020 per-SoC compatibles.
> >
> > [1]: https://lore.kernel.org/linux-pci/20250819-pci-pwrctrl-perst-v1-0-4b74978d2007@xxxxxxxxxxxxxxxx/
> > [2]: https://lore.kernel.org/asahi/20250823-apple-dt-sync-6-17-v2-0-6dc0daeb4786@xxxxxxxxxx/
> > [3]: https://lore.kernel.org/asahi/20250821-apple-dart-4levels-v2-0-e39af79daa37@xxxxxxxxxx/
> > [4]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@xxxxxxxxxx/
> >
> > Signed-off-by: Janne Grunau <j@xxxxxxxxxx>
>
> Is it okay for me to pick up the pmdomain patches (patch3 and patch4)
> by now - or what route are you planning to get this merged through?
Sorry, I forgot to mention the merge strategy in the cover letter. I've
picking up all acked patches that are not yet picked up and we'll merge
them through the apple-soc tree.
This includes all dt-binding patches, patch4.
Feel free to pick up or ack patch3
Janne
