| Message ID | 20191205082555.22633-3-james.tai@realtek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Initial RTD1319 SoC and Realtek PymParticle EVB support | expand |
Hi James, + Robin for PMU + Lorenzo for PSCI Am 05.12.19 um 09:25 schrieb James Tai: > Add Device Trees for Realtek RTD1319 SoC family, RTD1319 SoC and > Realtek PymParticle EVB. > > Signed-off-by: James Tai <james.tai@realtek.com> > --- > arch/arm64/boot/dts/realtek/Makefile | 2 + > .../boot/dts/realtek/rtd1319-pymparticle.dts | 43 ++++++ > arch/arm64/boot/dts/realtek/rtd1319.dtsi | 12 ++ > arch/arm64/boot/dts/realtek/rtd13xx.dtsi | 137 ++++++++++++++++++ > 4 files changed, 194 insertions(+) > create mode 100644 arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts > create mode 100644 arch/arm64/boot/dts/realtek/rtd1319.dtsi > create mode 100644 arch/arm64/boot/dts/realtek/rtd13xx.dtsi > > diff --git a/arch/arm64/boot/dts/realtek/Makefile b/arch/arm64/boot/dts/realtek/Makefile > index fb5f05978ecc..ab00c272ea9e 100644 > --- a/arch/arm64/boot/dts/realtek/Makefile > +++ b/arch/arm64/boot/dts/realtek/Makefile > @@ -9,3 +9,5 @@ dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb > dtb-$(CONFIG_ARCH_REALTEK) += rtd1296-ds418.dtb > > dtb-$(CONFIG_ARCH_REALTEK) += rtd1619-mjolnir.dtb > + > +dtb-$(CONFIG_ARCH_REALTEK) += rtd1319-pymparticle.dtb This hunk is lacking rtd1395, so is not based on the latest patches I posted. I expect you to be developing against linux-next.git tree, and when there's relevant in-flight patches, you'll need to either apply my patches via git-am to your tree, or for convenience you can use the beginning of my (but better not the full experimental) rtd1295-next branch (git-rebase -i, or (careful!) git-reset --hard). Yes, neither is super-easy. Same as with the binding, it would seem better to not add this at the end, even if it's your newest family. Consider this: Someone finds an RTD1036 in their household and wants to contribute a patch - where would they add it? I don't want all newly added stuff to go into the bottom of the file (then it'll be hard to find and potentially causes conflicts), so we need a stable sort order where I don't need to do historical research of whether 1036 is newer or older than 1195/1296 to determine where to insert it in a file. Alphanumerical sort order seems simplest to understand and is proven elsewhere to reduce merge conflicts. > diff --git a/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts > new file mode 100644 > index 000000000000..d8bfe2304b71 > --- /dev/null > +++ b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts > @@ -0,0 +1,43 @@ > +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) > +/* > + * Copyright (c) 2019 Realtek Semiconductor Corp. > + */ > + > +/dts-v1/; > + > +#include "rtd1319.dtsi" > + > +/ { > + compatible = "realtek,pymparticle", "realtek,rtd1319"; Thanks, correct order now. > + model = "Realtek PymParticle EVB"; > + > + memory@0 { > + device_type = "memory"; > + reg = <0x0 0x80000000>; > + }; No! I understood RTD1319 has the same boot ROM size 184 KiB as RTD1619, so please look at the patches I posted, including fix for RTD1619 [1], and fix this yourself here. A comment for humans would also be nice. In the public BPI-M4-bsp code I see one -pymparticle-1GB.CMAx2.dts file. If this board is available with less than 2 GiB RAM then please use the lower value to be safe - you can run a 2 GiB board with 1 GiB RAM used, but using more RAM than available will break. [1] https://patchwork.kernel.org/patch/11268969/ > + > + chosen { > + stdout-path = "serial0:460800n8"; > + }; > + > + aliases { > + serial0 = &uart0; > + serial1 = &uart1; > + serial2 = &uart2; > + }; > +}; > + > +/* debug console (J1) */ > +&uart0 { > + status = "okay"; > +}; > + > +/* M.2 slot (CON8) */ > +&uart1 { > + status = "disabled"; > +}; > + > +/* GPIO connector (T1) */ > +&uart2 { > + status = "disabled"; > +}; > diff --git a/arch/arm64/boot/dts/realtek/rtd1319.dtsi b/arch/arm64/boot/dts/realtek/rtd1319.dtsi > new file mode 100644 > index 000000000000..1dcee00009cd > --- /dev/null > +++ b/arch/arm64/boot/dts/realtek/rtd1319.dtsi > @@ -0,0 +1,12 @@ > +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) > +/* > + * Realtek RTD1319 SoC > + * > + * Copyright (c) 2019 Realtek Semiconductor Corp. > + */ > + > +#include "rtd13xx.dtsi" > + > +/ { > + compatible = "realtek,rtd1319"; > +}; What other contents are you expecting to add in this file? > diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi > new file mode 100644 > index 000000000000..92bf962377f6 > --- /dev/null > +++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi > @@ -0,0 +1,137 @@ > +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) > +/* > + * Realtek RTD13xx SoC family > + * > + * Copyright (c) 2019 Realtek Semiconductor Corp. > + */ > + > +#include <dt-bindings/interrupt-controller/arm-gic.h> > +#include <dt-bindings/interrupt-controller/irq.h> > + > +/ { > + interrupt-parent = <&gic>; > + #address-cells = <1>; > + #size-cells = <1>; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu0: cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + reg = <0x0>; > + enable-method = "psci"; > + next-level-cache = <&l2>; > + }; > + > + cpu1: cpu@100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + reg = <0x100>; > + enable-method = "psci"; > + next-level-cache = <&l2>; > + }; > + > + cpu2: cpu@200 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + reg = <0x200>; > + enable-method = "psci"; > + next-level-cache = <&l2>; > + }; > + > + cpu3: cpu@300 { > + device_type = "cpu"; > + compatible = "arm,cortex-a55"; > + reg = <0x300>; > + enable-method = "psci"; > + next-level-cache = <&l2>; > + }; > + > + l2: l2-cache { > + compatible = "cache"; > + }; I note this seems a different cache topology than RTD1619? > + }; > + > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, > + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, > + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, > + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; > + }; > + > + arm_pmu: pmu { > + compatible = "arm,armv8-pmuv3"; > + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>; > + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, > + <&cpu3>; > + }; @Robin, is this single PPI interrupt better than previous single SPI? Is "arm,armv8-pmuv3" the correct one to use for Cortex-A55? There's no "arm,cortex-a55-pmu" binding - is that still in the works? > + > + psci { > + compatible = "arm,psci-1.0"; @Lorenzo: Same question as left unanswered for RTD1619: Should this be "arm,psci-1.0", "arm-psci-0.2"? The YAML schema allows both, without clearly documenting which one shall be used in new DTs, and there's no psci-1.0 example either. > + method = "smc"; > + }; > + > + osc27M: osc { > + compatible = "fixed-clock"; > + clock-frequency = <27000000>; > + clock-output-names = "osc27M"; BTW I recall seeing "osc27m" in your clk patchset. We should decide on one name and stick with it consistently, and I think it's best to have this as a node here in .dtsi (or in .dts), in case OEMs ever choose to have it generated by some other non-trivial IC. > + #clock-cells = <0>; > + }; > + > + soc { > + compatible = "simple-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x98000000 0x98000000 0x68000000>; No! Lacking a range for boot ROM. And your range is probably too large due to high RAM. Please see [1] and fix for both. r-bus ranges below would indicate that above soc range should be 0x00200000 long only, plus extra ranges for whatever besides r-bus is shadowing RAM (e.g., GIC). > + > + rbus: bus@98000000 { > + compatible = "simple-bus"; > + reg = <0x98000000 0x200000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x0 0x98000000 0x200000>; Thanks for incorporating r-bus right away. > + > + uart0: serial0@7800 { > + compatible = "snps,dw-apb-uart"; > + reg = <0x7800 0x400>; > + reg-shift = <2>; > + reg-io-width = <4>; > + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>; > + clock-frequency = <432000000>; > + status = "disabled"; > + }; > + > + uart1: serial1@1b200 { > + compatible = "snps,dw-apb-uart"; > + reg = <0x1b200 0x400>; > + reg-shift = <2>; > + reg-io-width = <4>; > + interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>; > + clock-frequency = <432000000>; > + status = "disabled"; > + }; > + > + uart2: serial2@1b400 { > + compatible = "snps,dw-apb-uart"; > + reg = <0x1b400 0x400>; > + reg-shift = <2>; > + reg-io-width = <4>; > + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; > + clock-frequency = <432000000>; > + status = "disabled"; > + }; Here you appear to ignore my patches introducing syscon for ISO & MISC! See https://patchwork.kernel.org/cover/11269453/ > + }; > + > + gic: interrupt-controller@ff100000 { > + compatible = "arm,gic-v3"; > + reg = <0xff100000 0x10000>, > + <0xff140000 0xc0000>; > + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-controller; > + #interrupt-cells = <3>; > + }; > + }; > +}; Please review patches that have been posted to the list, and incorporate such fixes and refactorings into any new patches. If you disagree with my patchsets, then you need to reply to them! If my numbers and naming are correct on the other hand, you and your colleagues are encouraged to respond to patches with an Acked-by, or Reviewed-by if you've reviewed the full patch, and/or Tested-by if you've tested it on some board (usually with comment on where/what you did). As long as no compatible strings get introduced, it is within my discretion to apply DT patches to linux-realtek.git if no review comments arrive asking for changes, so you can safely assume that I'll apply my own non-RFC patches otherwise. Not responding to patches and silently subverting them is not the way to go. linux-realtek-soc is still fairly small in volume compared to LAKML, so that I do expect contributors to at least skim patch subjects and cover letters for any conflicting/relevant work before posting patches. Don't expect maintainers to apply a v1 patch and to fix it up for you. For Acked-by vs. Reviewed-by, compare this and the next section: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by If you want to post patches that you know are not yet ready for merging, you can use --subject-prefix="RFC", like I did for the SoC info series. The cover letter should explain the main discussion points then. Thanks in advance, Andreas
On 2019-12-05 10:58 am, Andreas Färber wrote: [...] >> + arm_pmu: pmu { >> + compatible = "arm,armv8-pmuv3"; >> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>; >> + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, >> + <&cpu3>; >> + }; > > @Robin, is this single PPI interrupt better than previous single SPI? Yes, a PPI is ideal (since it allows core to see its own local interrupt). > Is "arm,armv8-pmuv3" the correct one to use for Cortex-A55? There's no > "arm,cortex-a55-pmu" binding - is that still in the works? Hmm, I had thought that had been done already, but apparently not. Looks like it's high time for another round of event map updates for the latest Cortex and Neoverse cores, so I guess I'll add that to our backlog internally - although the PMU events should be in the public TRMs so if anyone else *did* fancy ploughing through them to spin patches they're always welcome to :) In the meantime the generic PMUv3 compatible will at least expose the subset of mandatory architectural events, which is arguably more useful than nothing. >> + >> + psci { >> + compatible = "arm,psci-1.0"; > > @Lorenzo: Same question as left unanswered for RTD1619: > Should this be "arm,psci-1.0", "arm-psci-0.2"? > > The YAML schema allows both, without clearly documenting which one shall > be used in new DTs, and there's no psci-1.0 example either. FWIW the age of the DT shouldn't really be relevant - it's a question of whether the platform's EL3 firmware actually implements the PSCI 1.0 (or later) spec, or is some fossilised binary based on the older version. Robin.
Hi Andreas, > This hunk is lacking rtd1395, so is not based on the latest patches I posted. I > expect you to be developing against linux-next.git tree, and when there's > relevant in-flight patches, you'll need to either apply my patches via git-am to > your tree, or for convenience you can use the beginning of my (but better not > the full experimental) rtd1295-next branch (git-rebase -i, or (careful!) git-reset > --hard). Yes, neither is super-easy. > I will use your rtd1295-next branch for development. > Same as with the binding, it would seem better to not add this at the end, even > if it's your newest family. Consider this: Someone finds an > RTD1036 in their household and wants to contribute a patch - where would > they add it? I don't want all newly added stuff to go into the bottom of the file > (then it'll be hard to find and potentially causes conflicts), so we need a stable > sort order where I don't need to do historical research of whether 1036 is > newer or older than 1195/1296 to determine where to insert it in a file. > Alphanumerical sort order seems simplest to understand and is proven > elsewhere to reduce merge conflicts. Thanks for your kind reminder. > > diff --git a/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts > > b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts > > new file mode 100644 > > index 000000000000..d8bfe2304b71 > > --- /dev/null > > +++ b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts > > @@ -0,0 +1,43 @@ > > +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) > > +/* > > + * Copyright (c) 2019 Realtek Semiconductor Corp. > > + */ > > + > > +/dts-v1/; > > + > > +#include "rtd1319.dtsi" > > + > > +/ { > > + compatible = "realtek,pymparticle", "realtek,rtd1319"; > > Thanks, correct order now. > > > + model = "Realtek PymParticle EVB"; > > + > > + memory@0 { > > + device_type = "memory"; > > + reg = <0x0 0x80000000>; > > + }; > > No! I understood RTD1319 has the same boot ROM size 184 KiB as RTD1619, > so please look at the patches I posted, including fix for RTD1619 [1], and fix > this yourself here. A comment for humans would also be nice. > > In the public BPI-M4-bsp code I see one -pymparticle-1GB.CMAx2.dts file. > If this board is available with less than 2 GiB RAM then please use the lower > value to be safe - you can run a 2 GiB board with 1 GiB RAM used, but using > more RAM than available will break. > > [1] https://patchwork.kernel.org/patch/11268969/ > I will fix it in next version patch. > > +++ b/arch/arm64/boot/dts/realtek/rtd1319.dtsi > > @@ -0,0 +1,12 @@ > > +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) > > +/* > > + * Realtek RTD1319 SoC > > + * > > + * Copyright (c) 2019 Realtek Semiconductor Corp. > > + */ > > + > > +#include "rtd13xx.dtsi" > > + > > +/ { > > + compatible = "realtek,rtd1319"; > > +}; > > What other contents are you expecting to add in this file? I expect add USB, SATA, PCIE and so on. > > + cpus { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + cpu0: cpu@0 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + reg = <0x0>; > > + enable-method = "psci"; > > + next-level-cache = <&l2>; > > + }; > > + > > + cpu1: cpu@100 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + reg = <0x100>; > > + enable-method = "psci"; > > + next-level-cache = <&l2>; > > + }; > > + > > + cpu2: cpu@200 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + reg = <0x200>; > > + enable-method = "psci"; > > + next-level-cache = <&l2>; > > + }; > > + > > + cpu3: cpu@300 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a55"; > > + reg = <0x300>; > > + enable-method = "psci"; > > + next-level-cache = <&l2>; > > + }; > > + > > + l2: l2-cache { > > + compatible = "cache"; > > + }; > > I note this seems a different cache topology than RTD1619? > Yes, It is different cache topology than RTD1619. The RTD1319 don't have an L3 cache. > > + osc27M: osc { > > + compatible = "fixed-clock"; > > + clock-frequency = <27000000>; > > + clock-output-names = "osc27M"; > > BTW I recall seeing "osc27m" in your clk patchset. We should decide on one > name and stick with it consistently, and I think it's best to have this as a node > here in .dtsi (or in .dts), in case OEMs ever choose to have it generated by > some other non-trivial IC. I understand. > > + #clock-cells = <0>; > > + }; > > + > > + soc { > > + compatible = "simple-bus"; > > + #address-cells = <1>; > > + #size-cells = <1>; > > + ranges = <0x98000000 0x98000000 0x68000000>; > > No! Lacking a range for boot ROM. And your range is probably too large due to > high RAM. Please see [1] and fix for both. r-bus ranges below would indicate > that above soc range should be 0x00200000 long only, plus extra ranges for > whatever besides r-bus is shadowing RAM (e.g., GIC). > I will fix it in next version patch. > > + > > + uart0: serial0@7800 { > > + compatible = "snps,dw-apb-uart"; > > + reg = <0x7800 0x400>; > > + reg-shift = <2>; > > + reg-io-width = <4>; > > + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>; > > + clock-frequency = <432000000>; > > + status = "disabled"; > > + }; > > + > > + uart1: serial1@1b200 { > > + compatible = "snps,dw-apb-uart"; > > + reg = <0x1b200 0x400>; > > + reg-shift = <2>; > > + reg-io-width = <4>; > > + interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>; > > + clock-frequency = <432000000>; > > + status = "disabled"; > > + }; > > + > > + uart2: serial2@1b400 { > > + compatible = "snps,dw-apb-uart"; > > + reg = <0x1b400 0x400>; > > + reg-shift = <2>; > > + reg-io-width = <4>; > > + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; > > + clock-frequency = <432000000>; > > + status = "disabled"; > > + }; > > Here you appear to ignore my patches introducing syscon for ISO & MISC! > > See https://patchwork.kernel.org/cover/11269453/ I will apply the syscon for ISO & MISC in next version patch. > > + }; > > + > > + gic: interrupt-controller@ff100000 { > > + compatible = "arm,gic-v3"; > > + reg = <0xff100000 0x10000>, > > + <0xff140000 0xc0000>; > > + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; > > + interrupt-controller; > > + #interrupt-cells = <3>; > > + }; > > + }; > > +}; > Regards, James
diff --git a/arch/arm64/boot/dts/realtek/Makefile b/arch/arm64/boot/dts/realtek/Makefile index fb5f05978ecc..ab00c272ea9e 100644 --- a/arch/arm64/boot/dts/realtek/Makefile +++ b/arch/arm64/boot/dts/realtek/Makefile @@ -9,3 +9,5 @@ dtb-$(CONFIG_ARCH_REALTEK) += rtd1295-zidoo-x9s.dtb dtb-$(CONFIG_ARCH_REALTEK) += rtd1296-ds418.dtb dtb-$(CONFIG_ARCH_REALTEK) += rtd1619-mjolnir.dtb + +dtb-$(CONFIG_ARCH_REALTEK) += rtd1319-pymparticle.dtb diff --git a/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts new file mode 100644 index 000000000000..d8bfe2304b71 --- /dev/null +++ b/arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts @@ -0,0 +1,43 @@ +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) +/* + * Copyright (c) 2019 Realtek Semiconductor Corp. + */ + +/dts-v1/; + +#include "rtd1319.dtsi" + +/ { + compatible = "realtek,pymparticle", "realtek,rtd1319"; + model = "Realtek PymParticle EVB"; + + memory@0 { + device_type = "memory"; + reg = <0x0 0x80000000>; + }; + + chosen { + stdout-path = "serial0:460800n8"; + }; + + aliases { + serial0 = &uart0; + serial1 = &uart1; + serial2 = &uart2; + }; +}; + +/* debug console (J1) */ +&uart0 { + status = "okay"; +}; + +/* M.2 slot (CON8) */ +&uart1 { + status = "disabled"; +}; + +/* GPIO connector (T1) */ +&uart2 { + status = "disabled"; +}; diff --git a/arch/arm64/boot/dts/realtek/rtd1319.dtsi b/arch/arm64/boot/dts/realtek/rtd1319.dtsi new file mode 100644 index 000000000000..1dcee00009cd --- /dev/null +++ b/arch/arm64/boot/dts/realtek/rtd1319.dtsi @@ -0,0 +1,12 @@ +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) +/* + * Realtek RTD1319 SoC + * + * Copyright (c) 2019 Realtek Semiconductor Corp. + */ + +#include "rtd13xx.dtsi" + +/ { + compatible = "realtek,rtd1319"; +}; diff --git a/arch/arm64/boot/dts/realtek/rtd13xx.dtsi b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi new file mode 100644 index 000000000000..92bf962377f6 --- /dev/null +++ b/arch/arm64/boot/dts/realtek/rtd13xx.dtsi @@ -0,0 +1,137 @@ +// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) +/* + * Realtek RTD13xx SoC family + * + * Copyright (c) 2019 Realtek Semiconductor Corp. + */ + +#include <dt-bindings/interrupt-controller/arm-gic.h> +#include <dt-bindings/interrupt-controller/irq.h> + +/ { + interrupt-parent = <&gic>; + #address-cells = <1>; + #size-cells = <1>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + reg = <0x0>; + enable-method = "psci"; + next-level-cache = <&l2>; + }; + + cpu1: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + reg = <0x100>; + enable-method = "psci"; + next-level-cache = <&l2>; + }; + + cpu2: cpu@200 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + reg = <0x200>; + enable-method = "psci"; + next-level-cache = <&l2>; + }; + + cpu3: cpu@300 { + device_type = "cpu"; + compatible = "arm,cortex-a55"; + reg = <0x300>; + enable-method = "psci"; + next-level-cache = <&l2>; + }; + + l2: l2-cache { + compatible = "cache"; + }; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; + }; + + arm_pmu: pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>; + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, + <&cpu3>; + }; + + psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; + + osc27M: osc { + compatible = "fixed-clock"; + clock-frequency = <27000000>; + clock-output-names = "osc27M"; + #clock-cells = <0>; + }; + + soc { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x98000000 0x98000000 0x68000000>; + + rbus: bus@98000000 { + compatible = "simple-bus"; + reg = <0x98000000 0x200000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x98000000 0x200000>; + + uart0: serial0@7800 { + compatible = "snps,dw-apb-uart"; + reg = <0x7800 0x400>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <432000000>; + status = "disabled"; + }; + + uart1: serial1@1b200 { + compatible = "snps,dw-apb-uart"; + reg = <0x1b200 0x400>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <432000000>; + status = "disabled"; + }; + + uart2: serial2@1b400 { + compatible = "snps,dw-apb-uart"; + reg = <0x1b400 0x400>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <432000000>; + status = "disabled"; + }; + }; + + gic: interrupt-controller@ff100000 { + compatible = "arm,gic-v3"; + reg = <0xff100000 0x10000>, + <0xff140000 0xc0000>; + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <3>; + }; + }; +};
Add Device Trees for Realtek RTD1319 SoC family, RTD1319 SoC and Realtek PymParticle EVB. Signed-off-by: James Tai <james.tai@realtek.com> --- arch/arm64/boot/dts/realtek/Makefile | 2 + .../boot/dts/realtek/rtd1319-pymparticle.dts | 43 ++++++ arch/arm64/boot/dts/realtek/rtd1319.dtsi | 12 ++ arch/arm64/boot/dts/realtek/rtd13xx.dtsi | 137 ++++++++++++++++++ 4 files changed, 194 insertions(+) create mode 100644 arch/arm64/boot/dts/realtek/rtd1319-pymparticle.dts create mode 100644 arch/arm64/boot/dts/realtek/rtd1319.dtsi create mode 100644 arch/arm64/boot/dts/realtek/rtd13xx.dtsi