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

[PATCH V3 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/

Rebased against v3.17-rc3

Changes from v2:
----------------
* Addressed review comments:
	- Minor nit-picks.
	- Removed the #address-cells, #size-cells, and ranges properties
	  in the gic node.

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               |  117 ++++++++++++++++++++
 arch/arm64/configs/defconfig                       |    1 +
 8 files changed, 210 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 V3 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 V3 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 V3 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 V3 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     |  117 ++++++++++++++++++++++++++++++
 2 files changed, 143 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..0f9170d
--- /dev/null
+++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi
@@ -0,0 +1,117 @@
+/*
+ * 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>;
+		};
+	};
+
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0 0x80000000>;
+		      /* DRAM space - 1, size : 2 GB DRAM */
+	};
+
+	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>;
+		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 */
+	};
+};
-- 
1.7.9.5

[PATCH V3 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 V3 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 V3 0/6] ARM64: Add support for FSL's LS2085A SoC

[Arnd Bergmann]

On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
> 
> 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:

What would be a reason for using something other than PSCI?

	Arnd

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

[bhupesh.sharma at freescale.com]

Hi Arnd,

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Wednesday, September 03, 2014 9:00 PM
> To: Sharma Bhupesh-B45370
> Cc: Catalin.Marinas at arm.com; Will.Deacon at arm.com;
> grant.likely at secretlab.ca; mark.rutland at arm.com; marc.zyngier at arm.com;
> rob.herring at linaro.org; linux-arm-kernel at lists.infradead.org; Yoder
> Stuart-B08248; Basu Arnab-B45036
> Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
> 
> On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
> >
> > 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:
> 
> What would be a reason for using something other than PSCI?
> 

We had originally gone ahead and implemented spin-table release method in ARMv8 u-boot
(see [1]) (the v3 of that patchset is still in works), but we have since been pointed towards
PSCI by Mark and Catalin, so we have implemented PSCI in ARMv8 u-boot and the v2 and v3
of the DTS patchset have been tested with both the spin-table and PSCI approaches.

[1] http://lists.denx.de/pipermail/u-boot/2014-June/182759.html

Regards,
Bhupesh

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

[Arnd Bergmann]

On Wednesday 03 September 2014 15:36:44 bhupesh.sharma at freescale.com wrote:
> > On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
> > >
> > > 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:
> > 
> > What would be a reason for using something other than PSCI?
> > 
> 
> We had originally gone ahead and implemented spin-table release method in ARMv8 u-boot
> (see [1]) (the v3 of that patchset is still in works), but we have since been pointed towards
> PSCI by Mark and Catalin, so we have implemented PSCI in ARMv8 u-boot and the v2 and v3
> of the DTS patchset have been tested with both the spin-table and PSCI approaches.
> 
> [1] http://lists.denx.de/pipermail/u-boot/2014-June/182759.html
> 

Would it be possible then to just mandate PSCI for the upstream-supported
version?

	Arnd

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

[bhupesh.sharma at freescale.com]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Wednesday, September 03, 2014 9:09 PM
> To: Sharma Bhupesh-B45370
> Cc: Catalin.Marinas at arm.com; Will.Deacon at arm.com;
> grant.likely at secretlab.ca; mark.rutland at arm.com; marc.zyngier at arm.com;
> rob.herring at linaro.org; linux-arm-kernel at lists.infradead.org; Yoder
> Stuart-B08248; Basu Arnab-B45036
> Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
> 
> On Wednesday 03 September 2014 15:36:44 bhupesh.sharma at freescale.com
> wrote:
> > > On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
> > > >
> > > > 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:
> > >
> > > What would be a reason for using something other than PSCI?
> > >
> >
> > We had originally gone ahead and implemented spin-table release method
> > in ARMv8 u-boot (see [1]) (the v3 of that patchset is still in works),
> > but we have since been pointed towards PSCI by Mark and Catalin, so we
> > have implemented PSCI in ARMv8 u-boot and the v2 and v3 of the DTS
> patchset have been tested with both the spin-table and PSCI approaches.
> >
> > [1] http://lists.denx.de/pipermail/u-boot/2014-June/182759.html
> >
> 
> Would it be possible then to just mandate PSCI for the upstream-supported
> version?

Yes. The upstream DTS is going to use PSCI as the default cpu release method
for the secondary's. Later as we add more richness to the PSCI v0.2 layer
in the ARMv8 u-boot, we will look to check features such as Hotplug etc.

Regards,
Bhupesh

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

[Mark Rutland]

Hi Arnd,

On Wed, Sep 03, 2014 at 04:39:07PM +0100, Arnd Bergmann wrote:
> On Wednesday 03 September 2014 15:36:44 bhupesh.sharma at freescale.com wrote:
> > > On Wednesday 03 September 2014 20:43:08 Bhupesh Sharma wrote:
> > > >
> > > > 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:
> > > 
> > > What would be a reason for using something other than PSCI?
> > > 
> > 
> > We had originally gone ahead and implemented spin-table release method in ARMv8 u-boot
> > (see [1]) (the v3 of that patchset is still in works), but we have since been pointed towards
> > PSCI by Mark and Catalin, so we have implemented PSCI in ARMv8 u-boot and the v2 and v3
> > of the DTS patchset have been tested with both the spin-table and PSCI approaches.
> > 
> > [1] http://lists.denx.de/pipermail/u-boot/2014-June/182759.html
> > 
> 
> Would it be possible then to just mandate PSCI for the upstream-supported
> version?

I had asked for the FW to patch up the enable-method (and omit this in
the in-kernel dts) as this is something that may vary over the lifetime
of the SoC independently from the fixed HW properties (it's a firmware
property really).

Personally I'd like to see such things patched by the firmware/loader
where possible (ideally with some way of switching said patching off if
we really know better). We already expect the loader to patch memory
nodes where memory can be dynamically populated. 

I don't see why we should tie the in-kernel dts to a particular firmware
revision. Having such properties in the in-kernel dts is only going to
mislead. The arm64 boot-wrapper patches dts for PSCI, but for
compatibility with old wrappers the in-kernel dts must forever say
spin-table is used to bring up secondaries.

Mark.

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

[Arnd Bergmann]

On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
> I had asked for the FW to patch up the enable-method (and omit this in
> the in-kernel dts) as this is something that may vary over the lifetime
> of the SoC independently from the fixed HW properties (it's a firmware
> property really).

I agree in principle.
 
> Personally I'd like to see such things patched by the firmware/loader
> where possible (ideally with some way of switching said patching off if
> we really know better). We already expect the loader to patch memory
> nodes where memory can be dynamically populated. 
> 
> I don't see why we should tie the in-kernel dts to a particular firmware
> revision. Having such properties in the in-kernel dts is only going to
> mislead. The arm64 boot-wrapper patches dts for PSCI, but for
> compatibility with old wrappers the in-kernel dts must forever say
> spin-table is used to bring up secondaries.

But the kernel has never supported this platform with a non-PSCI
enable method, why should we provide compatibility for something
we never had upstream?

	ARnd

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

[Mark Rutland]

On Wed, Sep 03, 2014 at 05:05:51PM +0100, Arnd Bergmann wrote:
> On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
> > I had asked for the FW to patch up the enable-method (and omit this in
> > the in-kernel dts) as this is something that may vary over the lifetime
> > of the SoC independently from the fixed HW properties (it's a firmware
> > property really).
> 
> I agree in principle.

Ok.
 
> > Personally I'd like to see such things patched by the firmware/loader
> > where possible (ideally with some way of switching said patching off if
> > we really know better). We already expect the loader to patch memory
> > nodes where memory can be dynamically populated. 
> > 
> > I don't see why we should tie the in-kernel dts to a particular firmware
> > revision. Having such properties in the in-kernel dts is only going to
> > mislead. The arm64 boot-wrapper patches dts for PSCI, but for
> > compatibility with old wrappers the in-kernel dts must forever say
> > spin-table is used to bring up secondaries.
> 
> But the kernel has never supported this platform with a non-PSCI
> enable method, why should we provide compatibility for something
> we never had upstream?

I'm not arguing we should.

What I'm suggesting is there wouldn't be an enable-method at all (so we
won't bring up secondaries at all unless that's patched).

I didn't spot an enable-method in skimming this series, but I've not yet
looked at this posting in-depth. Assuming there isn't one I don't see
that we're providing compatibility with anything.

Mark.

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

[bhupesh.sharma at freescale.com]

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Wednesday, September 03, 2014 9:40 PM
> To: Arnd Bergmann
> Cc: Sharma Bhupesh-B45370; Catalin Marinas; Will Deacon;
> 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 V3 0/6] ARM64: Add support for FSL's LS2085A SoC
> 
> On Wed, Sep 03, 2014 at 05:05:51PM +0100, Arnd Bergmann wrote:
> > On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
> > > I had asked for the FW to patch up the enable-method (and omit this
> > > in the in-kernel dts) as this is something that may vary over the
> > > lifetime of the SoC independently from the fixed HW properties (it's
> > > a firmware property really).
> >
> > I agree in principle.
> 
> Ok.
> 
> > > Personally I'd like to see such things patched by the
> > > firmware/loader where possible (ideally with some way of switching
> > > said patching off if we really know better). We already expect the
> > > loader to patch memory nodes where memory can be dynamically
> populated.
> > >
> > > I don't see why we should tie the in-kernel dts to a particular
> > > firmware revision. Having such properties in the in-kernel dts is
> > > only going to mislead. The arm64 boot-wrapper patches dts for PSCI,
> > > but for compatibility with old wrappers the in-kernel dts must
> > > forever say spin-table is used to bring up secondaries.
> >
> > But the kernel has never supported this platform with a non-PSCI
> > enable method, why should we provide compatibility for something we
> > never had upstream?
> 
> I'm not arguing we should.
> 
> What I'm suggesting is there wouldn't be an enable-method at all (so we
> won't bring up secondaries at all unless that's patched).
> 
> I didn't spot an enable-method in skimming this series, but I've not yet
> looked at this posting in-depth. Assuming there isn't one I don't see
> that we're providing compatibility with anything.

'enable-method' has been removed from this DTS since v2.

Regards,
Bhupesh

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

[Arnd Bergmann]

On Wednesday 03 September 2014 17:09:36 Mark Rutland wrote:
> On Wed, Sep 03, 2014 at 05:05:51PM +0100, Arnd Bergmann wrote:
> > On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
> > > Personally I'd like to see such things patched by the firmware/loader
> > > where possible (ideally with some way of switching said patching off if
> > > we really know better). We already expect the loader to patch memory
> > > nodes where memory can be dynamically populated. 
> > > 
> > > I don't see why we should tie the in-kernel dts to a particular firmware
> > > revision. Having such properties in the in-kernel dts is only going to
> > > mislead. The arm64 boot-wrapper patches dts for PSCI, but for
> > > compatibility with old wrappers the in-kernel dts must forever say
> > > spin-table is used to bring up secondaries.
> > 
> > But the kernel has never supported this platform with a non-PSCI
> > enable method, why should we provide compatibility for something
> > we never had upstream?
> 
> I'm not arguing we should.
> 
> What I'm suggesting is there wouldn't be an enable-method at all (so we
> won't bring up secondaries at all unless that's patched).

Ok, I see the appeal in forcing boot loaders to put some patch
up the dtbs with whatever software interfaces they provide.
What I'm interested in however is making it harder for the boot
loader to use something other than psci.

How about setting enable-method=psci but not providing a psci node?
That way the boot loader still has to patch up the psci node but
not necessarily each CPU node, unless they want to use the spin table,
which they should not.

	Arnd

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

[Mark Rutland]

On Wed, Sep 03, 2014 at 05:18:42PM +0100, Arnd Bergmann wrote:
> On Wednesday 03 September 2014 17:09:36 Mark Rutland wrote:
> > On Wed, Sep 03, 2014 at 05:05:51PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 03 September 2014 16:56:55 Mark Rutland wrote:
> > > > Personally I'd like to see such things patched by the firmware/loader
> > > > where possible (ideally with some way of switching said patching off if
> > > > we really know better). We already expect the loader to patch memory
> > > > nodes where memory can be dynamically populated. 
> > > > 
> > > > I don't see why we should tie the in-kernel dts to a particular firmware
> > > > revision. Having such properties in the in-kernel dts is only going to
> > > > mislead. The arm64 boot-wrapper patches dts for PSCI, but for
> > > > compatibility with old wrappers the in-kernel dts must forever say
> > > > spin-table is used to bring up secondaries.
> > > 
> > > But the kernel has never supported this platform with a non-PSCI
> > > enable method, why should we provide compatibility for something
> > > we never had upstream?
> > 
> > I'm not arguing we should.
> > 
> > What I'm suggesting is there wouldn't be an enable-method at all (so we
> > won't bring up secondaries at all unless that's patched).
> 
> Ok, I see the appeal in forcing boot loaders to put some patch
> up the dtbs with whatever software interfaces they provide.
> What I'm interested in however is making it harder for the boot
> loader to use something other than psci.

I see.

I agree that we presently want systems to implement PSCI (0.2+), and we
certainly do not want anything that's platform-specific.

However, I'm not sure I follow the reasoning for making this
significantly harder, and even ignoring that I don't think this does
make things significantly harder. Especially so if we have a PSCI node
but not an enable method -- in that case its trivial to patch in an
unrelated enable-method anyhow.

Mark.

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

[Geoff Levand]

Hi Mark.

On Wed, 2014-09-03 at 16:56 +0100, Mark Rutland wrote:
> Personally I'd like to see such things patched by the firmware/loader
> where possible (ideally with some way of switching said patching off if
> we really know better).

I think this makes sense for the enable method at least, since the
enable method is a service the firmware provides, and what the
firmware provides may vary over firmware revisions or even a single
revision configured differently.

-Geoff

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

[Arnd Bergmann]

On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> 
> However, I'm not sure I follow the reasoning for making this
> significantly harder, and even ignoring that I don't think this does
> make things significantly harder. Especially so if we have a PSCI node
> but not an enable method -- in that case its trivial to patch in an
> unrelated enable-method anyhow.

Right, it's not actually much harder. A better way to look at it is
probably that we document what which parts we expect to stay constant
and which parts are to be filled out by the boot loader. Independent
of what PSCI implementation the boot loader provides, we would like
to see enable-method="psci".

I just saw that Geoff had a related comment, and documenting this
would make it clearer to other reviewers, as well as people that
happen to look at this file as a base for new platforms.

	Arnd

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

[Arnd Bergmann]

On Wednesday 03 September 2014 20:43:12 Bhupesh Sharma wrote:
> 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.
> + */
> 

One more thing, same comment as for the respective Exynos7 patch:
can this please be a permissive license, like GPLv2+MIT dual
license?

	Arnd

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

[bhupesh.sharma at freescale.com]

Hi Arnd,

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Thursday, September 04, 2014 12:05 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Sharma Bhupesh-B45370; Catalin.Marinas at arm.com; mark.rutland at arm.com;
> rob.herring at linaro.org; marc.zyngier at arm.com; Will.Deacon at arm.com; Yoder
> Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-B45036
> Subject: Re: [PATCH V3 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> On Wednesday 03 September 2014 20:43:12 Bhupesh Sharma wrote:
> > 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.
> > + */
> >
> 
> One more thing, same comment as for the respective Exynos7 patch:
> can this please be a permissive license, like GPLv2+MIT dual license?
> 

Yes. I saw Russell's email in which he mentions that Linus is ok with using the MIT
X11 licenses ([1]). However, I am not sure I understand the GPLv2+MIT dual license.
Is it listed separately on [2], or is it a sum of the X11 + GPLv2 clauses mentioned in [2].

[1] http://www.spinics.net/lists/arm-kernel/msg358782.html
[2] http://www.gnu.org/licenses/license-list.html

Regards,
Bhupesh

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

[Mark Rutland]

On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
> On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> > 
> > However, I'm not sure I follow the reasoning for making this
> > significantly harder, and even ignoring that I don't think this does
> > make things significantly harder. Especially so if we have a PSCI node
> > but not an enable method -- in that case its trivial to patch in an
> > unrelated enable-method anyhow.
> 
> Right, it's not actually much harder. A better way to look at it is
> probably that we document what which parts we expect to stay constant
> and which parts are to be filled out by the boot loader. Independent
> of what PSCI implementation the boot loader provides, we would like
> to see enable-method="psci".

So in the /cpus node, have a comment like:

/*
 * We expect the enable-method to be "psci", but this is dependent on
 * the FW, which will fill this in.
 */

Or, should we put together a soc-guidance.txt with that, ensuring things
are initialised correctly (CNTVOFF, CNTFREQ), etc?

> I just saw that Geoff had a related comment, and documenting this
> would make it clearer to other reviewers, as well as people that
> happen to look at this file as a base for new platforms.

I agree that having something to point people in the right direction is
a good idea. The only point I disagree with is putitng something in the
DT that can be trivially made false (and possibly with good reason).

I'm happy with having comments.

Mark.

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

[Arnd Bergmann]

On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
> On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
> > On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> > > 
> > > However, I'm not sure I follow the reasoning for making this
> > > significantly harder, and even ignoring that I don't think this does
> > > make things significantly harder. Especially so if we have a PSCI node
> > > but not an enable method -- in that case its trivial to patch in an
> > > unrelated enable-method anyhow.
> > 
> > Right, it's not actually much harder. A better way to look at it is
> > probably that we document what which parts we expect to stay constant
> > and which parts are to be filled out by the boot loader. Independent
> > of what PSCI implementation the boot loader provides, we would like
> > to see enable-method="psci".
> 
> So in the /cpus node, have a comment like:
> 
> /*
>  * We expect the enable-method to be "psci", but this is dependent on
>  * the FW, which will fill this in.
>  */

I was thinking of leaving the enable-method in the cpus node, but having
an empty psci node with a similar comment.

> Or, should we put together a soc-guidance.txt with that, ensuring things
> are initialised correctly (CNTVOFF, CNTFREQ), etc?

I would very much welcome documentation like that!

> > I just saw that Geoff had a related comment, and documenting this
> > would make it clearer to other reviewers, as well as people that
> > happen to look at this file as a base for new platforms.
> 
> I agree that having something to point people in the right direction is
> a good idea. The only point I disagree with is putitng something in the
> DT that can be trivially made false (and possibly with good reason).
> 
> I'm happy with having comments.

Right, but I see no good reason for having something else in the
enable-method, the only way I can see why that would be done is for
the boot loader or firmware implementer to be misinformed.

	Arnd

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

[Stuart Yoder]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Thursday, September 04, 2014 4:39 AM
> To: Mark Rutland
> Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Sharma Bhupesh-B45370; Catalin Marinas;
> Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Marc Zyngier; Basu Arnab-B45036; Geoff Levand
> Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
> 
> On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
> > On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> > > >
> > > > However, I'm not sure I follow the reasoning for making this
> > > > significantly harder, and even ignoring that I don't think this does
> > > > make things significantly harder. Especially so if we have a PSCI node
> > > > but not an enable method -- in that case its trivial to patch in an
> > > > unrelated enable-method anyhow.
> > >
> > > Right, it's not actually much harder. A better way to look at it is
> > > probably that we document what which parts we expect to stay constant
> > > and which parts are to be filled out by the boot loader. Independent
> > > of what PSCI implementation the boot loader provides, we would like
> > > to see enable-method="psci".
> >
> > So in the /cpus node, have a comment like:
> >
> > /*
> >  * We expect the enable-method to be "psci", but this is dependent on
> >  * the FW, which will fill this in.
> >  */
> 
> I was thinking of leaving the enable-method in the cpus node, but having
> an empty psci node with a similar comment.
> 
> > Or, should we put together a soc-guidance.txt with that, ensuring things
> > are initialised correctly (CNTVOFF, CNTFREQ), etc?
> 
> I would very much welcome documentation like that!

If any documentation updates are to be made I think they belong in
Documentation/arm64/booting.txt.

There is currently the following:

[cut]
- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr'
  property in their cpu node.  This property identifies a
  naturally-aligned 64-bit zero-initalised memory location.

  These CPUs should spin outside of the kernel in a reserved area of
  memory (communicated to the kernel by a /memreserve/ region in the
  device tree) polling their cpu-release-addr location, which must be
  contained in the reserved region.  A wfe instruction may be inserted
  to reduce the overhead of the busy-loop and a sev will be issued by
  the primary CPU.  When a read of the location pointed to by the
  cpu-release-addr returns a non-zero value, the CPU must jump to this
  value.  The value will be written as a single 64-bit little-endian
  value, so CPUs must convert the read value to their native endianness
  before jumping to it.

- CPUs with a "psci" enable method should remain outside of
  the kernel (i.e. outside of the regions of memory described to the
  kernel in the memory node, or in a reserved area of memory described
  to the kernel by a /memreserve/ region in the device tree).  The
  kernel will issue CPU_ON calls as described in ARM document number ARM
  DEN 0022A ("Power State Coordination Interface System Software on ARM
  processors") to bring CPUs into the kernel.

  The device tree should contain a 'psci' node, as described in
  Documentation/devicetree/bindings/arm/psci.txt.
[cut]

Whatever the requirements are-- enable-method present, psci node
(empty or otherwise), plus anything about other initialization
like CNTVOFF/CNTFREQ.  Having all boot time requirements in one
place would be good.

Also, if psci 2.0 is a requirement that should be specified in 
there as well.

Thanks,
Stuart

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

[bhupesh.sharma at freescale.com]

Hi Mark, Arnd

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Thursday, September 04, 2014 3:09 PM
> To: Mark Rutland
> Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Sharma
> Bhupesh-B45370; Catalin Marinas; Will Deacon; Yoder Stuart-B08248;
> grant.likely at secretlab.ca; Marc Zyngier; Basu Arnab-B45036; Geoff Levand
> Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
> 
> On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
> > On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> > > >
> > > > However, I'm not sure I follow the reasoning for making this
> > > > significantly harder, and even ignoring that I don't think this
> > > > does make things significantly harder. Especially so if we have a
> > > > PSCI node but not an enable method -- in that case its trivial to
> > > > patch in an unrelated enable-method anyhow.
> > >
> > > Right, it's not actually much harder. A better way to look at it is
> > > probably that we document what which parts we expect to stay
> > > constant and which parts are to be filled out by the boot loader.
> > > Independent of what PSCI implementation the boot loader provides, we
> > > would like to see enable-method="psci".
> >
> > So in the /cpus node, have a comment like:
> >
> > /*
> >  * We expect the enable-method to be "psci", but this is dependent on
> >  * the FW, which will fill this in.
> >  */
> 
> I was thinking of leaving the enable-method in the cpus node, but having
> an empty psci node with a similar comment.
> 
> > Or, should we put together a soc-guidance.txt with that, ensuring
> > things are initialised correctly (CNTVOFF, CNTFREQ), etc?
> 
> I would very much welcome documentation like that!

Is this documentation planned (already being worked upon), or should I try to spin-out a RFC patch
which tries to add this guidance documentation.

Regards,
Bhupesh

> 
> > > I just saw that Geoff had a related comment, and documenting this
> > > would make it clearer to other reviewers, as well as people that
> > > happen to look at this file as a base for new platforms.
> >
> > I agree that having something to point people in the right direction
> > is a good idea. The only point I disagree with is putitng something in
> > the DT that can be trivially made false (and possibly with good
> reason).
> >
> > I'm happy with having comments.
> 
> Right, but I see no good reason for having something else in the enable-
> method, the only way I can see why that would be done is for the boot
> loader or firmware implementer to be misinformed.
> 
> 	Arnd

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

[Catalin Marinas]

On Tue, Sep 09, 2014 at 12:46:18PM +0100, bhupesh.sharma at freescale.com wrote:
> > On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
> > > On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
> > > > On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> > > > >
> > > > > However, I'm not sure I follow the reasoning for making this
> > > > > significantly harder, and even ignoring that I don't think this
> > > > > does make things significantly harder. Especially so if we have a
> > > > > PSCI node but not an enable method -- in that case its trivial to
> > > > > patch in an unrelated enable-method anyhow.
> > > >
> > > > Right, it's not actually much harder. A better way to look at it is
> > > > probably that we document what which parts we expect to stay
> > > > constant and which parts are to be filled out by the boot loader.
> > > > Independent of what PSCI implementation the boot loader provides, we
> > > > would like to see enable-method="psci".
> > >
> > > So in the /cpus node, have a comment like:
> > >
> > > /*
> > >  * We expect the enable-method to be "psci", but this is dependent on
> > >  * the FW, which will fill this in.
> > >  */
> > 
> > I was thinking of leaving the enable-method in the cpus node, but having
> > an empty psci node with a similar comment.
> > 
> > > Or, should we put together a soc-guidance.txt with that, ensuring
> > > things are initialised correctly (CNTVOFF, CNTFREQ), etc?
> > 
> > I would very much welcome documentation like that!
> 
> Is this documentation planned (already being worked upon), or should I
> try to spin-out a RFC patch which tries to add this guidance
> documentation.

RFCs are welcome. We had such thing on the random to-do list of the day
but never got to write anything down. As Stuart mentioned, it would be
better to add it as part of the booting.txt document. A potential
soc.txt is more for DT, code structuring (spreading) throughout drivers/
etc. If you have time, that would be good as well ;).

-- 
Catalin

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

[bhupesh.sharma at freescale.com]

Ping?

> -----Original Message-----
> From: Sharma Bhupesh-B45370
> Sent: Tuesday, September 09, 2014 5:16 PM
> To: 'Arnd Bergmann'; Mark Rutland
> Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Catalin
> Marinas; Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca;
> Marc Zyngier; Basu Arnab-B45036; Geoff Levand
> Subject: RE: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
> 
> Hi Mark, Arnd
> 
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Thursday, September 04, 2014 3:09 PM
> > To: Mark Rutland
> > Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org;
> > Sharma Bhupesh-B45370; Catalin Marinas; Will Deacon; Yoder
> > Stuart-B08248; grant.likely at secretlab.ca; Marc Zyngier; Basu
> > Arnab-B45036; Geoff Levand
> > Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
> >
> > On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
> > > On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
> > > > On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> > > > >
> > > > > However, I'm not sure I follow the reasoning for making this
> > > > > significantly harder, and even ignoring that I don't think this
> > > > > does make things significantly harder. Especially so if we have
> > > > > a PSCI node but not an enable method -- in that case its trivial
> > > > > to patch in an unrelated enable-method anyhow.
> > > >
> > > > Right, it's not actually much harder. A better way to look at it
> > > > is probably that we document what which parts we expect to stay
> > > > constant and which parts are to be filled out by the boot loader.
> > > > Independent of what PSCI implementation the boot loader provides,
> > > > we would like to see enable-method="psci".
> > >
> > > So in the /cpus node, have a comment like:
> > >
> > > /*
> > >  * We expect the enable-method to be "psci", but this is dependent
> > > on
> > >  * the FW, which will fill this in.
> > >  */
> >
> > I was thinking of leaving the enable-method in the cpus node, but
> > having an empty psci node with a similar comment.
> >
> > > Or, should we put together a soc-guidance.txt with that, ensuring
> > > things are initialised correctly (CNTVOFF, CNTFREQ), etc?
> >
> > I would very much welcome documentation like that!
> 
> Is this documentation planned (already being worked upon), or should I
> try to spin-out a RFC patch which tries to add this guidance
> documentation.
> 
> Regards,
> Bhupesh
> 
> >
> > > > I just saw that Geoff had a related comment, and documenting this
> > > > would make it clearer to other reviewers, as well as people that
> > > > happen to look at this file as a base for new platforms.
> > >
> > > I agree that having something to point people in the right direction
> > > is a good idea. The only point I disagree with is putitng something
> > > in the DT that can be trivially made false (and possibly with good
> > reason).
> > >
> > > I'm happy with having comments.
> >
> > Right, but I see no good reason for having something else in the
> > enable- method, the only way I can see why that would be done is for
> > the boot loader or firmware implementer to be misinformed.
> >
> > 	Arnd

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

[bhupesh.sharma at freescale.com]

Ping?


> -----Original Message-----
> From: Sharma Bhupesh-B45370
> Sent: Thursday, September 04, 2014 1:25 PM
> To: 'Arnd Bergmann'; linux-arm-kernel at lists.infradead.org
> Cc: Catalin.Marinas at arm.com; mark.rutland at arm.com;
> rob.herring at linaro.org; marc.zyngier at arm.com; Will.Deacon at arm.com; Yoder
> Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-B45036
> Subject: RE: [PATCH V3 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> Hi Arnd,
> 
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Thursday, September 04, 2014 12:05 AM
> > To: linux-arm-kernel at lists.infradead.org
> > Cc: Sharma Bhupesh-B45370; Catalin.Marinas at arm.com;
> > mark.rutland at arm.com; rob.herring at linaro.org; marc.zyngier at arm.com;
> > Will.Deacon at arm.com; Yoder Stuart-B08248; grant.likely at secretlab.ca;
> > Basu Arnab-B45036
> > Subject: Re: [PATCH V3 4/6] arm64: Add DTS support for FSL's LS2085A
> > SoC
> >
> > On Wednesday 03 September 2014 20:43:12 Bhupesh Sharma wrote:
> > > 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.
> > > + */
> > >
> >
> > One more thing, same comment as for the respective Exynos7 patch:
> > can this please be a permissive license, like GPLv2+MIT dual license?
> >
> 
> Yes. I saw Russell's email in which he mentions that Linus is ok with
> using the MIT
> X11 licenses ([1]). However, I am not sure I understand the GPLv2+MIT
> dual license.
> Is it listed separately on [2], or is it a sum of the X11 + GPLv2 clauses
> mentioned in [2].
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg358782.html
> [2] http://www.gnu.org/licenses/license-list.html
> 
> Regards,
> Bhupesh

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

[Mark Rutland]

On Sat, Sep 20, 2014 at 09:35:08PM +0100, bhupesh.sharma at freescale.com wrote:
> Ping?

Hi Bhupesh,

> > -----Original Message-----
> > From: Sharma Bhupesh-B45370
> > Sent: Tuesday, September 09, 2014 5:16 PM
> > To: 'Arnd Bergmann'; Mark Rutland
> > Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org; Catalin
> > Marinas; Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca;
> > Marc Zyngier; Basu Arnab-B45036; Geoff Levand
> > Subject: RE: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
> > 
> > Hi Mark, Arnd
> > 
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Sent: Thursday, September 04, 2014 3:09 PM
> > > To: Mark Rutland
> > > Cc: linux-arm-kernel at lists.infradead.org; rob.herring at linaro.org;
> > > Sharma Bhupesh-B45370; Catalin Marinas; Will Deacon; Yoder
> > > Stuart-B08248; grant.likely at secretlab.ca; Marc Zyngier; Basu
> > > Arnab-B45036; Geoff Levand
> > > Subject: Re: [PATCH V3 0/6] ARM64: Add support for FSL's LS2085A SoC
> > >
> > > On Thursday 04 September 2014 10:13:19 Mark Rutland wrote:
> > > > On Wed, Sep 03, 2014 at 07:31:44PM +0100, Arnd Bergmann wrote:
> > > > > On Wednesday 03 September 2014 17:31:30 Mark Rutland wrote:
> > > > > >
> > > > > > However, I'm not sure I follow the reasoning for making this
> > > > > > significantly harder, and even ignoring that I don't think this
> > > > > > does make things significantly harder. Especially so if we have
> > > > > > a PSCI node but not an enable method -- in that case its trivial
> > > > > > to patch in an unrelated enable-method anyhow.
> > > > >
> > > > > Right, it's not actually much harder. A better way to look at it
> > > > > is probably that we document what which parts we expect to stay
> > > > > constant and which parts are to be filled out by the boot loader.
> > > > > Independent of what PSCI implementation the boot loader provides,
> > > > > we would like to see enable-method="psci".
> > > >
> > > > So in the /cpus node, have a comment like:
> > > >
> > > > /*
> > > >  * We expect the enable-method to be "psci", but this is dependent
> > > > on
> > > >  * the FW, which will fill this in.
> > > >  */
> > >
> > > I was thinking of leaving the enable-method in the cpus node, but
> > > having an empty psci node with a similar comment.
> > >
> > > > Or, should we put together a soc-guidance.txt with that, ensuring
> > > > things are initialised correctly (CNTVOFF, CNTFREQ), etc?
> > >
> > > I would very much welcome documentation like that!
> > 
> > Is this documentation planned (already being worked upon), or should I
> > try to spin-out a RFC patch which tries to add this guidance
> > documentation.

If you'd be willing to put together an RFC, that would be welcomed. It
has so far been a TODO item that no-one has had the time for.

Mark.

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

[Stuart Yoder]

So there is still an open issue that has not been closed related to
what device trees should have with respect to enable-method.  There 
are 2 proposals from Mark and Arnd--

1.  Put comment in /cpus node in dts (Mark)

     ...
        cpus {
                #address-cells = <2>;
                #size-cells = <0>;

                /*
                 * We expect the enable-method to be "psci", but this is dependent on
                 * the FW, which will fill this in.
                 */

                cpu at 0 {
                        device_type = "cpu";
                        compatible = "arm,cortex-a57";
                        reg = <0x0 0x0>;
                };
     ...


2.  Put explicit psci enable-method in cpu nodes, to make it clear that psci 
    is expected.  Plus include empty psci node with a comment. (Arnd)

     ...
       /*
        * We expect the enable-method to be "psci", but this is dependent on
        * the FW, which will fill this in.
        */
        psci {
        }
     ...
        cpus {
                #address-cells = <2>;
                #size-cells = <0>;

                cpu at 0 {
                        device_type = "cpu";
                        compatible = "arm,cortex-a57";
                        reg = <0x0 0x0>;
                        enable-method = "psci";
                };
     ...


I would prefer #1.  I think putting "hints" like the psci node and
the enable-method are weak at best.  I think the comment in #1 is
enough to make the preferred approach clear.  In the end firmware will 
override the nodes and properties if it wants or needs to.

Thanks,
Stuart