| Message ID | 1414153221-13104-1-git-send-email-suravee.suthikulpanit@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 24.10.14 14:20, suravee.suthikulpanit@amd.com wrote: > From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> > > Initial revision of device tree for AMD Seattle platform > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Will Deacon <will.deacon@arm.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Rob Herring <robh+dt@kernel.org> > Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> > Signed-off-by: Thomas Lendacky <Thomas.Lendacky@amd.com> > Signed-off-by: Joel Schopp <Joel.Schopp@amd.com> > --- > arch/arm64/Kconfig | 5 + > arch/arm64/boot/dts/Makefile | 1 + > arch/arm64/boot/dts/amd-seattle-periph.dtsi | 164 ++++++++++++++++++++++++++++ > arch/arm64/boot/dts/amd-seattle.dts | 126 +++++++++++++++++++++ > 4 files changed, 296 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 48b7437..e4c052f 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -137,6 +137,11 @@ source "kernel/Kconfig.freezer" > > menu "Platform selection" > > +config ARCH_SEATTLE > + bool "AMD Seattle SoC Family" > + help > + This enables support for AMD Seattle SOC Family > + > config ARCH_THUNDER > bool "Cavium Inc. Thunder SoC Family" > help > diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile > index f8001a6..6c27047 100644 > --- a/arch/arm64/boot/dts/Makefile > +++ b/arch/arm64/boot/dts/Makefile > @@ -1,6 +1,7 @@ > dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb > dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb > +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb This option doesn't exist in upstream kernels, does it? Why not just make it dtb-y? Alex
Am 26.10.2014 um 01:08 schrieb Alexander Graf: > On 24.10.14 14:20, suravee.suthikulpanit@amd.com wrote: >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 48b7437..e4c052f 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -137,6 +137,11 @@ source "kernel/Kconfig.freezer" >> >> menu "Platform selection" >> >> +config ARCH_SEATTLE >> + bool "AMD Seattle SoC Family" >> + help >> + This enables support for AMD Seattle SOC Family >> + >> config ARCH_THUNDER >> bool "Cavium Inc. Thunder SoC Family" >> help >> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile >> index f8001a6..6c27047 100644 >> --- a/arch/arm64/boot/dts/Makefile >> +++ b/arch/arm64/boot/dts/Makefile >> @@ -1,6 +1,7 @@ >> dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb >> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb >> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb >> +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb > > This option doesn't exist in upstream kernels, does it? Why not just > make it dtb-y? CONFIG_ARCH_SEATTLE is being added one hunk above. :) Cheers, Andreas
> Am 26.10.2014 um 13:43 schrieb Andreas Färber <afaerber@suse.de>: > >> Am 26.10.2014 um 01:08 schrieb Alexander Graf: >>> On 24.10.14 14:20, suravee.suthikulpanit@amd.com wrote: >>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >>> index 48b7437..e4c052f 100644 >>> --- a/arch/arm64/Kconfig >>> +++ b/arch/arm64/Kconfig >>> @@ -137,6 +137,11 @@ source "kernel/Kconfig.freezer" >>> >>> menu "Platform selection" >>> >>> +config ARCH_SEATTLE >>> + bool "AMD Seattle SoC Family" >>> + help >>> + This enables support for AMD Seattle SOC Family >>> + >>> config ARCH_THUNDER >>> bool "Cavium Inc. Thunder SoC Family" >>> help >>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile >>> index f8001a6..6c27047 100644 >>> --- a/arch/arm64/boot/dts/Makefile >>> +++ b/arch/arm64/boot/dts/Makefile >>> @@ -1,6 +1,7 @@ >>> dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb >>> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb >>> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb >>> +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb >> >> This option doesn't exist in upstream kernels, does it? Why not just >> make it dtb-y? > > CONFIG_ARCH_SEATTLE is being added one hunk above. :) Oops :). I'm not convinced we need a config option just for the sake of compiling a device tree though. Alex
Hi, Am 24.10.2014 um 14:20 schrieb suravee.suthikulpanit@amd.com: > diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile > index f8001a6..6c27047 100644 > --- a/arch/arm64/boot/dts/Makefile > +++ b/arch/arm64/boot/dts/Makefile > @@ -1,6 +1,7 @@ > dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb > dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb > +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb It seems these lines are sorted alphabetically, so Seattle should go somewhere before Thunder. > > targets += dtbs > targets += $(dtb-y) Regards, Andreas
Hi Suravee, [...] > dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb > dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb > dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb > +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb This should move earlier in the list (to keep things organised alphabetically). [...] > + v2m_serial0: uart@1010000 { Drop the "v2m_" prefix -- in other dts that refers to a Versatile Express ?ATX motherboard (the V2M-P1), and this isn't a Versatile Express. Also, I believe the preferred node name is "serial" rather than "uart". [...] > + chosen { > + linux,stdout-path = "console=ttyAMA0,115200 earlycon=pl011,0xe1010000"; The stdout-path property should just be a path to the UART node. It's not a direct replacement for /chosen/bootargs. This should be (assuming you fix up the label above): stdout-path = &serial0; That will give us earlycon if "earlycon" (with no arguments) is provided on the command line, and should set up that UART as the console. There's no need for the "linux," prefix now either. Unfortuantely, I believe that the UART rate will get changed when the real PL011 driver registers, unless the rate is explicitly provided on the command line. It might be worth looking into retaining the configured rate somehow indepentent of bootargs (unless overriden). Thanks, Mark.
On 10/26/2014 9:08 AM, Alexander Graf wrote: >>> This option doesn't exist in upstream kernels, does it? Why not just >>> >>make it dtb-y? >> > >> >CONFIG_ARCH_SEATTLE is being added one hunk above.:) > Oops:). > > I'm not convinced we need a config option just for the sake of compiling a device tree though. > > > Alex > Eventually, we would add other device driver selections when CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready. Suravee
On 10/26/2014 9:09 AM, Andreas Färber wrote: > Hi, > > Am 24.10.2014 um 14:20 schrieb suravee.suthikulpanit@amd.com: >> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile >> index f8001a6..6c27047 100644 >> --- a/arch/arm64/boot/dts/Makefile >> +++ b/arch/arm64/boot/dts/Makefile >> @@ -1,6 +1,7 @@ >> dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb >> dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb >> dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb >> +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb > > It seems these lines are sorted alphabetically, so Seattle should go > somewhere before Thunder. > >> >> targets += dtbs >> targets += $(dtb-y) > > Regards, > Andreas > Ah.. right. I'll fix this and send out V2. Suravee
On 10/27/2014 8:50 AM, Mark Rutland wrote: > Hi Suravee, > > [...] > >> + chosen { >> + linux,stdout-path = "console=ttyAMA0,115200 earlycon=pl011,0xe1010000"; > > The stdout-path property should just be a path to the UART node. It's > not a direct replacement for /chosen/bootargs. > > This should be (assuming you fix up the label above): > > stdout-path = &serial0; > > That will give us earlycon if "earlycon" (with no arguments) is provided > on the command line, and should set up that UART as the console. There's > no need for the "linux," prefix now either. > > Unfortuantely, I believe that the UART rate will get changed when the > real PL011 driver registers, unless the rate is explicitly provided on > the command line. It might be worth looking into retaining the > configured rate somehow indepentent of bootargs (unless overriden). Thanks for the explanation. I think I should be able to get rid of the "console=ttyAMA0,115200 earlycon=pl011,0xe1010000" altogether. I'll send out V2 soon. Thanks, Suravee > Thanks, > Mark. >
On 27.10.14 15:29, Suravee Suthikulanit wrote: > On 10/26/2014 9:08 AM, Alexander Graf wrote: >>>> This option doesn't exist in upstream kernels, does it? Why not just >>>> >>make it dtb-y? >>> > >>> >CONFIG_ARCH_SEATTLE is being added one hunk above.:) >> Oops:). >> >> I'm not convinced we need a config option just for the sake of >> compiling a device tree though. >> >> >> Alex >> > > Eventually, we would add other device driver selections when > CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready. Could you please give me some examples of drivers that would depend on CONFIG_ARCH_SEATTLE? I like the current way things work without the need for such an option, where everything's implemented purely as drivers you can opt in our out of. You don't have a CONFIG_ARCH_SB7XX on x86 either, right? ;) Alex
On 10/27/2014 6:25 PM, Alexander Graf wrote: > > > On 27.10.14 15:29, Suravee Suthikulanit wrote: >> On 10/26/2014 9:08 AM, Alexander Graf wrote: >>>>> This option doesn't exist in upstream kernels, does it? Why not just >>>>>>> make it dtb-y? >>>>> >>>>> CONFIG_ARCH_SEATTLE is being added one hunk above.:) >>> Oops:). >>> >>> I'm not convinced we need a config option just for the sake of >>> compiling a device tree though. >>> >>> >>> Alex >>> >> >> Eventually, we would add other device driver selections when >> CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready. > > Could you please give me some examples of drivers that would depend on > CONFIG_ARCH_SEATTLE? I like the current way things work without the need > for such an option, where everything's implemented purely as drivers you > can opt in our out of. > > You don't have a CONFIG_ARCH_SB7XX on x86 either, right? ;) > > > Alex > I am not saying that device drivers need to depend on CONFIG_ARCH_SEATTLE. I am thinking along the line of an easy way to enable SOC without having to manually select each of the required drivers to support the SOC. An example is the "ARCH_VEXPRESS". Suravee
> Am 28.10.2014 um 14:07 schrieb Suravee Suthikulanit <suravee.suthikulpanit@amd.com>: > >> On 10/27/2014 6:25 PM, Alexander Graf wrote: >> >> >>> On 27.10.14 15:29, Suravee Suthikulanit wrote: >>> On 10/26/2014 9:08 AM, Alexander Graf wrote: >>>>>> This option doesn't exist in upstream kernels, does it? Why not just >>>>>>>> make it dtb-y? >>>>>> >>>>>> CONFIG_ARCH_SEATTLE is being added one hunk above.:) >>>> Oops:). >>>> >>>> I'm not convinced we need a config option just for the sake of >>>> compiling a device tree though. >>>> >>>> >>>> Alex >>>> >>> >>> Eventually, we would add other device driver selections when >>> CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready. >> >> Could you please give me some examples of drivers that would depend on >> CONFIG_ARCH_SEATTLE? I like the current way things work without the need >> for such an option, where everything's implemented purely as drivers you >> can opt in our out of. >> >> You don't have a CONFIG_ARCH_SB7XX on x86 either, right? ;) >> >> >> Alex >> > > I am not saying that device drivers need to depend on CONFIG_ARCH_SEATTLE. I am thinking along the line of an easy way to enable SOC without having to manually select each of the required drivers to support the SOC. An example is the "ARCH_VEXPRESS". Works for me, but then please don't make anything depend on CONFIG_ARCH_SEATTLE. Everything you need for seattle support should be possible to select without the easy enable switch until we see a good reason to have one ;). So in this particular case, we shouldn't build the device tree depending on CONFIG_ARCH_SEATTLE but rather slways which again means the switch does not need to get introduced by this patch ;) But at the end of the day, this is Catalin's subsystem and his opinion counts more than mine. Catalin, do you have strong feelings in any direction here? Alex
On Tue, Oct 28, 2014 at 01:07:49PM +0000, Suravee Suthikulanit wrote: > On 10/27/2014 6:25 PM, Alexander Graf wrote: > > > > > > On 27.10.14 15:29, Suravee Suthikulanit wrote: > >> On 10/26/2014 9:08 AM, Alexander Graf wrote: > >>>>> This option doesn't exist in upstream kernels, does it? Why not just > >>>>>>> make it dtb-y? > >>>>> > >>>>> CONFIG_ARCH_SEATTLE is being added one hunk above.:) > >>> Oops:). > >>> > >>> I'm not convinced we need a config option just for the sake of > >>> compiling a device tree though. > >>> > >>> > >>> Alex > >>> > >> > >> Eventually, we would add other device driver selections when > >> CONFIG_ARCH_SEATTLE=y. At this point, those drivers are still not ready. > > > > Could you please give me some examples of drivers that would depend on > > CONFIG_ARCH_SEATTLE? I like the current way things work without the need > > for such an option, where everything's implemented purely as drivers you > > can opt in our out of. > > > > You don't have a CONFIG_ARCH_SB7XX on x86 either, right? ;) > > > > > > Alex > > > > I am not saying that device drivers need to depend on > CONFIG_ARCH_SEATTLE. I am thinking along the line of an easy way to > enable SOC without having to manually select each of the required > drivers to support the SOC. An example is the "ARCH_VEXPRESS". ARCH_VEXPRESS is an historical artifact and we have discussed a few times internally in ARM to remove it as it brings no value until some other platform can't work with the default options comes in. I agree with Alexander here, I think the device tree should be compiled in regardless. One reason for it is because it will make it easier to dis-entangle the .dt{s,b} files from the tree in the future and have them hosted in a different place. Best regards, Liviu > > Suravee > >
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 48b7437..e4c052f 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -137,6 +137,11 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_SEATTLE + bool "AMD Seattle SoC Family" + help + This enables support for AMD Seattle SOC Family + config ARCH_THUNDER bool "Cavium Inc. Thunder SoC Family" help diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index f8001a6..6c27047 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -1,6 +1,7 @@ dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb +dtb-$(CONFIG_ARCH_SEATTLE) += amd-seattle.dtb targets += dtbs targets += $(dtb-y) diff --git a/arch/arm64/boot/dts/amd-seattle-periph.dtsi b/arch/arm64/boot/dts/amd-seattle-periph.dtsi new file mode 100644 index 0000000..273b7fc --- /dev/null +++ b/arch/arm64/boot/dts/amd-seattle-periph.dtsi @@ -0,0 +1,164 @@ +/* + * DTS file for AMD Seattle Peripheral + * + * Copyright (C) 2014 Advanced Micro Devices, Inc. + */ + +motherboard { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + adl3clk_100mhz: clk100mhz_0 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <100000000>; + clock-output-names = "adl3clk_100mhz"; + }; + + ccpclk_375mhz: clk375mhz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <375000000>; + clock-output-names = "ccpclk_375mhz"; + }; + + sataclk_333mhz: clk333mhz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <333000000>; + clock-output-names = "sataclk_333mhz"; + }; + + pcieclk_500mhz: clk500mhz_0 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <500000000>; + clock-output-names = "pcieclk_500mhz"; + }; + + dmaclk_500mhz: clk500mhz_1 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <500000000>; + clock-output-names = "dmaclk_500mhz"; + }; + + miscclk_250mhz: clk250mhz_4 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <250000000>; + clock-output-names = "miscclk_250mhz"; + }; + + uartspiclk_100mhz: clk100mhz_1 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <100000000>; + clock-output-names = "uartspiclk_100mhz"; + }; + + dma0: dma@0500000 { + compatible = "arm,pl330", "arm,primecell"; + reg = <0 0x0500000 0 0x1000>; + interrupts = + <0 368 4>, + <0 369 4>, + <0 370 4>, + <0 371 4>, + <0 372 4>, + <0 373 4>, + <0 374 4>, + <0 375 4>; + clocks = <&dmaclk_500mhz>; + clock-names = "apb_pclk"; + #dma-cells = <1>; + }; + + sata0: sata@00300000 { + compatible = "snps,spear-ahci"; + reg = <0 0x300000 0 0x800>; + interrupts = <0 355 4>; + clocks = <&sataclk_333mhz>; + clock-names = "apb_pclk"; + dma-coherent; + }; + + i2c@1000000 { + compatible = "snps,designware-i2c"; + reg = <0 0x01000000 0 0x1000>; + interrupts = <0 357 4>; + clocks = <&uartspiclk_100mhz>; + clock-names = "apb_pclk"; + }; + + v2m_serial0: uart@1010000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0 0x1010000 0 0x1000>; + interrupts = <0 328 4>; + clocks = <&uartspiclk_100mhz>, <&uartspiclk_100mhz>; + clock-names = "uartclk", "apb_pclk"; + }; + + ssp@1020000 { + compatible = "arm,pl022", "arm,primecell"; + #gpio-cells = <2>; + reg = <0 0x1020000 0 0x1000>; + spi-controller; + interrupts = <0 330 4>; + clocks = <&uartspiclk_100mhz>; + clock-names = "apb_pclk"; + }; + + ssp@1030000 { + compatible = "arm,pl022", "arm,primecell"; + #gpio-cells = <2>; + reg = <0 0x1030000 0 0x1000>; + spi-controller; + interrupts = <0 329 4>; + clocks = <&uartspiclk_100mhz>; + clock-names = "apb_pclk"; + num-cs = <1>; + #address-cells = <1>; + #size-cells = <0>; + + sdcard@0 { + compatible = "mmc-spi-slot"; + reg = <0>; + spi-max-frequency = <20000000>; + pl022,hierarchy = <0>; + pl022,interface = <0>; + pl022,com-mode = <0x0>; + pl022,rx-level-trig = <0>; + pl022,tx-level-trig = <0>; + }; + }; + + gpio0: gpio@1040000 { + compatible = "arm,pl061", "arm,primecell"; + #gpio-cells = <2>; + reg = <0 0x1040000 0 0x1000>; + gpio-controller; + interrupts = <0 359 4>; + clocks = <&uartspiclk_100mhz>; + clock-names = "apb_pclk"; + }; + + gpio1: gpio@1050000 { + compatible = "arm,pl061", "arm,primecell"; + #gpio-cells = <2>; + reg = <0 0x1050000 0 0x1000>; + gpio-controller; + interrupts = <0 358 4>; + clocks = <&uartspiclk_100mhz>; + clock-names = "apb_pclk"; + }; + + ccp: ccp@00100000 { + compatible = "amd,ccp-seattle-v1a"; + reg = <0 0x00100000 0 0x10000>; + interrupts = <0 3 4>; + dma-coherent; + }; +}; diff --git a/arch/arm64/boot/dts/amd-seattle.dts b/arch/arm64/boot/dts/amd-seattle.dts new file mode 100644 index 0000000..2988637 --- /dev/null +++ b/arch/arm64/boot/dts/amd-seattle.dts @@ -0,0 +1,126 @@ +/* + * DTS file for AMD Seattle + * + * Copyright (C) 2014 Advanced Micro Devices, Inc. + */ + +/dts-v1/; + +/ { + compatible = "amd,seattle"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + chosen { + linux,stdout-path = "console=ttyAMA0,115200 earlycon=pl011,0xe1010000"; + linux,pci-probe-only; + }; + + aliases { + serial0 = &v2m_serial0; + }; + + gic: interrupt-controller@e1101000 { + compatible = "arm,gic-400", "arm,cortex-a15-gic"; + interrupt-controller; + #interrupt-cells = <3>; + #address-cells = <2>; + #size-cells = <2>; + reg = <0x0 0xe1110000 0 0x1000>, + <0x0 0xe112f000 0 0x2000>, + <0x0 0xe1140000 0 0x10000>, + <0x0 0xe1160000 0 0x10000>; + interrupts = <1 8 0xf04>; + ranges; + v2m0: v2m@e1180000 { + compatible = "arm,gic-v2m-frame"; + msi-controller; + arm,msi-base-spi = <64>; + arm,msi-num-spis = <256>; + reg = <0x0 0xe1180000 0 0x1000>; + }; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0xff01>, + <1 14 0xff01>, + <1 11 0xff01>, + <1 10 0xff01>; + }; + + pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <0 7 4>, + <0 8 4>, + <0 9 4>, + <0 10 4>, + <0 11 4>, + <0 12 4>, + <0 13 4>, + <0 14 4>; + }; + + /* This entry is modified by UEFI */ + pcie0: pcie-controller{ + compatible = "pci-host-ecam-generic"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + bus-range = <0 0xff>; + reg = <0 0xf0000000 0 0x10000000>; + dma-coherent; + msi-parent = <&v2m0>; + + interrupts = + <0 320 4>, /* ioc_soc_serr */ + <0 321 4>; /* ioc_soc_sci */ + + ranges = + /* I/O Memory (size=64K) */ + <0x01000000 0x00 0xefff0000 0x00 0xefff0000 0x00 0x00010000>, + + /* Non-Pref 32-bit MMIO (size=512M) */ + <0x02000000 0x00 0x40000000 0x00 0x40000000 0x00 0x20000000>, + + /* Non-Pref 32-bit MMIO (size=512M) */ + <0x02000000 0x00 0x60000000 0x00 0x60000000 0x00 0x20000000>, + + /* Non-Pref 32-bit MMIO (size=512M) */ + <0x02000000 0x00 0x80000000 0x00 0x80000000 0x00 0x20000000>, + + /* Non-Pref 32-bit MMIO (size=512M) */ + <0x02000000 0x00 0xa0000000 0x00 0xa0000000 0x00 0x20000000>, + + /* Pref 64-bit MMIO (size= 4G) */ + <0x43000000 0x01 0x00000000 0x01 0x00000000 0x01 0x00000000>, + + /* Pref 64-bit MMIO (size= 8G) */ + <0x43000000 0x02 0x00000000 0x02 0x00000000 0x02 0x00000000>, + + /* Pref 64-bit MMIO (size=16G) */ + <0x43000000 0x04 0x00000000 0x04 0x00000000 0x04 0x00000000>, + + /* Pref 64-bit MMIO (size=32G) */ + <0x43000000 0x08 0x00000000 0x08 0x00000000 0x08 0x00000000>, + + /* Pref 64-bit MMIO (size=64G) */ + <0x43000000 0x10 0x00000000 0x10 0x00000000 0x10 0x00000000>, + + /* Pref 64-bit MMIO (size=128G) */ + <0x43000000 0x20 0x00000000 0x20 0x00000000 0x20 0x00000000>, + + /* Pref 64-bit MMIO (size=256G) */ + <0x43000000 0x40 0x00000000 0x40 0x00000000 0x40 0x00000000>; + }; + + smb { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges = <0 0 0 0xE0000000 0 0x01300000>; + + /include/ "amd-seattle-periph.dtsi" + }; +};