Message-ID: <20250914152518.GB1645557@robin.jannau.net>
Date: Sun, 14 Sep 2025 17:25:18 +0200
From: Janne Grunau <j@...nau.net>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Sven Peter <sven@...nel.org>, Alyssa Rosenzweig <alyssa@...enzweig.io>,
	Neal Gompa <neal@...pa.dev>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,	Hector Martin <marcan@...can.st>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,	Joerg Roedel <joro@...tes.org>,
 Will Deacon <will@...nel.org>,	Robin Murphy <robin.murphy@....com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Kettenis <kettenis@...nbsd.org>,	Andi Shyti <andi.shyti@...nel.org>,
	Jassi Brar <jassisinghbrar@...il.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Sasha Finkelstein <fnkl.kernel@...il.com>,
	Marcel Holtmann <marcel@...tmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@...il.com>,
	Johannes Berg <johannes@...solutions.net>,
	van Spriel <arend@...adcom.com>, Lee Jones <lee@...nel.org>,
	Uwe Kleine-König <ukleinek@...nel.org>,
	Stephen Boyd <sboyd@...nel.org>,
	Wim Van Sebroeck <wim@...ux-watchdog.org>,
	Guenter Roeck <linux@...ck-us.net>,
	Michael Turquette <mturquette@...libre.com>,
	Martin Povišer <povik+lin@...ebit.org>,
	Vinod Koul <vkoul@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Marc Zyngier <maz@...nel.org>,
	Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...nel.dk>,
	Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
	asahi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, iommu@...ts.linux.dev,
	linux-gpio@...r.kernel.org, linux-i2c@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, linux-bluetooth@...r.kernel.org,
	linux-wireless@...r.kernel.org, linux-pwm@...r.kernel.org,
	linux-watchdog@...r.kernel.org, linux-clk@...r.kernel.org,
	dmaengine@...r.kernel.org, linux-sound@...r.kernel.org,
	linux-spi@...r.kernel.org, linux-nvme@...ts.infradead.org
Subject: Re: [PATCH 00/37] arm64: Add initial device trees for Apple M2
 Pro/Max/Ultra devices

On Thu, Sep 04, 2025 at 12:41:58PM +0200, Ulf Hansson wrote:
> On Thu, 28 Aug 2025 at 16:01, Janne Grunau <j@...nau.net> 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@oss.qualcomm.com/
> > [2]: https://lore.kernel.org/asahi/20250823-apple-dt-sync-6-17-v2-0-6dc0daeb4786@jannau.net/
> > [3]: https://lore.kernel.org/asahi/20250821-apple-dart-4levels-v2-0-e39af79daa37@jannau.net/
> > [4]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/
> >
> > Signed-off-by: Janne Grunau <j@...nau.net>
> 
> 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

Powered by blists - more mailing lists