Re: [PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-14 Thread Mark Kettenis
> From: Rob Herring 
> Date: Mon, 11 Oct 2021 14:48:46 -0500

Hi Rob,

Trimming the CC list a bit and adding marcan.

> On Mon, Oct 11, 2021 at 2:00 PM Mark Kettenis  wrote:
> >
> > > From: Rob Herring 
> > > Date: Mon, 11 Oct 2021 13:36:29 -0500
> >
> > Hi Rob,
> >
> > > On Sun, Oct 3, 2021 at 1:35 PM Mark Kettenis  wrote:
> > > >
> > > > Add preliminary device trees for the Apple M1 mini (2020) and
> > > > Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> > > > the Apple M1 SoC are still being formalized and these device
> > > > trees will be synchronized with the Linux kernel as needed.
> > >
> > > So not synchronized currently? If it is sync'ed, you should specify
> > > which version you got.
> >
> > Not synched at the moment.  It is based on what was in 5.13 or 5.14,
> > but with lots of stuff added so specifying a version would be
> > misleading.  It should be mostly aligned with the bindings that are
> > making their way into 5.15 or 5.16 though.
> 
> This and what's added or preliminary would be good to have in the commit msg.

Sure.  I added that information to the commit message for v4.

> > Hopefully now that the power domains are getting addressed we'll have
> > something that can be synchronized soon.  I was explicitly encouraged
> > to start upstreaming the U-Boot code even though not all the DT
> > bindings had been sorted out.
> 
> In general, sounds like a recipe for getting out of sync and bindings
> never getting documented properly without any checks in place. The
> good news is checking that is at least possible now.
> 
> > > > These device trees are provided as a reference only as U-Boot
> > > > uses the device tree passed by the m1n1 bootloader.
> > >
> > > If reference only, why do they need to be checked in here? We're
> > > trying to get to fewer copies both of dtbs at runtime and dts files in
> > > source trees.
> >
> > The U-Boot maintainers insist there is a DT for each supported system
> > in the U-Boot tree.
> 
> Ok, fair enough.
> 
> > > I mainly bring it up here because this is a platform with multiple OS
> > > targets, following the model that DT comes from the firmware, and
> > > should be free of schema validation warnings. In other words, it's a
> > > good candidate to define best practices.
> >
> > You're preaching to the choir ;).
> 
> Good.
> 
> > Must admit that it is somewhat convenient for me to have a somewhat
> > complete DT for these devices at the moment.  But in the long run I
> > think it will just confuse people.  That said, I plan to be aggressive
> > in keeping the U-Boot tree synchronized with Linux.
> 
> What I'd like to see here is some sort of automatic synchronization.
> The idea I have here is just a list of boards to sync from the kernel
> tree to wherever. The requirement to get on the list would be passing
> schema validation and would be a declaration of stability (there's
> been numerous discussions over the years of how to declare a DT stable
> or unstable). It would perhaps also include passing validation on an
> older schema. I'm not sure how well that would catch compatibility
> issues, but that's the only idea I've come up with besides just
> testing of mixed versions. I'm happy to do the tooling to support that
> if we have a board/device to put in the list and u-boot folks agree to
> use it. I suppose even if just m1n1 used it to start with, I'd be
> willing to do the tooling.

Sounds interesting.

One of the things we would want to do a ship device trees for new
models with m1n1 as soon as we get our hands on the hardware such that
the they can be used with existing distro kernels as soon as possible.
Under the assumption that the new hardware is compatible with the old
of course.  That means those new device trees should pass validation.

But as soon as the device tree for a model is available in the Linux
tree, we probably want to be rather strict in synching it to m1n1.

Thanks,

Mark


Re: [PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-11 Thread Tom Rini
On Mon, Oct 11, 2021 at 02:00:56PM -0600, Simon Glass wrote:
> Hi Rob,
> 
> On Mon, 11 Oct 2021 at 13:49, Rob Herring  wrote:
> >
> > On Mon, Oct 11, 2021 at 2:00 PM Mark Kettenis  
> > wrote:
> > >
> > > > From: Rob Herring 
> > > > Date: Mon, 11 Oct 2021 13:36:29 -0500
> > >
> > > Hi Rob,
> > >
> > > > On Sun, Oct 3, 2021 at 1:35 PM Mark Kettenis  
> > > > wrote:
> > > > >
> > > > > Add preliminary device trees for the Apple M1 mini (2020) and
> > > > > Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> > > > > the Apple M1 SoC are still being formalized and these device
> > > > > trees will be synchronized with the Linux kernel as needed.
> > > >
> > > > So not synchronized currently? If it is sync'ed, you should specify
> > > > which version you got.
> > >
> > > Not synched at the moment.  It is based on what was in 5.13 or 5.14,
> > > but with lots of stuff added so specifying a version would be
> > > misleading.  It should be mostly aligned with the bindings that are
> > > making their way into 5.15 or 5.16 though.
> >
> > This and what's added or preliminary would be good to have in the commit 
> > msg.
> >
> > > Hopefully now that the power domains are getting addressed we'll have
> > > something that can be synchronized soon.  I was explicitly encouraged
> > > to start upstreaming the U-Boot code even though not all the DT
> > > bindings had been sorted out.
> >
> > In general, sounds like a recipe for getting out of sync and bindings
> > never getting documented properly without any checks in place. The
> > good news is checking that is at least possible now.
> >
> > > > > These device trees are provided as a reference only as U-Boot
> > > > > uses the device tree passed by the m1n1 bootloader.
> > > >
> > > > If reference only, why do they need to be checked in here? We're
> > > > trying to get to fewer copies both of dtbs at runtime and dts files in
> > > > source trees.
> > >
> > > The U-Boot maintainers insist there is a DT for each supported system
> > > in the U-Boot tree.
> >
> > Ok, fair enough.
> >
> > > > I mainly bring it up here because this is a platform with multiple OS
> > > > targets, following the model that DT comes from the firmware, and
> > > > should be free of schema validation warnings. In other words, it's a
> > > > good candidate to define best practices.
> > >
> > > You're preaching to the choir ;).
> >
> > Good.
> >
> > > Must admit that it is somewhat convenient for me to have a somewhat
> > > complete DT for these devices at the moment.  But in the long run I
> > > think it will just confuse people.  That said, I plan to be aggressive
> > > in keeping the U-Boot tree synchronized with Linux.
> >
> > What I'd like to see here is some sort of automatic synchronization.
> > The idea I have here is just a list of boards to sync from the kernel
> > tree to wherever. The requirement to get on the list would be passing
> > schema validation and would be a declaration of stability (there's
> > been numerous discussions over the years of how to declare a DT stable
> > or unstable). It would perhaps also include passing validation on an
> > older schema. I'm not sure how well that would catch compatibility
> > issues, but that's the only idea I've come up with besides just
> > testing of mixed versions. I'm happy to do the tooling to support that
> > if we have a board/device to put in the list and u-boot folks agree to
> > use it. I suppose even if just m1n1 used it to start with, I'd be
> > willing to do the tooling.
> 
> That sounds great to me. Yes m1n1 is a good first target since it is
> new, but I'm pretty sure there are quite a few other SoCs that could
> move over right away.
> 
> Ideally we would add it to U-Boot CI too, so that pull requests warn
> or fail if something wrong is added. Of course it is probably a no-no
> to make U-Boot CI due to comparisons with another tree over which we
> have no control, but perhaps we can head in that direction.
> 
> +Tom Rini too as he has been looking at this.

I guess the first priority is that so long as _everything_ is in sync,
it doesn't super matter if we have an otherwise redundant copy of files
in-tree.

And we need to get our DTS files back in sync with upstream, which is
the case for some platforms, and not others.  But once we get that
sorted out, we need to do more regular resyncs, and hopefully once
DTS files have settled down, because they all pass validation and for
example incorrect names get fixed, it will be less of an issue to more
automatically resync DTS files, that are fully validated at least.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-11 Thread Simon Glass
Hi Rob,

On Mon, 11 Oct 2021 at 13:49, Rob Herring  wrote:
>
> On Mon, Oct 11, 2021 at 2:00 PM Mark Kettenis  wrote:
> >
> > > From: Rob Herring 
> > > Date: Mon, 11 Oct 2021 13:36:29 -0500
> >
> > Hi Rob,
> >
> > > On Sun, Oct 3, 2021 at 1:35 PM Mark Kettenis  wrote:
> > > >
> > > > Add preliminary device trees for the Apple M1 mini (2020) and
> > > > Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> > > > the Apple M1 SoC are still being formalized and these device
> > > > trees will be synchronized with the Linux kernel as needed.
> > >
> > > So not synchronized currently? If it is sync'ed, you should specify
> > > which version you got.
> >
> > Not synched at the moment.  It is based on what was in 5.13 or 5.14,
> > but with lots of stuff added so specifying a version would be
> > misleading.  It should be mostly aligned with the bindings that are
> > making their way into 5.15 or 5.16 though.
>
> This and what's added or preliminary would be good to have in the commit msg.
>
> > Hopefully now that the power domains are getting addressed we'll have
> > something that can be synchronized soon.  I was explicitly encouraged
> > to start upstreaming the U-Boot code even though not all the DT
> > bindings had been sorted out.
>
> In general, sounds like a recipe for getting out of sync and bindings
> never getting documented properly without any checks in place. The
> good news is checking that is at least possible now.
>
> > > > These device trees are provided as a reference only as U-Boot
> > > > uses the device tree passed by the m1n1 bootloader.
> > >
> > > If reference only, why do they need to be checked in here? We're
> > > trying to get to fewer copies both of dtbs at runtime and dts files in
> > > source trees.
> >
> > The U-Boot maintainers insist there is a DT for each supported system
> > in the U-Boot tree.
>
> Ok, fair enough.
>
> > > I mainly bring it up here because this is a platform with multiple OS
> > > targets, following the model that DT comes from the firmware, and
> > > should be free of schema validation warnings. In other words, it's a
> > > good candidate to define best practices.
> >
> > You're preaching to the choir ;).
>
> Good.
>
> > Must admit that it is somewhat convenient for me to have a somewhat
> > complete DT for these devices at the moment.  But in the long run I
> > think it will just confuse people.  That said, I plan to be aggressive
> > in keeping the U-Boot tree synchronized with Linux.
>
> What I'd like to see here is some sort of automatic synchronization.
> The idea I have here is just a list of boards to sync from the kernel
> tree to wherever. The requirement to get on the list would be passing
> schema validation and would be a declaration of stability (there's
> been numerous discussions over the years of how to declare a DT stable
> or unstable). It would perhaps also include passing validation on an
> older schema. I'm not sure how well that would catch compatibility
> issues, but that's the only idea I've come up with besides just
> testing of mixed versions. I'm happy to do the tooling to support that
> if we have a board/device to put in the list and u-boot folks agree to
> use it. I suppose even if just m1n1 used it to start with, I'd be
> willing to do the tooling.

That sounds great to me. Yes m1n1 is a good first target since it is
new, but I'm pretty sure there are quite a few other SoCs that could
move over right away.

Ideally we would add it to U-Boot CI too, so that pull requests warn
or fail if something wrong is added. Of course it is probably a no-no
to make U-Boot CI due to comparisons with another tree over which we
have no control, but perhaps we can head in that direction.

+Tom Rini too as he has been looking at this.

Regards,
Simon


Re: [PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-11 Thread Rob Herring
On Mon, Oct 11, 2021 at 2:00 PM Mark Kettenis  wrote:
>
> > From: Rob Herring 
> > Date: Mon, 11 Oct 2021 13:36:29 -0500
>
> Hi Rob,
>
> > On Sun, Oct 3, 2021 at 1:35 PM Mark Kettenis  wrote:
> > >
> > > Add preliminary device trees for the Apple M1 mini (2020) and
> > > Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> > > the Apple M1 SoC are still being formalized and these device
> > > trees will be synchronized with the Linux kernel as needed.
> >
> > So not synchronized currently? If it is sync'ed, you should specify
> > which version you got.
>
> Not synched at the moment.  It is based on what was in 5.13 or 5.14,
> but with lots of stuff added so specifying a version would be
> misleading.  It should be mostly aligned with the bindings that are
> making their way into 5.15 or 5.16 though.

This and what's added or preliminary would be good to have in the commit msg.

> Hopefully now that the power domains are getting addressed we'll have
> something that can be synchronized soon.  I was explicitly encouraged
> to start upstreaming the U-Boot code even though not all the DT
> bindings had been sorted out.

In general, sounds like a recipe for getting out of sync and bindings
never getting documented properly without any checks in place. The
good news is checking that is at least possible now.

> > > These device trees are provided as a reference only as U-Boot
> > > uses the device tree passed by the m1n1 bootloader.
> >
> > If reference only, why do they need to be checked in here? We're
> > trying to get to fewer copies both of dtbs at runtime and dts files in
> > source trees.
>
> The U-Boot maintainers insist there is a DT for each supported system
> in the U-Boot tree.

Ok, fair enough.

> > I mainly bring it up here because this is a platform with multiple OS
> > targets, following the model that DT comes from the firmware, and
> > should be free of schema validation warnings. In other words, it's a
> > good candidate to define best practices.
>
> You're preaching to the choir ;).

Good.

> Must admit that it is somewhat convenient for me to have a somewhat
> complete DT for these devices at the moment.  But in the long run I
> think it will just confuse people.  That said, I plan to be aggressive
> in keeping the U-Boot tree synchronized with Linux.

What I'd like to see here is some sort of automatic synchronization.
The idea I have here is just a list of boards to sync from the kernel
tree to wherever. The requirement to get on the list would be passing
schema validation and would be a declaration of stability (there's
been numerous discussions over the years of how to declare a DT stable
or unstable). It would perhaps also include passing validation on an
older schema. I'm not sure how well that would catch compatibility
issues, but that's the only idea I've come up with besides just
testing of mixed versions. I'm happy to do the tooling to support that
if we have a board/device to put in the list and u-boot folks agree to
use it. I suppose even if just m1n1 used it to start with, I'd be
willing to do the tooling.


Rob


Re: [PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-11 Thread Mark Kettenis
> From: Rob Herring 
> Date: Mon, 11 Oct 2021 13:36:29 -0500

Hi Rob,

> On Sun, Oct 3, 2021 at 1:35 PM Mark Kettenis  wrote:
> >
> > Add preliminary device trees for the Apple M1 mini (2020) and
> > Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> > the Apple M1 SoC are still being formalized and these device
> > trees will be synchronized with the Linux kernel as needed.
> 
> So not synchronized currently? If it is sync'ed, you should specify
> which version you got.

Not synched at the moment.  It is based on what was in 5.13 or 5.14,
but with lots of stuff added so specifying a version would be
misleading.  It should be mostly aligned with the bindings that are
making their way into 5.15 or 5.16 though.

Hopefully now that the power domains are getting addressed we'll have
something that can be synchronized soon.  I was explicitly encouraged
to start upstreaming the U-Boot code even though not all the DT
bindings had been sorted out.

> > These device trees are provided as a reference only as U-Boot
> > uses the device tree passed by the m1n1 bootloader.
> 
> If reference only, why do they need to be checked in here? We're
> trying to get to fewer copies both of dtbs at runtime and dts files in
> source trees.

The U-Boot maintainers insist there is a DT for each supported system
in the U-Boot tree.

> I mainly bring it up here because this is a platform with multiple OS
> targets, following the model that DT comes from the firmware, and
> should be free of schema validation warnings. In other words, it's a
> good candidate to define best practices.

You're preaching to the choir ;).

Must admit that it is somewhat convenient for me to have a somewhat
complete DT for these devices at the moment.  But in the long run I
think it will just confuse people.  That said, I plan to be aggressive
in keeping the U-Boot tree synchronized with Linux.

Cheers,

Mark


Re: [PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-11 Thread Simon Glass
Hi Rob,

On Mon, 11 Oct 2021 at 12:36, Rob Herring  wrote:
>
> On Sun, Oct 3, 2021 at 1:35 PM Mark Kettenis  wrote:
> >
> > Add preliminary device trees for the Apple M1 mini (2020) and
> > Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> > the Apple M1 SoC are still being formalized and these device
> > trees will be synchronized with the Linux kernel as needed.
>
> So not synchronized currently? If it is sync'ed, you should specify
> which version you got.
>
> > These device trees are provided as a reference only as U-Boot
> > uses the device tree passed by the m1n1 bootloader.
>
> If reference only, why do they need to be checked in here? We're
> trying to get to fewer copies both of dtbs at runtime and dts files in
> source trees.
>
> I mainly bring it up here because this is a platform with multiple OS
> targets, following the model that DT comes from the firmware, and
> should be free of schema validation warnings. In other words, it's a
> good candidate to define best practices.

This is something I have brought in, as U-Boot DT maintainer, to
provide some sort of reference in U-Boot as to what is actually built.
It allows people to see the devices and also ensures that the build
system does build a devicetree. The existing OF_PRIOR_STAGE is being
removed and OF_BOARD is becoming a bool, with OF_SEPARATE the standard
approach.

We have a few examples where this is not done (e.g. qemu-arm) but I am
working on fixing that. It has led to discussions about whether U-Boot
is entitled to having its own things in the DT, etc. etc. The whole
area is in flux at present. If you want some background:

https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/

Regards,
Simon


Re: [PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-11 Thread Rob Herring
On Sun, Oct 3, 2021 at 1:35 PM Mark Kettenis  wrote:
>
> Add preliminary device trees for the Apple M1 mini (2020) and
> Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> the Apple M1 SoC are still being formalized and these device
> trees will be synchronized with the Linux kernel as needed.

So not synchronized currently? If it is sync'ed, you should specify
which version you got.

> These device trees are provided as a reference only as U-Boot
> uses the device tree passed by the m1n1 bootloader.

If reference only, why do they need to be checked in here? We're
trying to get to fewer copies both of dtbs at runtime and dts files in
source trees.

I mainly bring it up here because this is a platform with multiple OS
targets, following the model that DT comes from the firmware, and
should be free of schema validation warnings. In other words, it's a
good candidate to define best practices.

Rob


Re: [PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-11 Thread Simon Glass
On Sun, 3 Oct 2021 at 12:34, Mark Kettenis  wrote:
>
> Add preliminary device trees for the Apple M1 mini (2020) and
> Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
> the Apple M1 SoC are still being formalized and these device
> trees will be synchronized with the Linux kernel as needed.
>
> These device trees are provided as a reference only as U-Boot
> uses the device tree passed by the m1n1 bootloader.
>
> Signed-off-by: Mark Kettenis 
> ---
>  arch/arm/dts/Makefile |   4 +
>  arch/arm/dts/t8103-j274.dts   | 135 +
>  arch/arm/dts/t8103-j293.dts   |  97 +++
>  arch/arm/dts/t8103.dtsi   | 560 ++
>  configs/apple_m1_defconfig|   1 +
>  .../interrupt-controller/apple-aic.h  |  15 +
>  include/dt-bindings/pinctrl/apple.h   |  13 +
>  include/dt-bindings/spmi/spmi.h   |  10 +
>  8 files changed, 835 insertions(+)
>  create mode 100644 arch/arm/dts/t8103-j274.dts
>  create mode 100644 arch/arm/dts/t8103-j293.dts
>  create mode 100644 arch/arm/dts/t8103.dtsi
>  create mode 100644 include/dt-bindings/interrupt-controller/apple-aic.h
>  create mode 100644 include/dt-bindings/pinctrl/apple.h
>  create mode 100644 include/dt-bindings/spmi/spmi.h
>

Reviewed-by: Simon Glass 


[PATCH v2 6/7] arm: dts: apple: Add preliminary device trees

2021-10-03 Thread Mark Kettenis
Add preliminary device trees for the Apple M1 mini (2020) and
Apple M1 Macbook Pro 13" (2020).  Device tree bindings for
the Apple M1 SoC are still being formalized and these device
trees will be synchronized with the Linux kernel as needed.

These device trees are provided as a reference only as U-Boot
uses the device tree passed by the m1n1 bootloader.

Signed-off-by: Mark Kettenis 
---
 arch/arm/dts/Makefile |   4 +
 arch/arm/dts/t8103-j274.dts   | 135 +
 arch/arm/dts/t8103-j293.dts   |  97 +++
 arch/arm/dts/t8103.dtsi   | 560 ++
 configs/apple_m1_defconfig|   1 +
 .../interrupt-controller/apple-aic.h  |  15 +
 include/dt-bindings/pinctrl/apple.h   |  13 +
 include/dt-bindings/spmi/spmi.h   |  10 +
 8 files changed, 835 insertions(+)
 create mode 100644 arch/arm/dts/t8103-j274.dts
 create mode 100644 arch/arm/dts/t8103-j293.dts
 create mode 100644 arch/arm/dts/t8103.dtsi
 create mode 100644 include/dt-bindings/interrupt-controller/apple-aic.h
 create mode 100644 include/dt-bindings/pinctrl/apple.h
 create mode 100644 include/dt-bindings/spmi/spmi.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index fc16a57e60..65152d3ddf 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -29,6 +29,10 @@ dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5422-odroidxu3.dtb
 dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
 
+dtb-$(CONFIG_ARCH_APPLE) += \
+   t8103-j274.dtb \
+   t8103-j293.dtb
+
 dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-evm.dtb \
da850-lcdk.dtb \
diff --git a/arch/arm/dts/t8103-j274.dts b/arch/arm/dts/t8103-j274.dts
new file mode 100644
index 00..aef1ae29b6
--- /dev/null
+++ b/arch/arm/dts/t8103-j274.dts
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Apple Mac mini (M1, 2020)
+ *
+ * target-type: J274
+ *
+ * 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 = 
+   ethernet0 = 
+   wifi0 = 
+   };
+
+   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@8 {
+   device_type = "memory";
+   reg = <0x8 0 0x2 0>; /* To be filled by loader */
+   };
+};
+
+ {
+   status = "okay";
+};
+
+_dart_0 {
+   status = "okay";
+};
+
+_dart_1 {
+   status = "okay";
+};
+
+_dart_2 {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   pci0: pci@0,0 {
+   device_type = "pci";
+   reg = <0x0 0x0 0x0 0x0 0x0>;
+   pwren-gpios = < 13 0>;
+   reset-gpios = <_ap 152 0>;
+   max-link-speed = <2>;
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges;
+   };
+
+   pci1: pci@1,0 {
+   device_type = "pci";
+   reg = <0x800 0x0 0x0 0x0 0x0>;
+   reset-gpios = <_ap 153 0>;
+   max-link-speed = <2>;
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges;
+   };
+
+   pci2: pci@2,0 {
+   device_type = "pci";
+   reg = <0x1000 0x0 0x0 0x0 0x0>;
+   reset-gpios = <_ap 33 0>;
+   max-link-speed = <1>;
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges;
+   };
+};
+
+ {
+   wifi0: network@0,0 {
+   reg = <0x1 0x0 0x0 0x0 0x0>;
+   local-mac-address = [00 00 00 00 00 00];
+   };
+};
+
+ {
+   eth0: ethernet@0,0 {
+   reg = <0x3 0x0 0x0 0x0 0x0>;
+   local-mac-address = [00 00 00 00 00 00];
+   };
+};
+
+_0_dart_0 {
+   status = "okay";
+};
+
+_0_dart_1 {
+   status = "okay";
+};
+
+_0 {
+   status = "okay";
+};
+
+_1_dart_0 {
+   status = "okay";
+};
+
+_1_dart_1 {
+   status = "okay";
+};
+
+_1 {
+   status = "okay";
+};
diff --git a/arch/arm/dts/t8103-j293.dts b/arch/arm/dts/t8103-j293.dts
new file mode 100644
index 00..4a22596cf4
--- /dev/null
+++ b/arch/arm/dts/t8103-j293.dts
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Apple Macbook Pro (M1, 2020)
+ *
+ * target-type: J293
+ *
+ * Copyright The Asahi Linux