ARM64: Add support for FSL's LS2085A SoC
Subsystems (4)
v2 cover ARM64: Add support for FSL's LS2085A SoC
This patchset adds the support for FSL's LS2085A SoC which is based on ARMv8 architecture.
This patchset also has patches which addresses DT compatible strings for nodes which appear un-documented.
In this version, the enable-method for the CPU nodes is left for the bootloader (u-boot or UEFI) to patch-up. This DTS has been tested for PSCI v0.2 CPU_ON method (and corresponding secondary boot) using the following ARMv8 u-boot patches:
http://patchwork.ozlabs.org/patch/383556/
http://patchwork.ozlabs.org/patch/383555/
http://patchwork.ozlabs.org/patch/383557/
http://patchwork.ozlabs.org/patch/383558/
http://patchwork.ozlabs.org/patch/383559/
http://patchwork.ozlabs.org/patch/383560/
http://patchwork.ozlabs.org/patch/383561/
http://patchwork.ozlabs.org/patch/383562/
Changes from v1:
----------------
* Addressed review comments:
- PSCI v0.2 enable method for CPU patched by corresponding u-boot patches for ARMv8 (which are referred-to above):
- Moved the NS16550 DT documentation to a new location:
devicetree/bindings/serial/of-serial.txt
- Minor nit-pick in FSL Management Complex DT node in regs section.
- Minor nit-pick in smsc ethernet DT node.
- Removed GICv3-ITS node from the DTS.
- Addressed Virtual timer PPI interrupt number and some other minor nit-picks.
Bhupesh Sharma (6):
Documentation: DT: Add bindings for FSL NS16550A UART
Documentation: DT: Add entry for FSL LS2085A SoC and Simulator model
Documentation: DT: Add entry for FSL Management Complex
arm64: Add DTS support for FSL's LS2085A SoC
arm64: dts/Makefile: Add support for FSL's LS2085A simulator model
arm64: Add support for FSL's LS2085A SoC in Kconfig and defconfig
Documentation/devicetree/bindings/arm/fsl.txt | 8 ++ .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 40 +++++++ .../devicetree/bindings/serial/of-serial.txt | 12 ++ arch/arm64/Kconfig | 5 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 26 +++++ arch/arm64/boot/dts/fsl-ls2085a.dtsi | 120 ++++++++++++++++++++ arch/arm64/configs/defconfig | 1 + 8 files changed, 213 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi
Signature · 1 line
1.7.9.5
PATCH v2 1/6 Documentation: DT: Add bindings for FSL NS16550A UART
This patch addss the device-tree documentation for Freescale's NS16550 UART (also called DUART).
There is a specific errata fix required in FSL NS16550 UART which ensures that an random interrupt storm is not observed when a break is provided as an input to the UART.
--- .../devicetree/bindings/serial/of-serial.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Documentation/devicetree/bindings/serial/of-serial.txt +12 -0
@@ -14,6 +14,7 @@ Required properties: - "altr,16550-FIFO32" - "altr,16550-FIFO64" - "altr,16550-FIFO128" + - "fsl,ns16550" - "serial" if the port type is unknown. - reg : offset and length of the register set for the device. - interrupts : should contain uart interrupt.
@@ -39,6 +40,17 @@ Optional properties: property. - has-hw-flow-control: the hardware has flow control capability. +Note: +* fsl,ns16550: + ------------ + Freescale DUART is very similar to the PC16552D (and to a + pair of NS16550A), albeit with some nonstandard behavior such as + erratum A-004737 (relating to incorrect BRK handling). + + Represents a single port that is compatible with the DUART found + on many Freescale chips (examples include mpc8349, mpc8548, + mpc8641d, p4080 and ls2085a). + Example: uart at 80230000 {
Signature · 1 line
1.7.9.5
PATCH v2 2/6 Documentation: DT: Add entry for FSL LS2085A SoC and Simulator model
In reply to Bhupesh SharmaThis patch adds a devicetree binding documentation for FSL's LS2085A SoC and Simulator model.
--- Documentation/devicetree/bindings/arm/fsl.txt | 8 ++++++++ 1 file changed, 8 insertions(+)
Documentation/devicetree/bindings/arm/fsl.txt +8 -0
@@ -74,3 +74,11 @@ Required root node properties: i.MX6q generic board Required root node properties: - compatible = "fsl,imx6q"; + +Freescale LS2085A SoC Device Tree Bindings +------------------------------------------ + +LS2085A ARMv8 based Simulator model +Required root node properties: + - compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; +
Signature · 1 line
1.7.9.5
PATCH v2 3/6 Documentation: DT: Add entry for FSL Management Complex
In reply to Bhupesh SharmaThis patch adds a devicetree binding documentation for FSL's Management Complex.
Management Complex is a hardware resource manager that manages specialized hardware objects used in network-oriented packet processing applications
--- .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 40 ++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt new file +40 -0
@@ -0,0 +1,40 @@ +* Freescale Management Complex + +The Freescale Management Complex (fsl-mc) is a hardware resource +manager that manages specialized hardware objects used in +network-oriented packet processing applications. After the fsl-mc +block is enabled, pools of hardware resources are available, such as +queues, buffer pools, I/O interfaces. These resources are building +blocks that can be used to create functional hardware objects/devices +such as network interfaces, crypto accelerator instances, L2 switches, +etc. + +Required properties: + + - compatible + Value type: <string> + Definition: Must be "fsl,qoriq-mc". A Freescale Management Complex + compatible with this binding must have Block Revision + Registers BRR1 and BRR2 at offset 0x0BF8 and 0x0BFC in + the MC control register region. + + - reg + Value type: <prop-encoded-array> + Definition: A standard property. Specifies one or two regions + defining the MC's registers: + + -the first region is the command portal for the + this machine and must always be present + + -the second region is the MC control registers. This + region may not be present in some scenarios, such + as in the device tree presented to a virtual machine. + +Example: + + fsl_mc: fsl-mc at 80c000000 { + compatible = "fsl,qoriq-mc"; + reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base */ + <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ + }; +
Signature · 1 line
1.7.9.5
PATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
In reply to Bhupesh SharmaThis 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.
--- 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
arch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +26 -0
@@ -0,0 +1,26 @@ +/* + * Device Tree file for Freescale LS2085a software Simulator model + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <[email protected]> + * + * 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 at 2210000 { + compatible = "smsc,lan91c111"; + reg = <0x0 0x2210000 0x0 0x100>; + interrupts = <0 58 0x1>; + }; +};
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +120 -0
120 lines not on this page · raw message
Signature · 1 line
1.7.9.5
Mark Rutland
reviewerPATCH 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.
Quoted 133 lines · Bhupesh Sharma
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 <[email protected]>Signed-off-by Arnab Basu <[email protected]>Signed-off-by Stuart Yoder <[email protected]>--- 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.dtsiarch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +26
-0@@ -0,0 +1,26 @@ +/* + * Device Tree file for Freescale LS2085a software Simulator model + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <[email protected]> + * + * 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 at 2210000 { + compatible = "smsc,lan91c111"; + reg = <0x0 0x2210000 0x0 0x100>; + interrupts = <0 58 0x1>; + }; +};arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +73
-0@@ -0,0 +1,120 @@ +/* + * Device Tree Include file for Freescale Layerscape-2085A family SoC. + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <[email protected]> + * + * 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 at 0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + }; + + cpu at 1 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x1>; + }; + + cpu at 100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x100>; + }; + + cpu at 101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x101>; + }; + + cpu at 200 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x200>; + }; + + cpu at 201 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x201>; + }; + + cpu at 300 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x300>; + }; + + cpu at 301 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x301>; + }; + }; + + gic: interrupt-controller at 6000000 {
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 83
Quoted 10 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +10
-0+ 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.
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 91
Quoted 8 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +8
-0+ + 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?
Quoted 6 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +6
-0+ + serial0: serial at 21c0500 { + device_type = "serial"; + compatible = "fsl,ns16550", "ns16550a"; + reg = <0x0 0x21c0500 0x0 0x100>; + clock-frequency = <0>; /* Updated by bootloader */
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 107
Quoted 10 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +10
-0+ interrupts = <0 32 0x1>; /* edge triggered */ + }; + + serial1: serial at 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?
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 113
Quoted 6 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +6
-0+ + fsl_mc: fsl-mc at 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.
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 119
Quoted 6 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +6
-0+ + memory at 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.
PATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Hi Mark,
Thanks for your review.
Please see my comments inline.
Quoted 155 lines
-----Original Message-----
From: Mark Rutland [mailto:mark.rutland at arm.com]
Sent: Thursday, August 28, 2014 8:27 PM
To: Sharma Bhupesh-B45370
Cc: Catalin Marinas; Will Deacon; arnd at arndb.de;
grant.likely at secretlab.ca; Marc Zyngier; rob.herring at linaro.org; linux- arm-kernel at lists.infradead.org; Yoder Stuart-B08248; Basu Arnab-B45036
Subject: Re: [PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoCHi Bhupesh,
This looks generally good, I just have a few questions and minor change suggestions below.
Quoted 12 lines · Bhupesh Sharma
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.Quoted 6 lines
Signed-off-by Bhupesh Sharma <[email protected]>Signed-off-by Arnab Basu <[email protected]>Signed-off-by Stuart Yoder <[email protected]>--- arch/arm64/boot/dts/fsl-ls2085a-simu.dts | 26 +++++++ arch/arm64/boot/dts/fsl-ls2085a.dtsi | 120++++++++++++++++++++++++++++++
Quoted 110 lines
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.dtsiarch/arm64/boot/dts/fsl-ls2085a-simu.dts new file +26
-0@@ -0,0 +1,26 @@ +/* + * Device Tree file for Freescale LS2085a software Simulator model + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <[email protected]> + * + * 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 at 2210000 { + compatible = "smsc,lan91c111"; + reg = <0x0 0x2210000 0x0 0x100>; + interrupts = <0 58 0x1>; + }; +};arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +66
-0@@ -0,0 +1,120 @@ +/* + * Device Tree Include file for Freescale Layerscape-2085A family SoC. + * + * Copyright (C) 2014, Freescale Semiconductor + * + * Bhupesh Sharma <[email protected]> + * + * 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 at 0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + }; + + cpu at 1 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x1>; + }; + + cpu at 100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x100>; + }; + + cpu at 101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x101>; + }; + + cpu at 200 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x200>; + }; + + cpu at 201 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x201>; + }; + + cpu at 300 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x300>; + }; + + cpu at 301 {arch/arm64/boot/dts/fsl-ls2085a.dtsi line 76
Quoted 10 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +10
-0+ device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x301>; + }; + }; + + gic: interrupt-controller at 6000000 { + compatible = "arm,gic-v3"; + reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */ + <0x0 0x06100000 0 0x100000>; /* GICR (RD_base +
SGI_base) */
Quoted 10 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 83
Quoted 7 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +7
-0+ #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.
Quoted 6 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +4
-0+ + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0x1>, /* Physical Secure PPI, edgetriggered */
Quoted 8 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 88
Quoted 1 line
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +1
-0+ <1 14 0x1>, /* Physical Non-Secure PPI, edgetriggered */
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 91
Quoted 3 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +3
-0+ <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.
Quoted 2 lines
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.
Quoted 12 lines
Quoted 12 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +11
-0+ + serial0: serial at 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 at 21c0600 { + device_type = "serial";
Quoted 8 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 107
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +5
-0+ 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.
Quoted 10 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +4
-0+ + fsl_mc: fsl-mc at 80c000000 { + compatible = "fsl,qoriq-mc"; + reg = <0x00000008 0x0c000000 0 0x40>, /* MC portal base*/
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 113
Quoted 2 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +2
-0+ <0x00000000 0x08340000 0 0x40000>; /* MC control reg */ + };Nit: the '}' is indented a tab too far.
Oops. Ok.
Quoted 14 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 119
Quoted 7 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +6
-0+ + memory at 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:
Quoted 7 lines
- 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/loaderwould fix this up (assuming it can probe the memory).
If the former. I will fix it up in v3.
Quoted 3 lines
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
Quoted 3 lines
Cheers,
Mark.
Mark Rutland
reviewerPATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Hi Bhupesh,
Quoted 16 lines
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi
Quoted 4 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +4
-0+ gic: interrupt-controller at 6000000 { + compatible = "arm,gic-v3"; + reg = <0x0 0x06000000 0 0x10000>, /* GIC Dist */ + <0x0 0x06100000 0 0x100000>; /* GICR (RD_base +
SGI_base) */Quoted 10 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 83
Quoted 7 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +7
-0+ #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.
Quoted 1 line
Ok. V3 will address the change.
Ok.
Quoted 16 lines
Quoted 7 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi
Quoted 6 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +4
-0+ + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0x1>, /* Physical Secure PPI, edgetriggered */
Quoted 8 lines
Review
Quoted 1 line
(quoted diff) +1
-0+ <1 14 0x1>, /* Physical Non-Secure PPI, edgetriggered */
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 91
Quoted 3 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +3
-0+ <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?
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
[...]
Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +10
-0+ serial0: serial at 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 at 21c0600 { + device_type = "serial";Quoted 8 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 107
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +5
-0+ 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?
Quoted 1 line
The two UARTs do share the same IRQ.
Ok.
[...]
Quoted 14 lines
Quoted 14 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 119
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +5
-0+ memory at 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?
Quoted 7 lines
Quoted 5 lines
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/loaderwould 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?
Quoted 4 lines
Quoted 2 lines
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.
PATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Hi Mark,
Quoted 11 lines
-----Original Message-----
From: Mark Rutland [mailto:mark.rutland at arm.com]
Sent: Friday, August 29, 2014 11:18 PM
To: Sharma Bhupesh-B45370
Cc: Catalin Marinas; Will Deacon; arnd at arndb.de;
grant.likely at secretlab.ca; Marc Zyngier; rob.herring at linaro.org; linux- arm-kernel at lists.infradead.org; Yoder Stuart-B08248; Basu Arnab-B45036
Subject: Re: [PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoCHi Bhupesh,
[snip..]
Quoted 15 lines
Quoted 7 lines
Quoted 7 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi
Quoted 3 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +3
-0+ timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0x1>, /* Physical Secure PPI, edgetriggered */
Review
Quoted 1 line
(quoted diff) +1
-0+ <1 14 0x1>, /* Physical Non-Secure PPI, edgetriggered */
Review
Quoted 1 line
(quoted diff) +1
-0+ <1 11 0x1>, /* Virtual PPI, edge triggered*/
Quoted 1 line
Quoted 1 line
Review
Quoted 1 line
(quoted diff) +1
-0+ <1 10 0x1>; /* Hypervisor PPI, edgetriggered */
Quoted 5 lines
Quoted 4 lines
Review
Quoted 1 line
(quoted diff) +1
-0+ };In this SoC, are there low-power states the CPUs can be placed into where the architected timers can lose state?
Quoted 6 lines
Quoted 2 lines
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.
Quoted 12 lines
Quoted 6 lines
Quoted 3 lines
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]
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 119
Quoted 6 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +5
-0+ memory at 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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
If the latter, it might make sense to move that into board-specific dts files. If this can be dynamically populated ideally the
firmware/loaderwould 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
Catalin Marinas
maintainerPATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Quoted 25 lines · bhupesh.sharma at freescale.com
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 119
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +5
-0+ memory at 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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
If the latter, it might make sense to move that into board-specific dts files. If this can be dynamically populated ideally the
firmware/loaderwould 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?
Quoted 7 lines
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).
Signature · 1 line
Catalin
Catalin Marinas
maintainerPATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Quoted 34 lines · Catalin Marinas
Quoted 25 lines · bhupesh.sharma at freescale.com
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 119
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +5
-0+ memory at 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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
If the latter, it might make sense to move that into board-specific dts files. If this can be dynamically populated ideally the
firmware/loaderwould 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?
Quoted 7 lines
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?
Quoted 8 lines
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).
Signature · 1 line
Catalin
PATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Quoted 59 lines
-----Original Message-----
From: Catalin Marinas [mailto:catalin.marinas at arm.com]
Sent: Tuesday, September 02, 2014 3:45 PM
To: Sharma Bhupesh-B45370
Cc: Mark Rutland; Will Deacon; arnd at arndb.de; grant.likely at secretlab.ca; Marc Zyngier; rob.herring at linaro.org; linux-arm-
kernel at lists.infradead.org; Yoder Stuart-B08248; Basu Arnab-B45036
Subject: Re: [PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoCQuoted 1 line · Catalin Marinas
On Fri, Aug 29, 2014 at 07:07:40PM +0100, bhupesh.sharma at freescale.com
Quoted 12 lines · wrote:
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Review
Quoted 5 lines
(quoted diff) +5
-0+ memory at 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:
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
- 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/loaderwould fix this up (assuming it canprobe the memory).
Quoted 11 lines
Quoted 11 lines
Quoted 5 lines
Quoted 2 lines
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).
Quoted 2 lines
Quoted 2 lines
Any idea, about the latest state of Catalin's patch ([1])? Has it
made to linux-next?
Quoted 3 lines
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.
Quoted 7 lines
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).
Quoted 7 lines
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
PATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
In reply to Catalin MarinasQuoted 32 lines · Catalin Marinas
Quoted 31 lines · bhupesh.sharma at freescale.com
Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 119
Quoted 5 lines
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +5
-0+ memory at 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.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
If the latter, it might make sense to move that into board-specific dts files. If this can be dynamically populated ideally the
firmware/loaderwould 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).
Quoted 4 lines
Quoted 1 line
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.
Signature · 1 line
Jazz is not dead. It just smells funny...
PATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
In reply to Bhupesh SharmaHi Bhupesh,
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 28
Quoted 12 lines · Bhupesh Sharma
This patch adds the device tree support for FSL LS2085A SoC based on ARMv8 architecture.
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +10
-0+ cpus { + #address-cells = <2>; + #size-cells = <0>; + + /* We have 4 clusters having 2 Cortex-A57 cores each */ + cpu at 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
Mark Rutland
reviewerPATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Hi Geoff,
Quoted 18 lines · Geoff Levand
Hi Bhupesh,
arch/arm64/boot/dts/fsl-ls2085a.dtsi line 28
Quoted 12 lines · Bhupesh Sharma
This patch adds the device tree support for FSL LS2085A SoC based on ARMv8 architecture.
arch/arm64/boot/dts/fsl-ls2085a.dtsi new file +10
-0+ cpus { + #address-cells = <2>; + #size-cells = <0>; + + /* We have 4 clusters having 2 Cortex-A57 cores each */ + cpu at 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.
Quoted 3 lines
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
PATCH v2 4/6 arm64: Add DTS support for FSL's LS2085A SoC
Hi Mark,
Quoted 10 lines · Mark Rutland
Quoted 3 lines
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
PATCH v2 5/6 arm64: dts/Makefile: Add support for FSL's LS2085A simulator model
In reply to Bhupesh SharmaThis patch adds build support for FSL's LS2085A simulator model in arm64 dts Makefile.
--- arch/arm64/boot/dts/Makefile | 1 + 1 file changed, 1 insertion(+)
arch/arm64/boot/dts/Makefile +1 -0
@@ -1,5 +1,6 @@ dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb +dtb-$(CONFIG_ARCH_FSL_LS2085A) += fsl-ls2085a-simu.dtb targets += dtbs targets += $(dtb-y)
Signature · 1 line
1.7.9.5
PATCH v2 6/6 arm64: Add support for FSL's LS2085A SoC in Kconfig and defconfig
In reply to Bhupesh SharmaThis patch adds support for FSL's LS2085A SoC in the arm64 Kconfig and defconfig files.
--- arch/arm64/Kconfig | 5 +++++ arch/arm64/configs/defconfig | 1 + 2 files changed, 6 insertions(+)
arch/arm64/Kconfig +5 -0
@@ -149,6 +149,11 @@ config ARCH_XGENE help This enables support for AppliedMicro X-Gene SOC Family +config ARCH_FSL_LS2085A + bool "Freescale LS2085A SOC" + help + This enables support for Freescale LS2085A SOC. + endmenu menu "Bus support"
arch/arm64/configs/defconfig +1 -0
@@ -34,6 +34,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_XGENE=y +CONFIG_ARCH_FSL_LS2085A=y CONFIG_SMP=y CONFIG_PREEMPT=y CONFIG_KSM=y
Signature · 1 line
1.7.9.5