| Message ID | 20210304213902.83903-28-marcan@marcan.st (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Apple M1 SoC platform bring-up | expand |
On 04/03/2021 22:39, Hector Martin wrote: > This currently supports: > > * SMP (via spin-tables) > * AIC IRQs > * Serial (with earlycon) > * Framebuffer > > A number of properties are dynamic, and based on system firmware > decisions that vary from version to version. These are expected > to be filled in by the loader. > > Signed-off-by: Hector Martin <marcan@marcan.st> > --- > MAINTAINERS | 1 + > arch/arm64/boot/dts/Makefile | 1 + > arch/arm64/boot/dts/apple/Makefile | 2 + > arch/arm64/boot/dts/apple/t8103-j274.dts | 45 ++++++++ > arch/arm64/boot/dts/apple/t8103.dtsi | 135 +++++++++++++++++++++++ > 5 files changed, 184 insertions(+) > create mode 100644 arch/arm64/boot/dts/apple/Makefile > create mode 100644 arch/arm64/boot/dts/apple/t8103-j274.dts > create mode 100644 arch/arm64/boot/dts/apple/t8103.dtsi > > diff --git a/MAINTAINERS b/MAINTAINERS > index 28bd46f4f7a7..d5e4d93a536a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1647,6 +1647,7 @@ C: irc://chat.freenode.net/asahi-dev > T: git https://github.com/AsahiLinux/linux.git > F: Documentation/devicetree/bindings/arm/apple.yaml > F: Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml > +F: arch/arm64/boot/dts/apple/ > F: arch/arm64/include/asm/sysreg_apple.h > F: drivers/irqchip/irq-apple-aic.c > F: include/dt-bindings/interrupt-controller/apple-aic.h > diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile > index f1173cd93594..639e01a4d855 100644 > --- a/arch/arm64/boot/dts/Makefile > +++ b/arch/arm64/boot/dts/Makefile > @@ -6,6 +6,7 @@ subdir-y += amazon > subdir-y += amd > subdir-y += amlogic > subdir-y += apm > +subdir-y += apple > subdir-y += arm > subdir-y += bitmain > subdir-y += broadcom > diff --git a/arch/arm64/boot/dts/apple/Makefile b/arch/arm64/boot/dts/apple/Makefile > new file mode 100644 > index 000000000000..cbbd701ebf05 > --- /dev/null > +++ b/arch/arm64/boot/dts/apple/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0 > +dtb-$(CONFIG_ARCH_APPLE) += t8103-j274.dtb > diff --git a/arch/arm64/boot/dts/apple/t8103-j274.dts b/arch/arm64/boot/dts/apple/t8103-j274.dts > new file mode 100644 > index 000000000000..8afc2ed70361 > --- /dev/null > +++ b/arch/arm64/boot/dts/apple/t8103-j274.dts > @@ -0,0 +1,45 @@ > +// SPDX-License-Identifier: GPL-2.0+ OR MIT > +/* > + * Apple Mac mini (M1, 2020) > + * > + * target-type: J174 > + * > + * Copyright The Asahi Linux Contributors > + */ > + > +/dts-v1/; > + > +#include "t8103.dtsi" > + > +/ { > + compatible = "apple,j274", "apple,t8103", "apple,arm-platform"; > + model = "Apple Mac mini (M1, 2020)"; > + > + aliases { > + serial0 = &serial0; > + }; > + > + chosen { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + stdout-path = "serial0"; > + > + framebuffer0: framebuffer@0 { > + compatible = "apple,simple-framebuffer", "simple-framebuffer"; > + reg = <0 0 0 0>; /* To be filled by loader */ > + /* Format properties will be added by loader */ > + status = "disabled"; > + }; > + }; > + > + memory@800000000 { > + device_type = "memory"; > + reg = <0x8 0 0x2 0>; /* To be filled by loader */ Shouldn't this be 0x800000000 with ~0x80000000 length (or whatever is more common)? Or did I miss some ranges? Best regards, Krzysztof
On 05/03/2021 20.03, Krzysztof Kozlowski wrote: >> + memory@800000000 { >> + device_type = "memory"; >> + reg = <0x8 0 0x2 0>; /* To be filled by loader */ > > Shouldn't this be 0x800000000 with ~0x80000000 length (or whatever is > more common)? Or did I miss some ranges? The base model has 8GB of RAM, and RAM always starts at 0x800000000, hence that reg property. It's not actually useful to try to boot Linux like this, because it'll step all over device carveouts on both ends and break, but since those are potentially dynamic it doesn't really make sense to use a more specific example for the dts. E.g. on my system, with my current firmware version, this ends up getting patched to: reg = <0x8 0x0134c000 0x1 0xda294000> Thanks,
On 05/03/2021 12:14, Hector Martin wrote: > On 05/03/2021 20.03, Krzysztof Kozlowski wrote: >>> + memory@800000000 { >>> + device_type = "memory"; >>> + reg = <0x8 0 0x2 0>; /* To be filled by loader */ >> >> Shouldn't this be 0x800000000 with ~0x80000000 length (or whatever is >> more common)? Or did I miss some ranges? > > The base model has 8GB of RAM, and RAM always starts at 0x800000000, > hence that reg property. Ah, I messed up the unit addressing and number of zeros... it's OK. Best regards, Krzysztof
> From: Hector Martin <marcan@marcan.st> > Date: Fri, 5 Mar 2021 20:14:10 +0900 > > On 05/03/2021 20.03, Krzysztof Kozlowski wrote: > >> + memory@800000000 { > >> + device_type = "memory"; > >> + reg = <0x8 0 0x2 0>; /* To be filled by loader */ > > > > Shouldn't this be 0x800000000 with ~0x80000000 length (or whatever is > > more common)? Or did I miss some ranges? > > The base model has 8GB of RAM, and RAM always starts at 0x800000000, > hence that reg property. > > It's not actually useful to try to boot Linux like this, because it'll > step all over device carveouts on both ends and break, but since those > are potentially dynamic it doesn't really make sense to use a more > specific example for the dts. > > E.g. on my system, with my current firmware version, this ends up > getting patched to: > > reg = <0x8 0x0134c000 0x1 0xda294000> It may be better to handle the memory reserved by the firmware using a "/reserved-memory" node. I think the benefit of that could be that it communicates the entire range of physical memory to the kernel, which means it could use large mappings in the page tables. Unless the "/reserved-memory" node defines a region that has the "no-map" property of course. That doesn't really have an impact on this diff though. The firmware/bootloader would still have to modify the property on 16GB models.
On 06/03/2021 00.59, Mark Kettenis wrote: > It may be better to handle the memory reserved by the firmware using a > "/reserved-memory" node. I think the benefit of that could be that it > communicates the entire range of physical memory to the kernel, which > means it could use large mappings in the page tables. Unless the > "/reserved-memory" node defines a region that has the "no-map" > property of course. We actually need no-map, because otherwise the CPU could speculate its way into these carveouts (it's not just firmware, there's stuff in here the CPU really can't be allowed to touch, e.g. the SEP carveout). It also breaks simplefb mapping the framebuffer. I thought of the reserved-memory approach, but then figured it wouldn't buy us anything for this reason.
Hi! > +++ b/arch/arm64/boot/dts/apple/t8103-j274.dts > @@ -0,0 +1,45 @@ > +// SPDX-License-Identifier: GPL-2.0+ OR MIT It seems to be "// SPDX-License-Identifier: (GPL-2.0+ OR MIT)" in other DTs (notice the brackets). > +/* > + * Apple Mac mini (M1, 2020) Not sure if it's necessary, you already state it in model="" > + * > + * target-type: J174 Isn't that a typo? Compatible states J*2*74, but I'm curious if that's intentional. > + * > + * Copyright The Asahi Linux Contributors * Copyright (C) 2021 The Asahi Linux Contributors > + */ > + > +/dts-v1/; > + > +#include "t8103.dtsi" > + > +/ { > + compatible = "apple,j274", "apple,t8103", "apple,arm-platform"; > + model = "Apple Mac mini (M1, 2020)"; > + > + aliases { > + serial0 = &serial0; Isn't this M1-common? > + }; > + > + chosen { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + stdout-path = "serial0"; Doesn't serial work without this? > + > + framebuffer0: framebuffer@0 { Not sure if we want the @0 (unless it's also overwritten by the loader). > + compatible = "apple,simple-framebuffer", "simple-framebuffer"; > + reg = <0 0 0 0>; /* To be filled by loader */ > + /* Format properties will be added by loader */ > + status = "disabled"; Does it get enabled by the loader? Also, isn't the framebuffer common for all M1 devices? > + }; > + }; > + > + memory@800000000 { > + device_type = "memory"; > + reg = <0x8 0 0x2 0>; /* To be filled by loader */ > + }; Shouldn't this be in the SoC DTSI? > +}; > + > +&serial0 { > + status = "okay"; > +}; > diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi b/arch/arm64/boot/dts/apple/t8103.dtsi > new file mode 100644 > index 000000000000..aac9e4e6abc5 > --- /dev/null > +++ b/arch/arm64/boot/dts/apple/t8103.dtsi > @@ -0,0 +1,135 @@ > +// SPDX-License-Identifier: GPL-2.0+ OR MIT > +/* > + * Apple T8103 "M1" SoC > + * > + * Other names: H13G, "Tonga" > + * > + * Copyright The Asahi Linux Contributors Ditto > + */ > + > +#include <dt-bindings/interrupt-controller/apple-aic.h> > +#include <dt-bindings/interrupt-controller/irq.h> > + > +/ { > + compatible = "apple,t8103", "apple,arm-platform"; Please remove this line, it's getting overwritten anyway. > + }; > + > + soc { > + compatible = "simple-bus"; > + #address-cells = <2>; > + #size-cells = <2>; > + > + ranges; > + nonposted-mmio; > + I think " compatible = "simple-bus"; #address-cells = <2>; #size-cells = <2>; nonposted-mmio; ranges; " would look more coherent to the human eye, but that's rather a nit. Other than this, node order seems to be entirely random. Please sort them by address (where applicable) and by name where not, so that this doesn't become a huge mess as we go forward. Konrad
Hi, Sorry, I did not see this e-mail originally as it was sent only to the mailing list, not to me nor CCed to anyone else. I am subscribed to the lists, but I generally rely on my inbox for review feedback. I have added a sieve rule to catch emails sent to the list that are replies to me and do not have me in To: or Cc: and copy them to my inbox in the future. That said, I think it's best to reply-all, to keep everyone else in the loop. CCing a few relevant folks. On 14/03/2021 05.22, Konrad Dybcio wrote: >> +// SPDX-License-Identifier: GPL-2.0+ OR MIT > > It seems to be > > "// SPDX-License-Identifier: (GPL-2.0+ OR MIT)" > > in other DTs (notice the brackets). This was already discussed in [1]. The conclusion was that no braces is the preferred form according to the SPDX spec. [1] https://lore.kernel.org/linux-arm-kernel/20210216073120.qmlaky43t6uelqc4@kozik-lap/ >> +/* >> + * Apple Mac mini (M1, 2020) > > Not sure if it's necessary, you already state it in model="" I find it helpful to have identifying info in the top comment, since it's easier to locate at a glance than visually searching for the model property. Since I also add identifiers that Apple uses to be able to cross reference things here, even if it's somewhat duplicative, I think it makes sense to keep all of it in the top comment. >> + * >> + * target-type: J174 > > Isn't that a typo? Compatible states J*2*74, but I'm curious if that's intentional. That's a typo, it's already fixed in v4 :) >> + * >> + * Copyright The Asahi Linux Contributors > > * Copyright (C) 2021 The Asahi Linux Contributors This was also discussed, see [2] and [3]. Copyright dates in headers are essentially useless because they are always out of date in practice. [2] https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/ [3] https://lore.kernel.org/linux-arm-kernel/d8454963-3242-699b-4c20-e85d26b19796@marcan.st/ >> + */ >> + >> +/dts-v1/; >> + >> +#include "t8103.dtsi" >> + >> +/ { >> + compatible = "apple,j274", "apple,t8103", "apple,arm-platform"; >> + model = "Apple Mac mini (M1, 2020)"; >> + >> + aliases { >> + serial0 = &serial0; > > Isn't this M1-common? It's common to all existing M1 devices, but in principle there is nothing that says that the stdout path has to be the first UART on any given device (there is more than one UART, we just aren't declaring the others yet in this series). This is a common pattern, see e.g. nvidia/tegra210-smaug.dts. >> + }; >> + >> + chosen { >> + #address-cells = <2>; >> + #size-cells = <2>; >> + ranges; >> + >> + stdout-path = "serial0"; > > Doesn't serial work without this? This is for earlycon to work. See e.g. nvidia/tegra210-smaug.dts for another example. Note that this still requires the earlycon kernel parameter, so if earlycon is not enabled then this does nothing; if the user also isn't setting the serial TTY device as a console, then the serial port is free for use by the user. > Not sure if we want the @0 (unless it's also overwritten by the loader). We need a unit address for the linter, but yes, this is in fact overwritten by the loader with the correct one. >> + compatible = "apple,simple-framebuffer", "simple-framebuffer"; >> + reg = <0 0 0 0>; /* To be filled by loader */ >> + /* Format properties will be added by loader */ >> + status = "disabled"; > > Does it get enabled by the loader? Yup, assuming everything works. The loader leaves it disabled if something goes wrong converting the information from the XNU bootargs (e.g. unsupported CLUT format, which I don't think any M1 mac ever uses). > Also, isn't the framebuffer common for all M1 devices? The framebuffer is allocated by iBoot dynamically, and is at a variable address. The format is also variable, as is the resolution, depending on the device. This is why the loader fills in the info. In principle, the idea that a framebuffer exists is common to all existing devices, but nothing says this has to be the case for future devices: it's not a SoC property, it's a property of devices built using the SoC (and the way they are configured by iBoot). >> + }; >> + }; >> + >> + memory@800000000 { >> + device_type = "memory"; >> + reg = <0x8 0 0x2 0>; /* To be filled by loader */ >> + }; > > Shouldn't this be in the SoC DTSI? It could. The pattern I'm trying to follow here is that stuff filled in by the loader or which varies from device to device goes in the board file; technically here it doesn't matter since of course every SoC has "some" memory and the loader overwrites it anyway, but this still makes logical sense to me. If you look around, you'll see memory is usually defined in board or sub-platform files, not the SoC root (exception: qcom stuff, apparently). >> + compatible = "apple,t8103", "apple,arm-platform"; > > Please remove this line, it's getting overwritten anyway. I think it's helpful to document the expected compatible subset to be inherited by board files. The Tegra example I linked above does this too. >> + }; >> + >> + soc { >> + compatible = "simple-bus"; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + ranges; >> + nonposted-mmio; >> + > > I think > > " > > compatible = "simple-bus"; > > #address-cells = <2>; > > #size-cells = <2>; > > nonposted-mmio; > > ranges; > > " > > would look more coherent to the human eye, but that's rather a nit. The reason for putting nonposted-mmio last is that it is a flag for a bus, so to me it makes logical sense to put it after ranges, which is what marks this as a translatable bus. > Other than this, node order seems to be entirely random. Please sort them by address (where applicable) and by name where not, so that this doesn't become a huge mess as we go forward. Outside of the soc bus I think the order we have makes sense: CPUs first, timer (which is part of the CPU complex) next, then fixed clocks. There are only a few things that are going to go in here, so I think an ad-hoc order like this is okay. Inside the bus we only have two nodes so far, and they are indeed in the wrong order :-). I'll sort them by address. Almost everything else is going to go in here in the future, so that should keep things sane. Thanks!
On Mon, Apr 5, 2021 at 7:50 AM Hector Martin <marcan@marcan.st> wrote: > On 14/03/2021 05.22, Konrad Dybcio wrote: > > [1] > https://lore.kernel.org/linux-arm-kernel/20210216073120.qmlaky43t6uelqc4@kozik-lap/ > > >> +/* > >> + * Apple Mac mini (M1, 2020) > > > > Not sure if it's necessary, you already state it in model="" > > I find it helpful to have identifying info in the top comment, since > it's easier to locate at a glance than visually searching for the model > property. Since I also add identifiers that Apple uses to be able to > cross reference things here, even if it's somewhat duplicative, I think > it makes sense to keep all of it in the top comment. Agreed > >> + > >> +/dts-v1/; > >> + > >> +#include "t8103.dtsi" > >> + > >> +/ { > >> + compatible = "apple,j274", "apple,t8103", "apple,arm-platform"; > >> + model = "Apple Mac mini (M1, 2020)"; > >> + > >> + aliases { > >> + serial0 = &serial0; > > > > Isn't this M1-common? > > It's common to all existing M1 devices, but in principle there is > nothing that says that the stdout path has to be the first UART on any > given device (there is more than one UART, we just aren't declaring the > others yet in this series). This is a common pattern, see e.g. > nvidia/tegra210-smaug.dts. Also, I normally ask for the aliases, chosen and memory nodes to be part of the .dts file since these are settings that may be set by the bootloader and are not specific to the SoCs at all. > >> + compatible = "apple,t8103", "apple,arm-platform"; > > > > Please remove this line, it's getting overwritten anyway. > > I think it's helpful to document the expected compatible subset to be > inherited by board files. The Tegra example I linked above does this too. I'm fine with it either way here, your reasoning makes sense, but I personally don't ask for these to be added or removed. > > Other than this, node order seems to be entirely random. Please sort them > > by address (where applicable) and by name where not, so that this doesn't > > become a huge mess as we go forward. > > Outside of the soc bus I think the order we have makes sense: CPUs > first, timer (which is part of the CPU complex) next, then fixed clocks. > There are only a few things that are going to go in here, so I think an > ad-hoc order like this is okay. > > Inside the bus we only have two nodes so far, and they are indeed in the > wrong order :-). I'll sort them by address. Almost everything else is > going to go in here in the future, so that should keep things sane. Sounds good. Ordering by address is a good default, in particular for the SoC node, but other orders can make sense, too. We used to have some SoCs that sorted everything alphabetically, but that is less common now. The main reason for having a fixed sort order is to help with merge conflicts if we ever get nodes added through different git trees. If both sides add the same node in the same place, that lets git cleanly resolve the merge, while adding the same node in different places duplicates it, and adding different versions in the same place should cause a merge conflict. Arnd
diff --git a/MAINTAINERS b/MAINTAINERS index 28bd46f4f7a7..d5e4d93a536a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1647,6 +1647,7 @@ C: irc://chat.freenode.net/asahi-dev T: git https://github.com/AsahiLinux/linux.git F: Documentation/devicetree/bindings/arm/apple.yaml F: Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml +F: arch/arm64/boot/dts/apple/ F: arch/arm64/include/asm/sysreg_apple.h F: drivers/irqchip/irq-apple-aic.c F: include/dt-bindings/interrupt-controller/apple-aic.h diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index f1173cd93594..639e01a4d855 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -6,6 +6,7 @@ subdir-y += amazon subdir-y += amd subdir-y += amlogic subdir-y += apm +subdir-y += apple subdir-y += arm subdir-y += bitmain subdir-y += broadcom diff --git a/arch/arm64/boot/dts/apple/Makefile b/arch/arm64/boot/dts/apple/Makefile new file mode 100644 index 000000000000..cbbd701ebf05 --- /dev/null +++ b/arch/arm64/boot/dts/apple/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0 +dtb-$(CONFIG_ARCH_APPLE) += t8103-j274.dtb diff --git a/arch/arm64/boot/dts/apple/t8103-j274.dts b/arch/arm64/boot/dts/apple/t8103-j274.dts new file mode 100644 index 000000000000..8afc2ed70361 --- /dev/null +++ b/arch/arm64/boot/dts/apple/t8103-j274.dts @@ -0,0 +1,45 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Apple Mac mini (M1, 2020) + * + * target-type: J174 + * + * Copyright The Asahi Linux Contributors + */ + +/dts-v1/; + +#include "t8103.dtsi" + +/ { + compatible = "apple,j274", "apple,t8103", "apple,arm-platform"; + model = "Apple Mac mini (M1, 2020)"; + + aliases { + serial0 = &serial0; + }; + + chosen { + #address-cells = <2>; + #size-cells = <2>; + ranges; + + stdout-path = "serial0"; + + framebuffer0: framebuffer@0 { + compatible = "apple,simple-framebuffer", "simple-framebuffer"; + reg = <0 0 0 0>; /* To be filled by loader */ + /* Format properties will be added by loader */ + status = "disabled"; + }; + }; + + memory@800000000 { + device_type = "memory"; + reg = <0x8 0 0x2 0>; /* To be filled by loader */ + }; +}; + +&serial0 { + status = "okay"; +}; diff --git a/arch/arm64/boot/dts/apple/t8103.dtsi b/arch/arm64/boot/dts/apple/t8103.dtsi new file mode 100644 index 000000000000..aac9e4e6abc5 --- /dev/null +++ b/arch/arm64/boot/dts/apple/t8103.dtsi @@ -0,0 +1,135 @@ +// SPDX-License-Identifier: GPL-2.0+ OR MIT +/* + * Apple T8103 "M1" SoC + * + * Other names: H13G, "Tonga" + * + * Copyright The Asahi Linux Contributors + */ + +#include <dt-bindings/interrupt-controller/apple-aic.h> +#include <dt-bindings/interrupt-controller/irq.h> + +/ { + compatible = "apple,t8103", "apple,arm-platform"; + + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + cpu0: cpu@0 { + compatible = "apple,icestorm"; + device_type = "cpu"; + reg = <0x0 0x0>; + enable-method = "spin-table"; + cpu-release-addr = <0 0>; /* To be filled by loader */ + }; + + cpu1: cpu@1 { + compatible = "apple,icestorm"; + device_type = "cpu"; + reg = <0x0 0x1>; + enable-method = "spin-table"; + cpu-release-addr = <0 0>; /* To be filled by loader */ + }; + + cpu2: cpu@2 { + compatible = "apple,icestorm"; + device_type = "cpu"; + reg = <0x0 0x2>; + enable-method = "spin-table"; + cpu-release-addr = <0 0>; /* To be filled by loader */ + }; + + cpu3: cpu@3 { + compatible = "apple,icestorm"; + device_type = "cpu"; + reg = <0x0 0x3>; + enable-method = "spin-table"; + cpu-release-addr = <0 0>; /* To be filled by loader */ + }; + + cpu4: cpu@10100 { + compatible = "apple,firestorm"; + device_type = "cpu"; + reg = <0x0 0x10100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0>; /* To be filled by loader */ + }; + + cpu5: cpu@10101 { + compatible = "apple,firestorm"; + device_type = "cpu"; + reg = <0x0 0x10101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0>; /* To be filled by loader */ + }; + + cpu6: cpu@10102 { + compatible = "apple,firestorm"; + device_type = "cpu"; + reg = <0x0 0x10102>; + enable-method = "spin-table"; + cpu-release-addr = <0 0>; /* To be filled by loader */ + }; + + cpu7: cpu@10103 { + compatible = "apple,firestorm"; + device_type = "cpu"; + reg = <0x0 0x10103>; + enable-method = "spin-table"; + cpu-release-addr = <0 0>; /* To be filled by loader */ + }; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupt-parent = <&aic>; + interrupt-names = "hyp-phys", "hyp-virt", "phys", "virt"; + interrupts = <AIC_FIQ AIC_TMR_HV_PHYS IRQ_TYPE_LEVEL_HIGH>, + <AIC_FIQ AIC_TMR_HV_VIRT IRQ_TYPE_LEVEL_HIGH>, + <AIC_FIQ AIC_TMR_GUEST_PHYS IRQ_TYPE_LEVEL_HIGH>, + <AIC_FIQ AIC_TMR_GUEST_VIRT IRQ_TYPE_LEVEL_HIGH>; + }; + + clk24: clock-24m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <24000000>; + clock-output-names = "clk24"; + }; + + soc { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + + ranges; + nonposted-mmio; + + aic: interrupt-controller@23b100000 { + compatible = "apple,t8103-aic", "apple,aic"; + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x2 0x3b100000 0x0 0x8000>; + }; + + serial0: serial@235200000 { + compatible = "apple,s5l-uart"; + reg = <0x2 0x35200000 0x0 0x1000>; + reg-io-width = <4>; + interrupt-parent = <&aic>; + interrupts = <AIC_IRQ 605 IRQ_TYPE_LEVEL_HIGH>; + /* + * TODO: figure out the clocking properly, there may + * be a third selectable clock. + */ + clocks = <&clk24>, <&clk24>; + clock-names = "uart", "clk_uart_baud0"; + status = "disabled"; + }; + }; +};
This currently supports: * SMP (via spin-tables) * AIC IRQs * Serial (with earlycon) * Framebuffer A number of properties are dynamic, and based on system firmware decisions that vary from version to version. These are expected to be filled in by the loader. Signed-off-by: Hector Martin <marcan@marcan.st> --- MAINTAINERS | 1 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/apple/Makefile | 2 + arch/arm64/boot/dts/apple/t8103-j274.dts | 45 ++++++++ arch/arm64/boot/dts/apple/t8103.dtsi | 135 +++++++++++++++++++++++ 5 files changed, 184 insertions(+) create mode 100644 arch/arm64/boot/dts/apple/Makefile create mode 100644 arch/arm64/boot/dts/apple/t8103-j274.dts create mode 100644 arch/arm64/boot/dts/apple/t8103.dtsi