| Message ID | 1409219706-14843-5-git-send-email-bhupesh.sharma@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Bhupesh, This looks generally good, I just have a few questions and minor change suggestions below. On Thu, Aug 28, 2014 at 10:55:04AM +0100, Bhupesh Sharma wrote: > This patch adds the device tree support for FSL LS2085A SoC > based on ARMv8 architecture. > > Following levels of DTSI/DTS files have been created for the > LS2085A SoC family: > > - fsl-ls2085a.dtsi: > DTS-Include file for FSL LS2085A SoC. > > - fsl-ls2085a-simu.dts: > DTS file for FSL LS2085a software simulator model. > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> > Signed-off-by: Arnab Basu <arnab.basu@freescale.com> > Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com> > --- > arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 26 +++++++ > arch/arm64/boot/dts/fsl-ls2085a.dtsi | 120 ++++++++++++++++++++++++++++++ > 2 files changed, 146 insertions(+) > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi > > diff --git a/arch/arm64/boot/dts/fsl-ls2085a-simu.dts b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts > new file mode 100644 > index 0000000..3c0f953 > --- /dev/null > +++ b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts > @@ -0,0 +1,26 @@ > +/* > + * Device Tree file for Freescale LS2085a software Simulator model > + * > + * Copyright (C) 2014, Freescale Semiconductor > + * > + * Bhupesh Sharma <bhupesh.sharma@freescale.com> > + * > + * This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without any > + * warranty of any kind, whether express or implied. > + */ > + > +/dts-v1/; > + > +/include/ "fsl-ls2085a.dtsi" > + > +/ { > + model = "Freescale Layerscape 2085a software Simulator model"; > + compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; > + > + ethernet@2210000 { > + compatible = "smsc,lan91c111"; > + reg = <0x0 0x2210000 0x0 0x100>; > + interrupts = <0 58 0x1>; > + }; > +}; > diff --git a/arch/arm64/boot/dts/fsl-ls2085a.dtsi b/arch/arm64/boot/dts/fsl-ls2085a.dtsi > new file mode 100644 > index 0000000..a1692c2 > --- /dev/null > +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi > @@ -0,0 +1,120 @@ > +/* > + * Device Tree Include file for Freescale Layerscape-2085A family SoC. > + * > + * Copyright (C) 2014, Freescale Semiconductor > + * > + * Bhupesh Sharma <bhupesh.sharma@freescale.com> > + * > + * This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without any > + * warranty of any kind, whether express or implied. > + */ > + > +/ { > + compatible = "fsl,ls2085a"; > + interrupt-parent = <&gic>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x0>; > + }; > + > + cpu@1 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x1>; > + }; > + > + cpu@100 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x100>; > + }; > + > + cpu@101 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x101>; > + }; > + > + cpu@200 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x200>; > + }; > + > + cpu@201 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x201>; > + }; > + > + cpu@300 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x300>; > + }; > + > + cpu@301 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x301>; > + }; > + }; > + > + gic: interrupt-controller@6000000 { > + compatible = "arm,gic-v3"; > + reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */ > + <0x0 0x06100000 0 0x100000>; /* GICR (RD_base + SGI_base) */ > + #interrupt-cells = <3>; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + interrupt-controller; > + interrupts = <1 9 0x4>; > + }; The GIC node doesn't have any sub-nodes, so I think the #address-cells, #size-cells, and ranges properties can go for now. > + > + timer { > + compatible = "arm,armv8-timer"; > + interrupts = <1 13 0x1>, /* Physical Secure PPI, edge triggered */ > + <1 14 0x1>, /* Physical Non-Secure PPI, edge triggered */ > + <1 11 0x1>, /* Virtual PPI, edge triggered */ > + <1 10 0x1>; /* Hypervisor PPI, edge triggered */ > + }; In this SoC, are there low-power states the CPUs can be placed into where the architected timers can lose state? If so, do you any auxiliary timers that aren't cpu-local? > + > + serial0: serial@21c0500 { > + device_type = "serial"; > + compatible = "fsl,ns16550", "ns16550a"; > + reg = <0x0 0x21c0500 0x0 0x100>; > + clock-frequency = <0>; /* Updated by bootloader */ > + interrupts = <0 32 0x1>; /* edge triggered */ > + }; > + > + serial1: serial@21c0600 { > + device_type = "serial"; > + compatible = "fsl,ns16550", "ns16550a"; > + reg = <0x0 0x21c0600 0x0 0x100>; > + clock-frequency = <0>; /* Updated by bootloader */ > + interrupts = <0 32 0x1>; /* edge triggered */ > + }; Just to check: do the two UARTs share the same IRQ, or is that a copy-paste error? > + > + fsl_mc: fsl-mc@80c000000 { > + compatible = "fsl,qoriq-mc"; > + reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ > + <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > + }; Nit: the '}' is indented a tab too far. > + > + memory@80000000 { > + device_type = "memory"; > + reg = <0x00000000 0x80000000 0 0x80000000>; > + /* DRAM space 1 - 2 GB DRAM */ > + }; Does that mean: - This is "DRAM space 1", populated with 2GB? Or: - The DRAM space can be populated with 1 to 2 GB? If the former, s/ - /: / for clarity. If the latter, it might make sense to move that into board-specific dts files. If this can be dynamically populated ideally the firmware/loader would fix this up (assuming it can probe the memory). Also, can we move the memory node up to just after /cpus? That would match the other dts files we have. Cheers, Mark.
Hi Mark, Thanks for your review. Please see my comments inline. > -----Original Message----- > From: Mark Rutland [mailto:mark.rutland@arm.com] > Sent: Thursday, August 28, 2014 8:27 PM > To: Sharma Bhupesh-B45370 > Cc: Catalin Marinas; Will Deacon; arnd@arndb.de; > grant.likely@secretlab.ca; Marc Zyngier; rob.herring@linaro.org; linux- > arm-kernel@lists.infradead.org; Yoder Stuart-B08248; Basu Arnab-B45036 > Subject: Re: [PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > Hi Bhupesh, > > This looks generally good, I just have a few questions and minor change > suggestions below. > > On Thu, Aug 28, 2014 at 10:55:04AM +0100, Bhupesh Sharma wrote: > > This patch adds the device tree support for FSL LS2085A SoC based on > > ARMv8 architecture. > > > > Following levels of DTSI/DTS files have been created for the LS2085A > > SoC family: > > > > - fsl-ls2085a.dtsi: > > DTS-Include file for FSL LS2085A SoC. > > > > - fsl-ls2085a-simu.dts: > > DTS file for FSL LS2085a software simulator model. > > > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com> > > Signed-off-by: Arnab Basu <arnab.basu@freescale.com> > > Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com> > > --- > > arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 26 +++++++ > > arch/arm64/boot/dts/fsl-ls2085a.dtsi | 120 > ++++++++++++++++++++++++++++++ > > 2 files changed, 146 insertions(+) > > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts > > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi > > > > diff --git a/arch/arm64/boot/dts/fsl-ls2085a-simu.dts > > b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts > > new file mode 100644 > > index 0000000..3c0f953 > > --- /dev/null > > +++ b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts > > @@ -0,0 +1,26 @@ > > +/* > > + * Device Tree file for Freescale LS2085a software Simulator model > > + * > > + * Copyright (C) 2014, Freescale Semiconductor > > + * > > + * Bhupesh Sharma <bhupesh.sharma@freescale.com> > > + * > > + * This file is licensed under the terms of the GNU General Public > > + * License version 2. This program is licensed "as is" without any > > + * warranty of any kind, whether express or implied. > > + */ > > + > > +/dts-v1/; > > + > > +/include/ "fsl-ls2085a.dtsi" > > + > > +/ { > > + model = "Freescale Layerscape 2085a software Simulator model"; > > + compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; > > + > > + ethernet@2210000 { > > + compatible = "smsc,lan91c111"; > > + reg = <0x0 0x2210000 0x0 0x100>; > > + interrupts = <0 58 0x1>; > > + }; > > +}; > > diff --git a/arch/arm64/boot/dts/fsl-ls2085a.dtsi > > b/arch/arm64/boot/dts/fsl-ls2085a.dtsi > > new file mode 100644 > > index 0000000..a1692c2 > > --- /dev/null > > +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi > > @@ -0,0 +1,120 @@ > > +/* > > + * Device Tree Include file for Freescale Layerscape-2085A family SoC. > > + * > > + * Copyright (C) 2014, Freescale Semiconductor > > + * > > + * Bhupesh Sharma <bhupesh.sharma@freescale.com> > > + * > > + * This file is licensed under the terms of the GNU General Public > > + * License version 2. This program is licensed "as is" without any > > + * warranty of any kind, whether express or implied. > > + */ > > + > > +/ { > > + compatible = "fsl,ls2085a"; > > + interrupt-parent = <&gic>; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > + > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > + cpu@0 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x0>; > > + }; > > + > > + cpu@1 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x1>; > > + }; > > + > > + cpu@100 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x100>; > > + }; > > + > > + cpu@101 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x101>; > > + }; > > + > > + cpu@200 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x200>; > > + }; > > + > > + cpu@201 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x201>; > > + }; > > + > > + cpu@300 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x300>; > > + }; > > + > > + cpu@301 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x301>; > > + }; > > + }; > > + > > + gic: interrupt-controller@6000000 { > > + compatible = "arm,gic-v3"; > > + reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */ > > + <0x0 0x06100000 0 0x100000>; /* GICR (RD_base + > SGI_base) */ > > + #interrupt-cells = <3>; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > + interrupt-controller; > > + interrupts = <1 9 0x4>; > > + }; > > The GIC node doesn't have any sub-nodes, so I think the #address-cells, > #size-cells, and ranges properties can go for now. Ok. V3 will address the change. > > > + > > + timer { > > + compatible = "arm,armv8-timer"; > > + interrupts = <1 13 0x1>, /* Physical Secure PPI, edge > triggered */ > > + <1 14 0x1>, /* Physical Non-Secure PPI, edge > triggered */ > > + <1 11 0x1>, /* Virtual PPI, edge triggered */ > > + <1 10 0x1>; /* Hypervisor PPI, edge triggered */ > > + }; > > In this SoC, are there low-power states the CPUs can be placed into where > the architected timers can lose state? Yes the SoC has low-power states, however we are yet to work on the power management s/w layers. Probably a patch later down the lane would add this capability. > > If so, do you any auxiliary timers that aren't cpu-local? Yes, the SoC has 4 flextimer IP instances, but I am yet to test them and hence support for them is still to be added. Probably a patch later down the lane would add this capability. > > > + > > + serial0: serial@21c0500 { > > + device_type = "serial"; > > + compatible = "fsl,ns16550", "ns16550a"; > > + reg = <0x0 0x21c0500 0x0 0x100>; > > + clock-frequency = <0>; /* Updated by bootloader */ > > + interrupts = <0 32 0x1>; /* edge triggered */ > > + }; > > + > > + serial1: serial@21c0600 { > > + device_type = "serial"; > > + compatible = "fsl,ns16550", "ns16550a"; > > + reg = <0x0 0x21c0600 0x0 0x100>; > > + clock-frequency = <0>; /* Updated by bootloader */ > > + interrupts = <0 32 0x1>; /* edge triggered */ > > + }; > > Just to check: do the two UARTs share the same IRQ, or is that a copy- > paste error? The two UARTs do share the same IRQ. > > > + > > + fsl_mc: fsl-mc@80c000000 { > > + compatible = "fsl,qoriq-mc"; > > + reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base > */ > > + <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ > > + }; > > Nit: the '}' is indented a tab too far. Oops. Ok. > > > + > > + memory@80000000 { > > + device_type = "memory"; > > + reg = <0x00000000 0x80000000 0 0x80000000>; > > + /* DRAM space 1 - 2 GB DRAM */ > > + }; > > Does that mean: > > - This is "DRAM space 1", populated with 2GB? > > Or: > > - The DRAM space can be populated with 1 to 2 GB? > > If the former, s/ - /: / for clarity. > > If the latter, it might make sense to move that into board-specific dts > files. If this can be dynamically populated ideally the firmware/loader > would fix this up (assuming it can probe the memory). If the former. I will fix it up in v3. > > Also, can we move the memory node up to just after /cpus? That would > match the other dts files we have. Sure. V3 will address this change. Regards, Bhupesh > > Cheers, > Mark.
Hi Bhupesh, > > > + gic: interrupt-controller@6000000 { > > > + compatible = "arm,gic-v3"; > > > + reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */ > > > + <0x0 0x06100000 0 0x100000>; /* GICR (RD_base + > > SGI_base) */ > > > + #interrupt-cells = <3>; > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > + ranges; > > > + interrupt-controller; > > > + interrupts = <1 9 0x4>; > > > + }; > > > > The GIC node doesn't have any sub-nodes, so I think the #address-cells, > > #size-cells, and ranges properties can go for now. > > Ok. V3 will address the change. Ok. > > > > > > + > > > + timer { > > > + compatible = "arm,armv8-timer"; > > > + interrupts = <1 13 0x1>, /* Physical Secure PPI, edge > > triggered */ > > > + <1 14 0x1>, /* Physical Non-Secure PPI, edge > > triggered */ > > > + <1 11 0x1>, /* Virtual PPI, edge triggered */ > > > + <1 10 0x1>; /* Hypervisor PPI, edge triggered */ > > > + }; > > > > In this SoC, are there low-power states the CPUs can be placed into where > > the architected timers can lose state? > > Yes the SoC has low-power states, however we are yet to work on the power management > s/w layers. Probably a patch later down the lane would add this capability. That's fine. I just want to make sure we're not in for some pain with timers at the moment. > > > > > If so, do you any auxiliary timers that aren't cpu-local? > > Yes, the SoC has 4 flextimer IP instances, but I am yet to test them and hence support for them > is still to be added. Probably a patch later down the lane would add this capability. Ok. You'll need at least one global timer if you want to place all CPUs into low power states. For now things should work regardless. [...] > > > + serial0: serial@21c0500 { > > > + device_type = "serial"; > > > + compatible = "fsl,ns16550", "ns16550a"; > > > + reg = <0x0 0x21c0500 0x0 0x100>; > > > + clock-frequency = <0>; /* Updated by bootloader */ > > > + interrupts = <0 32 0x1>; /* edge triggered */ > > > + }; > > > + > > > + serial1: serial@21c0600 { > > > + device_type = "serial"; > > > + compatible = "fsl,ns16550", "ns16550a"; > > > + reg = <0x0 0x21c0600 0x0 0x100>; > > > + clock-frequency = <0>; /* Updated by bootloader */ > > > + interrupts = <0 32 0x1>; /* edge triggered */ > > > + }; > > > > Just to check: do the two UARTs share the same IRQ, or is that a copy- > > paste error? > > The two UARTs do share the same IRQ. Ok. [...] > > > + memory@80000000 { > > > + device_type = "memory"; > > > + reg = <0x00000000 0x80000000 0 0x80000000>; > > > + /* DRAM space 1 - 2 GB DRAM */ > > > + }; > > > > Does that mean: > > > > - This is "DRAM space 1", populated with 2GB? > > > > Or: > > > > - The DRAM space can be populated with 1 to 2 GB? > > > > If the former, s/ - /: / for clarity. > > > > If the latter, it might make sense to move that into board-specific dts > > files. If this can be dynamically populated ideally the firmware/loader > > would fix this up (assuming it can probe the memory). > > If the former. I will fix it up in v3. Ok. Out of curiosity, are there other DRAM spaces that might be populated? > > Also, can we move the memory node up to just after /cpus? That would > > match the other dts files we have. > > Sure. V3 will address this change. Cheers. Mark.
Hi Mark, > -----Original Message----- > From: Mark Rutland [mailto:mark.rutland@arm.com] > Sent: Friday, August 29, 2014 11:18 PM > To: Sharma Bhupesh-B45370 > Cc: Catalin Marinas; Will Deacon; arnd@arndb.de; > grant.likely@secretlab.ca; Marc Zyngier; rob.herring@linaro.org; linux- > arm-kernel@lists.infradead.org; Yoder Stuart-B08248; Basu Arnab-B45036 > Subject: Re: [PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > Hi Bhupesh, > [snip..] > > > > + timer { > > > > + compatible = "arm,armv8-timer"; > > > > + interrupts = <1 13 0x1>, /* Physical Secure PPI, edge > > > triggered */ > > > > + <1 14 0x1>, /* Physical Non-Secure PPI, edge > > > triggered */ > > > > + <1 11 0x1>, /* Virtual PPI, edge triggered > */ > > > > + <1 10 0x1>; /* Hypervisor PPI, edge > triggered */ > > > > + }; > > > > > > In this SoC, are there low-power states the CPUs can be placed into > > > where the architected timers can lose state? > > > > Yes the SoC has low-power states, however we are yet to work on the > > power management s/w layers. Probably a patch later down the lane would > add this capability. > > That's fine. I just want to make sure we're not in for some pain with > timers at the moment. Sure. I have added the same to my To-do. > > > > > > > > If so, do you any auxiliary timers that aren't cpu-local? > > > > Yes, the SoC has 4 flextimer IP instances, but I am yet to test them > > and hence support for them is still to be added. Probably a patch later > down the lane would add this capability. > > Ok. You'll need at least one global timer if you want to place all CPUs > into low power states. For now things should work regardless. > > [...] [snip] > > > > > + memory@80000000 { > > > > + device_type = "memory"; > > > > + reg = <0x00000000 0x80000000 0 0x80000000>; > > > > + /* DRAM space 1 - 2 GB DRAM */ > > > > + }; > > > > > > Does that mean: > > > > > > - This is "DRAM space 1", populated with 2GB? > > > > > > Or: > > > > > > - The DRAM space can be populated with 1 to 2 GB? > > > > > > If the former, s/ - /: / for clarity. > > > > > > If the latter, it might make sense to move that into board-specific > > > dts files. If this can be dynamically populated ideally the > > > firmware/loader would fix this up (assuming it can probe the memory). > > > > If the former. I will fix it up in v3. > > Ok. Out of curiosity, are there other DRAM spaces that might be > populated? Yes there is another DRAM space. The 1st one is accessible within 32 bits and the 2nd one is accessible from 40-bit and above. However, I was waiting for the 4-level ARM64 page table patches (from Catalin) to get absorbed, as w/o the same we can access only a 39-bit PA and hence can have only 3-level page table limited to the 1st DRAM region (which is accessible via first 32 bits). Any idea, about the latest state of Catalin's patch ([1])? Has it made to linux-next? [1] http://lwn.net/Articles/606082/ [snip] Regards, Bhupesh
On Fri, Aug 29, 2014 at 07:07:40PM +0100, bhupesh.sharma@freescale.com wrote: > > > > > + memory@80000000 { > > > > > + device_type = "memory"; > > > > > + reg = <0x00000000 0x80000000 0 0x80000000>; > > > > > + /* DRAM space 1 - 2 GB DRAM */ > > > > > + }; > > > > > > > > Does that mean: > > > > > > > > - This is "DRAM space 1", populated with 2GB? > > > > > > > > Or: > > > > > > > > - The DRAM space can be populated with 1 to 2 GB? > > > > > > > > If the former, s/ - /: / for clarity. > > > > > > > > If the latter, it might make sense to move that into board-specific > > > > dts files. If this can be dynamically populated ideally the > > > > firmware/loader would fix this up (assuming it can probe the memory). > > > > > > If the former. I will fix it up in v3. > > > > Ok. Out of curiosity, are there other DRAM spaces that might be > > populated? > > Yes there is another DRAM space. The 1st one is accessible within 32 bits and > the 2nd one is accessible from 40-bit and above. However, I was waiting > for the 4-level ARM64 page table patches (from Catalin) to get absorbed, as w/o the > same we can access only a 39-bit PA and hence can have only 3-level page table limited > to the 1st DRAM region (which is accessible via first 32 bits). > > Any idea, about the latest state of Catalin's patch ([1])? Has it made to linux-next? The 48-bit VA support is in mainline but you wouldn't be able to enable it because KVM is still broken. Hopefully it will make it to 3.18-rc1. But here we are talking about 40-bit PA range which should be fine with 3 levels of page tables. The only problem is if you want to idmap the memory beyond 40-bit (I don't know whether UEFI requires this but for kernel booting you wouldn't need it since the kernel image is in the lower part).
On Tue, Sep 02, 2014 at 11:05:31AM +0100, Catalin Marinas wrote: > On Fri, Aug 29, 2014 at 07:07:40PM +0100, bhupesh.sharma@freescale.com wrote: > > > > > > + memory@80000000 { > > > > > > + device_type = "memory"; > > > > > > + reg = <0x00000000 0x80000000 0 0x80000000>; > > > > > > + /* DRAM space 1 - 2 GB DRAM */ > > > > > > + }; > > > > > > > > > > Does that mean: > > > > > > > > > > - This is "DRAM space 1", populated with 2GB? > > > > > > > > > > Or: > > > > > > > > > > - The DRAM space can be populated with 1 to 2 GB? > > > > > > > > > > If the former, s/ - /: / for clarity. > > > > > > > > > > If the latter, it might make sense to move that into board-specific > > > > > dts files. If this can be dynamically populated ideally the > > > > > firmware/loader would fix this up (assuming it can probe the memory). > > > > > > > > If the former. I will fix it up in v3. > > > > > > Ok. Out of curiosity, are there other DRAM spaces that might be > > > populated? > > > > Yes there is another DRAM space. The 1st one is accessible within 32 bits and > > the 2nd one is accessible from 40-bit and above. However, I was waiting > > for the 4-level ARM64 page table patches (from Catalin) to get absorbed, as w/o the > > same we can access only a 39-bit PA and hence can have only 3-level page table limited > > to the 1st DRAM region (which is accessible via first 32 bits). > > > > Any idea, about the latest state of Catalin's patch ([1])? Has it made to linux-next? > > The 48-bit VA support is in mainline but you wouldn't be able to enable > it because KVM is still broken. Hopefully it will make it to 3.18-rc1. > > But here we are talking about 40-bit PA range which should be fine with > 3 levels of page tables. The only problem is if you want to idmap the > memory beyond 40-bit (I don't know whether UEFI requires this but for > kernel booting you wouldn't need it since the kernel image is in the > lower part). Ah, I confused my self (and thanks to Mark Rutland for telling me). If your PA range spans 40-bit, the kernel linear mapping would have to span 40-bit as well unless we either implement highmem or compress the phys_to_virt(). None of these are desirable on arm64, so it leaves us with 48-bit VA (which will be enabled by default in defconfig once KVM is sorted).
On 02/09/14 11:05, Catalin Marinas wrote: > On Fri, Aug 29, 2014 at 07:07:40PM +0100, bhupesh.sharma@freescale.com wrote: >>>>>> + memory@80000000 { >>>>>> + device_type = "memory"; >>>>>> + reg = <0x00000000 0x80000000 0 0x80000000>; >>>>>> + /* DRAM space 1 - 2 GB DRAM */ >>>>>> + }; >>>>> >>>>> Does that mean: >>>>> >>>>> - This is "DRAM space 1", populated with 2GB? >>>>> >>>>> Or: >>>>> >>>>> - The DRAM space can be populated with 1 to 2 GB? >>>>> >>>>> If the former, s/ - /: / for clarity. >>>>> >>>>> If the latter, it might make sense to move that into board-specific >>>>> dts files. If this can be dynamically populated ideally the >>>>> firmware/loader would fix this up (assuming it can probe the memory). >>>> >>>> If the former. I will fix it up in v3. >>> >>> Ok. Out of curiosity, are there other DRAM spaces that might be >>> populated? >> >> Yes there is another DRAM space. The 1st one is accessible within 32 bits and >> the 2nd one is accessible from 40-bit and above. However, I was waiting >> for the 4-level ARM64 page table patches (from Catalin) to get absorbed, as w/o the >> same we can access only a 39-bit PA and hence can have only 3-level page table limited >> to the 1st DRAM region (which is accessible via first 32 bits). >> >> Any idea, about the latest state of Catalin's patch ([1])? Has it made to linux-next? > > The 48-bit VA support is in mainline but you wouldn't be able to enable > it because KVM is still broken. Hopefully it will make it to 3.18-rc1. Yeah, if Joel doesn't finish it by the end of the week, I'll have a look at it myself, as it's been dragging for about 4 months now... Thanks, M.
> -----Original Message----- > From: Catalin Marinas [mailto:catalin.marinas@arm.com] > Sent: Tuesday, September 02, 2014 3:45 PM > To: Sharma Bhupesh-B45370 > Cc: Mark Rutland; Will Deacon; arnd@arndb.de; grant.likely@secretlab.ca; > Marc Zyngier; rob.herring@linaro.org; linux-arm- > kernel@lists.infradead.org; Yoder Stuart-B08248; Basu Arnab-B45036 > Subject: Re: [PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC > > On Tue, Sep 02, 2014 at 11:05:31AM +0100, Catalin Marinas wrote: > > On Fri, Aug 29, 2014 at 07:07:40PM +0100, bhupesh.sharma@freescale.com > wrote: > > > > > > > + memory@80000000 { > > > > > > > + device_type = "memory"; > > > > > > > + reg = <0x00000000 0x80000000 0 0x80000000>; > > > > > > > + /* DRAM space 1 - 2 GB DRAM */ > > > > > > > + }; > > > > > > > > > > > > Does that mean: > > > > > > > > > > > > - This is "DRAM space 1", populated with 2GB? > > > > > > > > > > > > Or: > > > > > > > > > > > > - The DRAM space can be populated with 1 to 2 GB? > > > > > > > > > > > > If the former, s/ - /: / for clarity. > > > > > > > > > > > > If the latter, it might make sense to move that into > > > > > > board-specific dts files. If this can be dynamically populated > > > > > > ideally the firmware/loader would fix this up (assuming it can > probe the memory). > > > > > > > > > > If the former. I will fix it up in v3. > > > > > > > > Ok. Out of curiosity, are there other DRAM spaces that might be > > > > populated? > > > > > > Yes there is another DRAM space. The 1st one is accessible within 32 > > > bits and the 2nd one is accessible from 40-bit and above. However, I > > > was waiting for the 4-level ARM64 page table patches (from Catalin) > > > to get absorbed, as w/o the same we can access only a 39-bit PA and > > > hence can have only 3-level page table limited to the 1st DRAM region > (which is accessible via first 32 bits). > > > > > > Any idea, about the latest state of Catalin's patch ([1])? Has it > made to linux-next? > > > > The 48-bit VA support is in mainline but you wouldn't be able to > > enable it because KVM is still broken. Hopefully it will make it to > 3.18-rc1. > > > > But here we are talking about 40-bit PA range which should be fine > > with > > 3 levels of page tables. The only problem is if you want to idmap the > > memory beyond 40-bit (I don't know whether UEFI requires this but for > > kernel booting you wouldn't need it since the kernel image is in the > > lower part). > > Ah, I confused my self (and thanks to Mark Rutland for telling me). If > your PA range spans 40-bit, the kernel linear mapping would have to span > 40-bit as well unless we either implement highmem or compress the > phys_to_virt(). None of these are desirable on arm64, so it leaves us > with 48-bit VA (which will be enabled by default in defconfig once KVM is > sorted). > Right. Thanks for the useful information, Catalin. Regards, Bhupesh
Hi Bhupesh, On Thu, 2014-08-28 at 15:25 +0530, Bhupesh Sharma wrote: > This patch adds the device tree support for FSL LS2085A SoC > based on ARMv8 architecture. > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > + cpu@0 { > + device_type = "cpu"; > + compatible = "arm,cortex-a57"; > + reg = <0x0 0x0>; > + }; arm64 needs a cpu enable-method property. Is your boot loader adding that? Be aware that if you have set it up this way, users will not be able to use this file with kexec's --dtb=FILE to specify a 2nd stage DT file. kexec will use a copy of the DT from the 1st stage in this case. -Geoff
Hi Geoff, On Wed, Sep 03, 2014 at 06:23:11PM +0100, Geoff Levand wrote: > Hi Bhupesh, > > On Thu, 2014-08-28 at 15:25 +0530, Bhupesh Sharma wrote: > > This patch adds the device tree support for FSL LS2085A SoC > > based on ARMv8 architecture. > > + cpus { > > + #address-cells = <2>; > > + #size-cells = <0>; > > + > > + /* We have 4 clusters having 2 Cortex-A57 cores each */ > > + cpu@0 { > > + device_type = "cpu"; > > + compatible = "arm,cortex-a57"; > > + reg = <0x0 0x0>; > > + }; > > arm64 needs a cpu enable-method property. Is your boot loader adding > that? That's the plan. If you take a look on the U-Boot mailing list you'll see there are patches under review which do just that, along with the basis of a PSCI 0.2 implementation. Note that whether or not the in-kernel dts should have an enable-method is under discussion in a subsequent (v3) posting [1,2] of this series. > Be aware that if you have set it up this way, users will not be able to > use this file with kexec's --dtb=FILE to specify a 2nd stage DT file. > kexec will use a copy of the DT from the 1st stage in this case. Surely the latter is the default and the former is the "trust me I know what I'm doing" case? In general there are other things you might need to fill in anyhow (like dynamically populated memory), so I don't see that as a big isssue (though admittedly painful if you're testing things in that area). Mark. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284076.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/284106.html
Hi Mark, On Wed, 2014-09-03 at 18:53 +0100, Mark Rutland wrote: > > Be aware that if you have set it up this way, users will not be able to > > use this file with kexec's --dtb=FILE to specify a 2nd stage DT file. > > kexec will use a copy of the DT from the 1st stage in this case. > > Surely the latter is the default and the former is the "trust me I know > what I'm doing" case? > > In general there are other things you might need to fill in anyhow (like > dynamically populated memory), so I don't see that as a big isssue > (though admittedly painful if you're testing things in that area). Yes, the --dtb=FILE is for flexibility in testing and also could help in the case where an old kernel + dt is installed as a kexec based boot loader and a new DT is desired in booting a newer kernel. One could always hand edit a DTS file to be acceptable to kexec-tools though. -Geoff
diff --git a/arch/arm64/boot/dts/fsl-ls2085a-simu.dts b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file mode 100644 index 0000000..3c0f953 --- /dev/null +++ b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts @@ -0,0 +1,26 @@ +/* + * Device Tree file for Freescale LS2085a software Simulator model + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <bhupesh.sharma@freescale.com> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +/dts-v1/; + +/include/ "fsl-ls2085a.dtsi" + +/ { + model = "Freescale Layerscape 2085a software Simulator model"; + compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; + + ethernet@2210000 { + compatible = "smsc,lan91c111"; + reg = <0x0 0x2210000 0x0 0x100>; + interrupts = <0 58 0x1>; + }; +}; diff --git a/arch/arm64/boot/dts/fsl-ls2085a.dtsi b/arch/arm64/boot/dts/fsl-ls2085a.dtsi new file mode 100644 index 0000000..a1692c2 --- /dev/null +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi @@ -0,0 +1,120 @@ +/* + * Device Tree Include file for Freescale Layerscape-2085A family SoC. + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <bhupesh.sharma@freescale.com> + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +/ { + compatible = "fsl,ls2085a"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + /* We have 4 clusters having 2 Cortex-A57 cores each */ + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x1>; + }; + + cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x100>; + }; + + cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x101>; + }; + + cpu@200 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x200>; + }; + + cpu@201 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x201>; + }; + + cpu@300 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x300>; + }; + + cpu@301 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x301>; + }; + }; + + gic: interrupt-controller@6000000 { + compatible = "arm,gic-v3"; + reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */ + <0x0 0x06100000 0 0x100000>; /* GICR (RD_base + SGI_base) */ + #interrupt-cells = <3>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + interrupt-controller; + interrupts = <1 9 0x4>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0x1>, /* Physical Secure PPI, edge triggered */ + <1 14 0x1>, /* Physical Non-Secure PPI, edge triggered */ + <1 11 0x1>, /* Virtual PPI, edge triggered */ + <1 10 0x1>; /* Hypervisor PPI, edge triggered */ + }; + + serial0: serial@21c0500 { + device_type = "serial"; + compatible = "fsl,ns16550", "ns16550a"; + reg = <0x0 0x21c0500 0x0 0x100>; + clock-frequency = <0>; /* Updated by bootloader */ + interrupts = <0 32 0x1>; /* edge triggered */ + }; + + serial1: serial@21c0600 { + device_type = "serial"; + compatible = "fsl,ns16550", "ns16550a"; + reg = <0x0 0x21c0600 0x0 0x100>; + clock-frequency = <0>; /* Updated by bootloader */ + interrupts = <0 32 0x1>; /* edge triggered */ + }; + + fsl_mc: fsl-mc@80c000000 { + compatible = "fsl,qoriq-mc"; + reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ + <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x80000000>; + /* DRAM space 1 - 2 GB DRAM */ + }; +};