[PATCH V2 0/6] ARM64: Add support for FSL's LS2085A SoC

[PATCH V2 0/6] ARM64: Add support for FSL's LS2085A SoC

[Bhupesh Sharma]

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

-- 
1.7.9.5

[PATCH V2 1/6] Documentation: DT: Add bindings for FSL NS16550A UART

[Bhupesh Sharma]

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.

Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
---
 .../devicetree/bindings/serial/of-serial.txt       |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt b/Documentation/devicetree/bindings/serial/of-serial.txt
index 7705477..1bdc569 100644
--- a/Documentation/devicetree/bindings/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
@@ -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 {
-- 
1.7.9.5

[PATCH V2 2/6] Documentation: DT: Add entry for FSL LS2085A SoC and Simulator model

[Bhupesh Sharma]

This patch adds a devicetree binding documentation for FSL's
LS2085A SoC and Simulator model.

Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
---
 Documentation/devicetree/bindings/arm/fsl.txt |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index e935d7d..3b28c4d 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -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";
+
-- 
1.7.9.5

[PATCH V2 3/6] Documentation: DT: Add entry for FSL Management Complex

[Bhupesh Sharma]

This 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

Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
Signed-off-by: J. German Rivera <German.Rivera@freescale.com>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      |   40 ++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
new file mode 100644
index 0000000..c7a26ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -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 */
+        };
+
-- 
1.7.9.5

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[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 <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 at 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 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 {
+		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 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";
+		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 at 80c000000 {
+		compatible = "fsl,qoriq-mc";
+		reg = <0x00000008 0x0c000000 0 0x40>,	 /* MC portal base */
+		      <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
+		};
+
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0 0x80000000>;
+		      /* DRAM space 1 - 2 GB DRAM */
+	};
+};
-- 
1.7.9.5

[PATCH V2 5/6] arm64: dts/Makefile: Add support for FSL's LS2085A simulator model

[Bhupesh Sharma]

This patch adds build support for FSL's LS2085A simulator model
in arm64 dts Makefile.

Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
---
 arch/arm64/boot/dts/Makefile |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index c52bdb0..c6ed88662 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -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)
-- 
1.7.9.5

[PATCH V2 6/6] arm64: Add support for FSL's LS2085A SoC in Kconfig and defconfig

[Bhupesh Sharma]

This patch adds support for FSL's LS2085A SoC in the arm64 Kconfig
and defconfig files.

Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
Signed-off-by: Arnab Basu <arnab.basu@freescale.com>
---
 arch/arm64/Kconfig           |    5 +++++
 arch/arm64/configs/defconfig |    1 +
 2 files changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a..1114df0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -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"
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d92ef3c..f2fb45d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -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
-- 
1.7.9.5

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Mark Rutland]

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 at 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 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 {
> +		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 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";
> +		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 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.

> +
> +	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

[bhupesh.sharma at freescale.com]

Hi Mark,

Thanks for your review.
Please see my comments inline.


> -----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 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 at 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 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 {
> > +		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 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";
> > +		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 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.

Oops. Ok.

> 
> > +
> > +	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).

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.

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Mark Rutland]

Hi Bhupesh,

> > > +	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) */
> > > +		#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 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";
> > > +		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 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).
> 
> 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.

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[bhupesh.sharma at freescale.com]

Hi Mark,

> -----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 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 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).
> >
> > 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

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Catalin Marinas]

On Fri, Aug 29, 2014 at 07:07:40PM +0100, bhupesh.sharma at freescale.com wrote:
> > > > > +	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).
> > >
> > > 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).

-- 
Catalin

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Catalin Marinas]

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 at freescale.com wrote:
> > > > > > +	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).
> > > >
> > > > 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).

-- 
Catalin

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Marc Zyngier]

On 02/09/14 11:05, Catalin Marinas wrote:
> On Fri, Aug 29, 2014 at 07:07:40PM +0100, bhupesh.sharma at freescale.com wrote:
>>>>>> +	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).
>>>>
>>>> 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.
-- 
Jazz is not dead. It just smells funny...

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[bhupesh.sharma at freescale.com]

> -----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 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 at freescale.com
> wrote:
> > > > > > > +	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).
> > > > >
> > > > > 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

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Geoff Levand]

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 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

[PATCH V2 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Mark Rutland]

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 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.

> 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

[Geoff Levand]

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