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

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

[Bhupesh Sharma]

This patchset adds the support for FSL 2085A SoC which is based on
ARMv8 architecture.

This patchset also has patches which addresses DT compatible string for
nodes which appear un-documented.

This patchset is dependent on the 'arm64: initial support for GICv3'
patches from Marc Zyngier and the related ITS patches:

- Refer to his GICv3 tree here:
  https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/gicv3

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 ++
 Documentation/devicetree/bindings/misc/fsl,mc.txt  |   40 ++++++
 .../devicetree/bindings/serial/fsl-ns16550.txt     |   24 ++++
 arch/arm64/Kconfig                                 |    5 +
 arch/arm64/boot/dts/Makefile                       |    1 +
 arch/arm64/boot/dts/fsl-ls2085a-simu.dts           |   29 ++++
 arch/arm64/boot/dts/fsl-ls2085a.dtsi               |  145 ++++++++++++++++++++
 arch/arm64/configs/defconfig                       |    1 +
 8 files changed, 253 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/fsl,mc.txt
 create mode 100644 Documentation/devicetree/bindings/serial/fsl-ns16550.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 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/fsl-ns16550.txt     |   24 ++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/fsl-ns16550.txt

diff --git a/Documentation/devicetree/bindings/serial/fsl-ns16550.txt b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
new file mode 100644
index 0000000..9926e10
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
@@ -0,0 +1,24 @@
+* 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).
+
+- compatible: "fsl,ns16550"
+
+  Represents a single port that is compatible with the DUART found
+  on many Freescale chips (examples include mpc8349, mpc8548,
+  mpc8641d, p4080 and ls2085a).
+
+- reg: The base address of the UART register bank.
+
+- interrupts: A single interrupt specifier.
+
+- clock-frequency = Input clock to the baud rate divider.
+
+Example:
+	serial1: serial at 21c4600 {
+		compatible = "fsl,ns16550", "ns16550a";
+		reg = <0x0 0x21c4600 0x0 0x100>;
+		clock-frequency = <0>;
+		interrupts = <0 32 0x1>;
+	};
+
-- 
1.7.9.5

[PATCH 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 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..608529e
--- /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 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 |   29 ++++++
 arch/arm64/boot/dts/fsl-ls2085a.dtsi     |  145 ++++++++++++++++++++++++++++++
 2 files changed, 174 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..8a55710
--- /dev/null
+++ b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts
@@ -0,0 +1,29 @@
+/*
+ * 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 {
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		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..aca48ac
--- /dev/null
+++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi
@@ -0,0 +1,145 @@
+/*
+ * 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.
+ */
+
+/* Preventing Linux from using the following memory chunk */
+/memreserve/ 0x80000000 0x00010000;
+
+/ {
+	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>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x8000fff8>;
+		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a57";
+			reg = <0x0 0x1>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x8000fff8>;
+		};
+
+		cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a57";
+			reg = <0x0 0x100>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x8000fff8>;
+		};
+
+		cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a57";
+			reg = <0x0 0x101>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x8000fff8>;
+		};
+
+		cpu at 200 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a57";
+			reg = <0x0 0x200>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x8000fff8>;
+		};
+
+		cpu at 201 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a57";
+			reg = <0x0 0x201>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x8000fff8>;
+		};
+
+		cpu at 300 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a57";
+			reg = <0x0 0x300>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x8000fff8>;
+		};
+
+		cpu at 301 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a57";
+			reg = <0x0 0x301>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x8000fff8>;
+		};
+	};
+
+	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 0xf04>;
+
+		its: gic-its at 6020000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x0 0x6020000 0 0x20000>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <1 13 0x01>, /* Physical Secure PPI, edge triggered */
+			     <1 14 0x01>, /* Physical Non-Secure PPI, edge triggered */
+			     <1 0 0x01>,  /* Virtual PPI, edge triggered */
+			     <1 10 0x01>; /* Hypervisor PPI, edge triggered */
+	};
+
+	serial0: serial at 21c4500 {
+		device_type = "serial";
+		compatible = "fsl,ns16550", "ns16550a";
+		reg = <0x0 0x21c4500 0x0 0x100>;
+		clock-frequency = <0>;
+		interrupts = <0 32 0x1>; /* edge triggered */
+	};
+
+	serial1: serial at 21c4600 {
+		device_type = "serial";
+		compatible = "fsl,ns16550", "ns16550a";
+		reg = <0x0 0x21c4600 0x0 0x100>;
+		clock-frequency = <0>;
+		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 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 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 839f48c..72456fe 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -144,6 +144,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 3421f31..0adb51e 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 4/6] arm64: Add DTS support for FSL's LS2085A SoC

[Catalin Marinas]

On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote:
> +	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>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x0 0x8000fff8>;
> +		};

Why not PSCI?

-- 
Catalin

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

[Mark Rutland]

Hi,

On Fri, Aug 15, 2014 at 10:49:13AM +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 |   29 ++++++
>  arch/arm64/boot/dts/fsl-ls2085a.dtsi     |  145 ++++++++++++++++++++++++++++++
>  2 files changed, 174 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..8a55710
> --- /dev/null
> +++ b/arch/arm64/boot/dts/fsl-ls2085a-simu.dts
> @@ -0,0 +1,29 @@
> +/*
> + * 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 {
> +		#address-cells = <2>;
> +		#size-cells = <2>;

As far as I am aware, this cannot have children. So the #address-cells
and #size-cells properties look redundant here.

> +
> +		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..aca48ac
> --- /dev/null
> +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi
> @@ -0,0 +1,145 @@
> +/*
> + * 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.
> + */
> +
> +/* Preventing Linux from using the following memory chunk */
> +/memreserve/ 0x80000000 0x00010000;

A more useful comment would describe what this is intended to protect.

Ideally any bootloader would inject this as required. Inevitably this
kind of thing varies over firmware/bootloader revisions.

> +
> +/ {
> +	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>;
> +			enable-method = "spin-table";
> +			cpu-release-addr = <0x0 0x8000fff8>;
> +		};

I would strongly recommend having a unique cpu-release-addr for each
CPU.

[...]

> +	serial0: serial at 21c4500 {
> +		device_type = "serial";
> +		compatible = "fsl,ns16550", "ns16550a";
> +		reg = <0x0 0x21c4500 0x0 0x100>;
> +		clock-frequency = <0>;

Do we expect this to be filled in by the bootloader?

[...]

> > +	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: please bracket these individually as with other reg entries.

Thanks,
Mark.

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

[Mark Rutland]

On Fri, Aug 15, 2014 at 10:49:10AM +0100, Bhupesh Sharma wrote:
> 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.

Should this not go in
Documentation/devicetree/bindings/serial/of-serial.txt as with other
NS16550A variations?

The only code for handling this string seems to live in
arch/powerpc/kernel/legacy_serial.c. Is there a patch factoring that out
into common code? Or is the erratum not applicable to the revision used
in your ARMv8 SoC?

Thanks,
Mark.

> 
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> ---
>  .../devicetree/bindings/serial/fsl-ns16550.txt     |   24 ++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> 
> diff --git a/Documentation/devicetree/bindings/serial/fsl-ns16550.txt b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> new file mode 100644
> index 0000000..9926e10
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> @@ -0,0 +1,24 @@
> +* 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).
> +
> +- compatible: "fsl,ns16550"
> +
> +  Represents a single port that is compatible with the DUART found
> +  on many Freescale chips (examples include mpc8349, mpc8548,
> +  mpc8641d, p4080 and ls2085a).
> +
> +- reg: The base address of the UART register bank.
> +
> +- interrupts: A single interrupt specifier.
> +
> +- clock-frequency = Input clock to the baud rate divider.
> +
> +Example:
> +	serial1: serial at 21c4600 {
> +		compatible = "fsl,ns16550", "ns16550a";
> +		reg = <0x0 0x21c4600 0x0 0x100>;
> +		clock-frequency = <0>;
> +		interrupts = <0 32 0x1>;
> +	};
> +
> -- 
> 1.7.9.5
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

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

[Mark Rutland]

[devicetree-discuss is no more, fixing up to devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]

Hi,

On Fri, Aug 15, 2014 at 10:49:12AM +0100, Bhupesh Sharma wrote:
> 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-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Signed-off-by: Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Signed-off-by: J. German Rivera <German.Rivera-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  .../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..608529e
> --- /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.

This looks extremely simple. Is this unit self-contained or does it
relate to other blocks which will be described separately?

> +
> +Example:
> +
> +        fsl_mc: fsl-mc@80c000000 {
> +                compatible = "fsl,qoriq-mc";
> +                reg = <0x00000008 0x0c000000 0 0x40        // MC portal base
> +                       0x00000000 0x08340000 0 0x40000 >;  // MC control reg

Nit: could we bracket list entries individually please?

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Rutland]

[devicetree-discuss is no more, fixing up to devicetree at vger.kernel.org]

Hi,

On Fri, Aug 15, 2014 at 10:49:12AM +0100, Bhupesh Sharma wrote:
> 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..608529e
> --- /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.

This looks extremely simple. Is this unit self-contained or does it
relate to other blocks which will be described separately?

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

Nit: could we bracket list entries individually please?

Thanks,
Mark.

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

[Marc Zyngier]

On Fri, Aug 15 2014 at 10:49:13 am BST, Bhupesh Sharma <bhupesh.sharma@freescale.com> 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 |   29 ++++++
>  arch/arm64/boot/dts/fsl-ls2085a.dtsi     |  145 ++++++++++++++++++++++++++++++
>  2 files changed, 174 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.dtsi
> b/arch/arm64/boot/dts/fsl-ls2085a.dtsi
> new file mode 100644
> index 0000000..aca48ac
> --- /dev/null
> +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi

[...]

> +
> +	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 0xf04>;

The GICv3 binding doesn't encode anything in the top bits of the 3rd
word. this should read 4 instead of 0xf04.

> +
> +		its: gic-its at 6020000 {
> +			compatible = "arm,gic-v3-its";
> +			msi-controller;
> +			reg = <0x0 0x6020000 0 0x20000>;
> +		};

Adding the ITS at this point is probably a bit premature, as I haven't
posted the patches yet, and it needs a public review.

> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> + 		interrupts = <1 13 0x01>, /* Physical Secure PPI, edge triggered */
> + 			     <1 14 0x01>, /* Physical Non-Secure PPI, edge triggered */
> +			     <1 0 0x01>,  /* Virtual PPI, edge triggered */

Are you sure about this interrupt number? Given that you have a bunch of
Cortex-A57, I'd expect this to be 11 instead of 0.

> +			     <1 10 0x01>; /* Hypervisor PPI, edge triggered */
> +	};
> +
> +	serial0: serial at 21c4500 {
> +		device_type = "serial";
> +		compatible = "fsl,ns16550", "ns16550a";
> +		reg = <0x0 0x21c4500 0x0 0x100>;
> +		clock-frequency = <0>;
> +		interrupts = <0 32 0x1>; /* edge triggered */

Nitpick: some level of consistency in the way you describe the trigger
would be good (0x01 vs 0x1 vs 1...).

> +	};
> +
> +	serial1: serial at 21c4600 {
> +		device_type = "serial";
> +		compatible = "fsl,ns16550", "ns16550a";
> +		reg = <0x0 0x21c4600 0x0 0x100>;
> +		clock-frequency = <0>;
> +		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 */
> +	};
> +};

-- 
Jazz is not dead. It just smells funny.

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

[Stuart Yoder]

> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> Sent: Friday, August 15, 2014 5:13 AM
> To: Sharma Bhupesh-B45370
> Cc: devicetree-discuss at lists.ozlabs.org; Will Deacon; arnd at arndb.de;
> grant.likely at secretlab.ca; linux-arm-kernel at lists.infradead.org; Yoder Stuart-
> B08248; Basu Arnab-B45036
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote:
> > +	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>;
> > +			enable-method = "spin-table";
> > +			cpu-release-addr = <0x0 0x8000fff8>;
> > +		};
> 
> Why not PSCI?

It simply is where we are today-- we don't have functioning PSCI yet
but plan to get there over time.  All the existing device trees
in arch/arm64 use "spin-table", so it seems that other platforms are
in the same situation:
   apm-storm.dtsi
   foundation-v8.dts
   rtsm_ve-aemv8a.dts

Thanks,
Stuart

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

[Catalin Marinas]

On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote:
> > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote:
> > > +	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>;
> > > +			enable-method = "spin-table";
> > > +			cpu-release-addr = <0x0 0x8000fff8>;
> > > +		};
> > 
> > Why not PSCI?
> 
> It simply is where we are today-- we don't have functioning PSCI yet
> but plan to get there over time.

Thanks for clarification.

> All the existing device trees
> in arch/arm64 use "spin-table", so it seems that other platforms are
> in the same situation:
>    apm-storm.dtsi

Not possible because there is no EL3 mode on the CPU implementation.

>    foundation-v8.dts
>    rtsm_ve-aemv8a.dts

These work with the latest boot wrapper (which overrides the DT nodes
and passes the PSCI information).

-- 
Catalin

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

[Stuart Yoder]

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland@arm.com]
> Sent: Friday, August 15, 2014 6:00 AM
> To: Sharma Bhupesh-B45370
> Cc: devicetree@vger.kernel.org; Catalin Marinas; arnd@arndb.de; Rivera Jose-
> B46482; Will Deacon; Yoder Stuart-B08248; grant.likely@secretlab.ca; Basu
> Arnab-B45036; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 3/6] Documentation: DT: Add entry for FSL Management
> Complex
> 
> [devicetree-discuss is no more, fixing up to devicetree@vger.kernel.org]
> 
> Hi,
> 
> On Fri, Aug 15, 2014 at 10:49:12AM +0100, Bhupesh Sharma wrote:
> > 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..608529e
> > --- /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.
> 
> This looks extremely simple. Is this unit self-contained or does it
> relate to other blocks which will be described separately?

The block is self-contained.  It's a complicated block, but all interactions
with happen through the command interface (1st reg region).

[The MC can do DMA and thus will relate to the SMMU, but there is some
present churn around the SMMU and we'll define the needed properties
(#stream-id-cells or whatever) when that is clear.]

Stuart

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

[Stuart Yoder]

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Friday, August 15, 2014 6:00 AM
> To: Sharma Bhupesh-B45370
> Cc: devicetree at vger.kernel.org; Catalin Marinas; arnd at arndb.de; Rivera Jose-
> B46482; Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Basu
> Arnab-B45036; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 3/6] Documentation: DT: Add entry for FSL Management
> Complex
> 
> [devicetree-discuss is no more, fixing up to devicetree at vger.kernel.org]
> 
> Hi,
> 
> On Fri, Aug 15, 2014 at 10:49:12AM +0100, Bhupesh Sharma wrote:
> > 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..608529e
> > --- /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.
> 
> This looks extremely simple. Is this unit self-contained or does it
> relate to other blocks which will be described separately?

The block is self-contained.  It's a complicated block, but all interactions
with happen through the command interface (1st reg region).

[The MC can do DMA and thus will relate to the SMMU, but there is some
present churn around the SMMU and we'll define the needed properties
(#stream-id-cells or whatever) when that is clear.]

Stuart

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

[Kumar Gala]

On Aug 15, 2014, at 4:49 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> 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 |   29 ++++++

Hmm, outside of something like qemu, we don?t normally have simulation model dts/support in the kernel.

> arch/arm64/boot/dts/fsl-ls2085a.dtsi     |  145 ++++++++++++++++++++++++++++++
> 2 files changed, 174 insertions(+)
> create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts
> create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

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

[Kumar Gala]

On Aug 15, 2014, at 6:00 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:

> [devicetree-discuss is no more, fixing up to devicetree-u79uwXL29TbrhsbdSgBK9A@public.gmane.orgrg]
> 
> Hi,
> 
> On Fri, Aug 15, 2014 at 10:49:12AM +0100, Bhupesh Sharma wrote:
>> 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-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> Signed-off-by: Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> Signed-off-by: J. German Rivera <German.Rivera-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> ---
>> .../devicetree/bindings/misc/fsl,qoriq-mc.txt      |   40 ++++++++++++++++++++

I’d probably start this off in bindings/soc/fsl/

>> 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..608529e
>> --- /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.

Hmm, this BRR1/BRR2 comments are a little odd, if we keep those, we should probably
also state what value is BRR1 (I think that was the one that contented the IP ID).

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

Should we distinguish the second case w/a different compat?  It seems like a major driver change if the second region isn’t there, or a different driver?

> 
> This looks extremely simple. Is this unit self-contained or does it
> relate to other blocks which will be described separately?
> 
>> +
>> +Example:
>> +
>> +        fsl_mc: fsl-mc@80c000000 {
>> +                compatible = "fsl,qoriq-mc";
>> +                reg = <0x00000008 0x0c000000 0 0x40        // MC portal base
>> +                       0x00000000 0x08340000 0 0x40000 >;  // MC control reg
> 
> Nit: could we bracket list entries individually please?
> 
> Thanks,
> Mark.
> 
> _______________________________________________

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kumar Gala]

On Aug 15, 2014, at 6:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:

> [devicetree-discuss is no more, fixing up to devicetree at vger.kernel.org]
> 
> Hi,
> 
> On Fri, Aug 15, 2014 at 10:49:12AM +0100, Bhupesh Sharma wrote:
>> 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 ++++++++++++++++++++

I?d probably start this off in bindings/soc/fsl/

>> 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..608529e
>> --- /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.

Hmm, this BRR1/BRR2 comments are a little odd, if we keep those, we should probably
also state what value is BRR1 (I think that was the one that contented the IP ID).

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

Should we distinguish the second case w/a different compat?  It seems like a major driver change if the second region isn?t there, or a different driver?

> 
> This looks extremely simple. Is this unit self-contained or does it
> relate to other blocks which will be described separately?
> 
>> +
>> +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
> 
> Nit: could we bracket list entries individually please?
> 
> Thanks,
> Mark.
> 
> _______________________________________________

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

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

[bhupesh.sharma at freescale.com]

> -----Original Message-----
> From: Kumar Gala [mailto:galak at codeaurora.org]
> Sent: Friday, August 15, 2014 7:00 PM
> To: Sharma Bhupesh-B45370
> Cc: devicetree-discuss at lists.ozlabs.org; Catalin.Marinas at arm.com;
> arnd at arndb.de; Will.Deacon at arm.com; Yoder Stuart-B08248;
> grant.likely at secretlab.ca; Basu Arnab-B45036; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> 
> On Aug 15, 2014, at 4:49 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com>
> 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 |   29 ++++++
> 
> Hmm, outside of something like qemu, we don't normally have simulation
> model dts/support in the kernel.

Well for ARMv8 - foundation model is an existing simulation model having DTS
support.

Regards,
Bhupesh

> 
> > arch/arm64/boot/dts/fsl-ls2085a.dtsi     |  145
> ++++++++++++++++++++++++++++++
> > 2 files changed, 174 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a-simu.dts
> > create mode 100644 arch/arm64/boot/dts/fsl-ls2085a.dtsi
> 
> - k
> 
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation

[PATCH 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: Friday, August 15, 2014 6:40 PM
> To: Yoder Stuart-B08248
> Cc: Sharma Bhupesh-B45370; devicetree-discuss at lists.ozlabs.org; Will
> Deacon; arnd at arndb.de; grant.likely at secretlab.ca; linux-arm-
> kernel at lists.infradead.org; Basu Arnab-B45036
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote:
> > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote:
> > > > +	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>;
> > > > +			enable-method = "spin-table";
> > > > +			cpu-release-addr = <0x0 0x8000fff8>;
> > > > +		};
> > >
> > > Why not PSCI?
> >
> > It simply is where we are today-- we don't have functioning PSCI yet
> > but plan to get there over time.
> 
> Thanks for clarification.
> 
> > All the existing device trees
> > in arch/arm64 use "spin-table", so it seems that other platforms are
> > in the same situation:
> >    apm-storm.dtsi
> 
> Not possible because there is no EL3 mode on the CPU implementation.
> 
> >    foundation-v8.dts
> >    rtsm_ve-aemv8a.dts
> 
> These work with the latest boot wrapper (which overrides the DT nodes and
> passes the PSCI information).

Right. We are working on our PSCI handler implementation in EL3 and the spin-table
approach it something we are currently supporting on the simulator model using
u-boot bootloader setting up the spin-tables.

Our patches for implementing spin-table approach in armv8 u-boot are already under
review and corresponding rework [1].

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

Regards,
Bhupesh

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

[Kumar Gala]

On Aug 15, 2014, at 9:26 AM, bhupesh.sharma at freescale.com wrote:

>> -----Original Message-----
>> From: Kumar Gala [mailto:galak at codeaurora.org]
>> Sent: Friday, August 15, 2014 7:00 PM
>> To: Sharma Bhupesh-B45370
>> Cc: devicetree-discuss at lists.ozlabs.org; Catalin.Marinas at arm.com;
>> arnd at arndb.de; Will.Deacon at arm.com; Yoder Stuart-B08248;
>> grant.likely at secretlab.ca; Basu Arnab-B45036; linux-arm-
>> kernel at lists.infradead.org
>> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
>> 
>> 
>> On Aug 15, 2014, at 4:49 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com>
>> 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 |   29 ++++++
>> 
>> Hmm, outside of something like qemu, we don't normally have simulation
>> model dts/support in the kernel.
> 
> Well for ARMv8 - foundation model is an existing simulation model having DTS
> support.
> 
> Regards,
> Bhupesh

True but that model was generally available to the open source community and was to get the base armv8 support going.

- k

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

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

[bhupesh.sharma at freescale.com]

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Friday, August 15, 2014 4:16 PM
> To: Sharma Bhupesh-B45370
> Cc: devicetree-discuss at lists.ozlabs.org; Catalin Marinas; arnd at arndb.de;
> Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-
> B45036; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/6] Documentation: DT: Add bindings for FSL NS16550A
> UART
> 
> On Fri, Aug 15, 2014 at 10:49:10AM +0100, Bhupesh Sharma wrote:
> > 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.
> 
> Should this not go in
> Documentation/devicetree/bindings/serial/of-serial.txt as with other
> NS16550A variations?
> 
> The only code for handling this string seems to live in
> arch/powerpc/kernel/legacy_serial.c. Is there a patch factoring that out
> into common code? Or is the erratum not applicable to the revision used in
> your ARMv8 SoC?
> 

The FSL specific 8250 (or NS16550A0 driver) at path drivers/tty/serial/8250/8250_fsl.c 
uses this string and provides the code to handle the erratum (see [1])

The NS16550 UART present on our SoC and the corresponding simulator model has this erratum and
hence the specific way in which IRQ are handled (fsl8250_handle_irq) by the driver (in [1])
is applicable here as well.

[1] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/tty/serial/8250/8250_fsl.c?id=refs/tags/next-20140815

Regards,
Bhupesh

> Thanks,
> Mark.
> 
> >
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > ---
> >  .../devicetree/bindings/serial/fsl-ns16550.txt     |   24
> ++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> >
> > diff --git a/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > new file mode 100644
> > index 0000000..9926e10
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > @@ -0,0 +1,24 @@
> > +* 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).
> > +
> > +- compatible: "fsl,ns16550"
> > +
> > +  Represents a single port that is compatible with the DUART found
> > + on many Freescale chips (examples include mpc8349, mpc8548,
> > + mpc8641d, p4080 and ls2085a).
> > +
> > +- reg: The base address of the UART register bank.
> > +
> > +- interrupts: A single interrupt specifier.
> > +
> > +- clock-frequency = Input clock to the baud rate divider.
> > +
> > +Example:
> > +	serial1: serial at 21c4600 {
> > +		compatible = "fsl,ns16550", "ns16550a";
> > +		reg = <0x0 0x21c4600 0x0 0x100>;
> > +		clock-frequency = <0>;
> > +		interrupts = <0 32 0x1>;
> > +	};
> > +
> > --
> > 1.7.9.5
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >

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

[Mark Rutland]

Hi Bhupesh,

On Fri, Aug 15, 2014 at 03:42:09PM +0100, bhupesh.sharma at freescale.com wrote:
> > -----Original Message-----
> > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > Sent: Friday, August 15, 2014 4:16 PM
> > To: Sharma Bhupesh-B45370
> > Cc: devicetree-discuss at lists.ozlabs.org; Catalin Marinas; arnd at arndb.de;
> > Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-
> > B45036; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH 1/6] Documentation: DT: Add bindings for FSL NS16550A
> > UART
> > 
> > On Fri, Aug 15, 2014 at 10:49:10AM +0100, Bhupesh Sharma wrote:
> > > 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.
> > 
> > Should this not go in
> > Documentation/devicetree/bindings/serial/of-serial.txt as with other
> > NS16550A variations?
> > 
> > The only code for handling this string seems to live in
> > arch/powerpc/kernel/legacy_serial.c. Is there a patch factoring that out
> > into common code? Or is the erratum not applicable to the revision used in
> > your ARMv8 SoC?
> > 
> 
> The FSL specific 8250 (or NS16550A0 driver) at path drivers/tty/serial/8250/8250_fsl.c 
> uses this string and provides the code to handle the erratum (see [1])

While the workaround itself is in that file, as far as I can see the detection
and setup is not. Even in next-20140815 it seems that only happens in
arch/powerpc/kernel/legacy_serial.c (see [2]):

[mark at leverpostej:~/src/linux]% git grep fsl8250_handle_irq next-20140815                 
next-20140815:arch/powerpc/kernel/legacy_serial.c:              port->handle_irq = fsl8250_handle_irq;
next-20140815:drivers/tty/serial/8250/8250_fsl.c:int fsl8250_handle_irq(struct uart_port *port)
next-20140815:include/linux/serial_8250.h:extern int fsl8250_handle_irq(struct uart_port *port);

I cannot see any use of the string outside of arch/powerpc:

[mark at leverpostej:~/src/linux]% git grep fsl,ns16550 next-20140815 | wc -l
102
[mark at leverpostej:~/src/linux]% git grep fsl,ns16550 next-20140815 -- arch/powerpc | wc -l
102

Am I missing something? Perhaps some macro is getting in the way of a simple
grep.

> The NS16550 UART present on our SoC and the corresponding simulator model has this erratum and
> hence the specific way in which IRQ are handled (fsl8250_handle_irq) by the driver (in [1])
> is applicable here as well.

Assuming I've not missed something, do you need to factor out the detection and
setup? Do things just happen to work on the simulator without the workaround?

Thanks,
Mark.

[2] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/powerpc/kernel/legacy_serial.c?id=refs/tags/next-20140815#n478

> [1] https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/tty/serial/8250/8250_fsl.c?id=refs/tags/next-20140815
> 
> Regards,
> Bhupesh
> 
> > Thanks,
> > Mark.
> > 
> > >
> > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > > ---
> > >  .../devicetree/bindings/serial/fsl-ns16550.txt     |   24
> > ++++++++++++++++++++
> > >  1 file changed, 24 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > > b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > > new file mode 100644
> > > index 0000000..9926e10
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > > @@ -0,0 +1,24 @@
> > > +* 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).
> > > +
> > > +- compatible: "fsl,ns16550"
> > > +
> > > +  Represents a single port that is compatible with the DUART found
> > > + on many Freescale chips (examples include mpc8349, mpc8548,
> > > + mpc8641d, p4080 and ls2085a).
> > > +
> > > +- reg: The base address of the UART register bank.
> > > +
> > > +- interrupts: A single interrupt specifier.
> > > +
> > > +- clock-frequency = Input clock to the baud rate divider.
> > > +
> > > +Example:
> > > +	serial1: serial at 21c4600 {
> > > +		compatible = "fsl,ns16550", "ns16550a";
> > > +		reg = <0x0 0x21c4600 0x0 0x100>;
> > > +		clock-frequency = <0>;
> > > +		interrupts = <0 32 0x1>;
> > > +	};
> > > +
> > > --
> > > 1.7.9.5
> > >
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > >
> 

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

[arnab.basu at freescale.com]

Hi Mark

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Friday, August 15, 2014 3:54 PM
> To: Sharma Bhupesh-B45370
> Cc: devicetree-discuss at lists.ozlabs.org; Catalin Marinas; arnd at arndb.de;
> Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-
> B45036; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> Hi,
> 
> On Fri, Aug 15, 2014 at 10:49:13AM +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 |   29 ++++++
> >  arch/arm64/boot/dts/fsl-ls2085a.dtsi     |  145
> ++++++++++++++++++++++++++++++
> >  2 files changed, 174 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.dtsi
> > b/arch/arm64/boot/dts/fsl-ls2085a.dtsi
> > new file mode 100644
> > index 0000000..aca48ac
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/fsl-ls2085a.dtsi
> > @@ -0,0 +1,145 @@
> > +/*

[...]

> > +	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>;
> > +			enable-method = "spin-table";
> > +			cpu-release-addr = <0x0 0x8000fff8>;
> > +		};
> 
> I would strongly recommend having a unique cpu-release-addr for each CPU.
>

This is more of a place holder, we intend to patch this address from U-Boot
and use individual release addresses for each CPU.

Thanks
Arnab
 
> [...]
> 
> > +	serial0: serial at 21c4500 {
> > +		device_type = "serial";
> > +		compatible = "fsl,ns16550", "ns16550a";
> > +		reg = <0x0 0x21c4500 0x0 0x100>;
> > +		clock-frequency = <0>;
> 
> Do we expect this to be filled in by the bootloader?
> 
> [...]
> 
> > > +	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: please bracket these individually as with other reg entries.
> 
> Thanks,
> Mark.

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

[Kumar Gala]

On Aug 15, 2014, at 10:21 AM, arnab.basu at freescale.com wrote:

>>> 
>>> +	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>;
>>> +			enable-method = "spin-table";
>>> +			cpu-release-addr = <0x0 0x8000fff8>;
>>> +		};
>> 
>> I would strongly recommend having a unique cpu-release-addr for each CPU.
>> 
> 
> This is more of a place holder, we intend to patch this address from U-Boot
> and use individual release addresses for each CPU.

If you are going to patch it in u-boot, than why not just have u-boot add the property and drop it from here.

If you intend to keep it here, than make <0x0 0x0> and add a comment that says u-boot will fill it out

- k
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

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

[Catalin Marinas]

On Fri, Aug 15, 2014 at 03:31:48PM +0100, bhupesh.sharma at freescale.com wrote:
> > On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote:
> > > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote:
> > > > > +	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>;
> > > > > +			enable-method = "spin-table";
> > > > > +			cpu-release-addr = <0x0 0x8000fff8>;
> > > > > +		};
> > > >
> > > > Why not PSCI?
> > >
> > > It simply is where we are today-- we don't have functioning PSCI yet
> > > but plan to get there over time.
> > 
> > Thanks for clarification.
> > 
> > > All the existing device trees
> > > in arch/arm64 use "spin-table", so it seems that other platforms are
> > > in the same situation:
> > >    apm-storm.dtsi
> > 
> > Not possible because there is no EL3 mode on the CPU implementation.
> > 
> > >    foundation-v8.dts
> > >    rtsm_ve-aemv8a.dts
> > 
> > These work with the latest boot wrapper (which overrides the DT nodes and
> > passes the PSCI information).
> 
> Right. We are working on our PSCI handler implementation in EL3 and the spin-table
> approach it something we are currently supporting on the simulator model using
> u-boot bootloader setting up the spin-tables.
> 
> Our patches for implementing spin-table approach in armv8 u-boot are already under
> review and corresponding rework [1].

It would be better if you helped with this effort to bring PSCI to
U-Boot (ARMv7 currently but easy to port to AArch64):

https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4
https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4-a20

-- 
Catalin

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

[Stuart Yoder]

> > +/ {
> > +	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>;
> > +			enable-method = "spin-table";
> > +			cpu-release-addr = <0x0 0x8000fff8>;
> > +		};
> 
> I would strongly recommend having a unique cpu-release-addr for each
> CPU.

We could do that, but we were just following existing practice in
existing arch/arm64 device trees.  The 3 existing platforms upstream
right now all have have the same cpu-release-addr value:
   apm-storm.dtsi
   foundation-v8.dts
   rtsm_ve-aemv8a.dts

Stuart

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

[Stuart Yoder]

> -----Original Message-----
> From: Kumar Gala [mailto:galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org]
> Sent: Friday, August 15, 2014 10:26 AM
> To: Basu Arnab-B45036
> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd-r2nGTMty4D4@public.gmane.org; Catalin Marinas;
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Will Deacon; Yoder Stuart-B08248;
> grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> 
> On Aug 15, 2014, at 10:21 AM, arnab.basu-KZfg59tc24xl57MIdRCFDg@public.gmane.org wrote:
> 
> >>>
> >>> +	cpus {
> >>> +		#address-cells = <2>;
> >>> +		#size-cells = <0>;
> >>> +
> >>> +		/* We have 4 clusters having 2 Cortex-A57 cores each */
> >>> +		cpu@0 {
> >>> +			device_type = "cpu";
> >>> +			compatible = "arm,cortex-a57";
> >>> +			reg = <0x0 0x0>;
> >>> +			enable-method = "spin-table";
> >>> +			cpu-release-addr = <0x0 0x8000fff8>;
> >>> +		};
> >>
> >> I would strongly recommend having a unique cpu-release-addr for each CPU.
> >>
> >
> > This is more of a place holder, we intend to patch this address from U-Boot
> > and use individual release addresses for each CPU.
> 
> If you are going to patch it in u-boot, than why not just have u-boot add the
> property and drop it from here.
> 
> If you intend to keep it here, than make <0x0 0x0> and add a comment that says
> u-boot will fill it out

As I said to Mark re: the comment on having different release addresses
per CPU, we are just following existing practice from the existing
arch/arm64 device trees:
   apm-storm.dtsi
   foundation-v8.dts
   rtsm_ve-aemv8a.dts

I think one of the reasons the cpu-release-addr is not 0x0 is that 
UEFI had(?)/has(?) limited ability to do device tree fix ups.  It's
not a problem at all in u-boot, but there is some reason all
existing device trees have the same hardcoded address for all
CPUs.

So we want to do the standard/conventional thing here that will
allow are device trees to be used in more than u-boot.

Thanks,
Stuart


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stuart Yoder]

> -----Original Message-----
> From: Kumar Gala [mailto:galak at codeaurora.org]
> Sent: Friday, August 15, 2014 10:26 AM
> To: Basu Arnab-B45036
> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd at arndb.de; Catalin Marinas;
> devicetree-discuss at lists.ozlabs.org; Will Deacon; Yoder Stuart-B08248;
> grant.likely at secretlab.ca; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> 
> On Aug 15, 2014, at 10:21 AM, arnab.basu at freescale.com wrote:
> 
> >>>
> >>> +	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>;
> >>> +			enable-method = "spin-table";
> >>> +			cpu-release-addr = <0x0 0x8000fff8>;
> >>> +		};
> >>
> >> I would strongly recommend having a unique cpu-release-addr for each CPU.
> >>
> >
> > This is more of a place holder, we intend to patch this address from U-Boot
> > and use individual release addresses for each CPU.
> 
> If you are going to patch it in u-boot, than why not just have u-boot add the
> property and drop it from here.
> 
> If you intend to keep it here, than make <0x0 0x0> and add a comment that says
> u-boot will fill it out

As I said to Mark re: the comment on having different release addresses
per CPU, we are just following existing practice from the existing
arch/arm64 device trees:
   apm-storm.dtsi
   foundation-v8.dts
   rtsm_ve-aemv8a.dts

I think one of the reasons the cpu-release-addr is not 0x0 is that 
UEFI had(?)/has(?) limited ability to do device tree fix ups.  It's
not a problem at all in u-boot, but there is some reason all
existing device trees have the same hardcoded address for all
CPUs.

So we want to do the standard/conventional thing here that will
allow are device trees to be used in more than u-boot.

Thanks,
Stuart

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

[Kumar Gala]

On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> 
> 
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org]
>> Sent: Friday, August 15, 2014 10:26 AM
>> To: Basu Arnab-B45036
>> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd-r2nGTMty4D4@public.gmane.org; Catalin Marinas;
>> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Will Deacon; Yoder Stuart-B08248;
>> grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
>> 
>> 
>> On Aug 15, 2014, at 10:21 AM, arnab.basu-KZfg59tc24xl57MIdRCFDg@public.gmane.org wrote:
>> 
>>>>> 
>>>>> +	cpus {
>>>>> +		#address-cells = <2>;
>>>>> +		#size-cells = <0>;
>>>>> +
>>>>> +		/* We have 4 clusters having 2 Cortex-A57 cores each */
>>>>> +		cpu@0 {
>>>>> +			device_type = "cpu";
>>>>> +			compatible = "arm,cortex-a57";
>>>>> +			reg = <0x0 0x0>;
>>>>> +			enable-method = "spin-table";
>>>>> +			cpu-release-addr = <0x0 0x8000fff8>;
>>>>> +		};
>>>> 
>>>> I would strongly recommend having a unique cpu-release-addr for each CPU.
>>>> 
>>> 
>>> This is more of a place holder, we intend to patch this address from U-Boot
>>> and use individual release addresses for each CPU.
>> 
>> If you are going to patch it in u-boot, than why not just have u-boot add the
>> property and drop it from here.
>> 
>> If you intend to keep it here, than make <0x0 0x0> and add a comment that says
>> u-boot will fill it out
> 
> As I said to Mark re: the comment on having different release addresses
> per CPU, we are just following existing practice from the existing
> arch/arm64 device trees:
>   apm-storm.dtsi
>   foundation-v8.dts
>   rtsm_ve-aemv8a.dts
> 
> I think one of the reasons the cpu-release-addr is not 0x0 is that 
> UEFI had(?)/has(?) limited ability to do device tree fix ups.  It's
> not a problem at all in u-boot, but there is some reason all
> existing device trees have the same hardcoded address for all
> CPUs.

Are you guys planning on supporting UEFI on this platform?

> So we want to do the standard/conventional thing here that will
> allow are device trees to be used in more than u-boot.

Well, I think the guys would say the standard thing is to move to PSCI.

- k

> 
> Thanks,
> Stuart
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kumar Gala]

On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder@freescale.com> wrote:

> 
> 
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak at codeaurora.org]
>> Sent: Friday, August 15, 2014 10:26 AM
>> To: Basu Arnab-B45036
>> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd at arndb.de; Catalin Marinas;
>> devicetree-discuss at lists.ozlabs.org; Will Deacon; Yoder Stuart-B08248;
>> grant.likely at secretlab.ca; linux-arm-kernel at lists.infradead.org
>> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
>> 
>> 
>> On Aug 15, 2014, at 10:21 AM, arnab.basu at freescale.com wrote:
>> 
>>>>> 
>>>>> +	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>;
>>>>> +			enable-method = "spin-table";
>>>>> +			cpu-release-addr = <0x0 0x8000fff8>;
>>>>> +		};
>>>> 
>>>> I would strongly recommend having a unique cpu-release-addr for each CPU.
>>>> 
>>> 
>>> This is more of a place holder, we intend to patch this address from U-Boot
>>> and use individual release addresses for each CPU.
>> 
>> If you are going to patch it in u-boot, than why not just have u-boot add the
>> property and drop it from here.
>> 
>> If you intend to keep it here, than make <0x0 0x0> and add a comment that says
>> u-boot will fill it out
> 
> As I said to Mark re: the comment on having different release addresses
> per CPU, we are just following existing practice from the existing
> arch/arm64 device trees:
>   apm-storm.dtsi
>   foundation-v8.dts
>   rtsm_ve-aemv8a.dts
> 
> I think one of the reasons the cpu-release-addr is not 0x0 is that 
> UEFI had(?)/has(?) limited ability to do device tree fix ups.  It's
> not a problem at all in u-boot, but there is some reason all
> existing device trees have the same hardcoded address for all
> CPUs.

Are you guys planning on supporting UEFI on this platform?

> So we want to do the standard/conventional thing here that will
> allow are device trees to be used in more than u-boot.

Well, I think the guys would say the standard thing is to move to PSCI.

- k

> 
> Thanks,
> Stuart
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

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

[Stuart Yoder]

> -----Original Message-----
> From: Kumar Gala [mailto:galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org]
> Sent: Friday, August 15, 2014 10:44 AM
> To: Yoder Stuart-B08248
> Cc: Basu Arnab-B45036; Mark Rutland; Sharma Bhupesh-B45370; arnd-r2nGTMty4D4@public.gmane.org;
> Catalin Marinas; Will Deacon; grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; linux-arm-
> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> 
> On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org]
> >> Sent: Friday, August 15, 2014 10:26 AM
> >> To: Basu Arnab-B45036
> >> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd-r2nGTMty4D4@public.gmane.org; Catalin Marinas;
> >> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Will Deacon; Yoder Stuart-B08248;
> >> grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> >> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> >>
> >>
> >> On Aug 15, 2014, at 10:21 AM, arnab.basu-KZfg59tc24xl57MIdRCFDg@public.gmane.org wrote:
> >>
> >>>>>
> >>>>> +	cpus {
> >>>>> +		#address-cells = <2>;
> >>>>> +		#size-cells = <0>;
> >>>>> +
> >>>>> +		/* We have 4 clusters having 2 Cortex-A57 cores each */
> >>>>> +		cpu@0 {
> >>>>> +			device_type = "cpu";
> >>>>> +			compatible = "arm,cortex-a57";
> >>>>> +			reg = <0x0 0x0>;
> >>>>> +			enable-method = "spin-table";
> >>>>> +			cpu-release-addr = <0x0 0x8000fff8>;
> >>>>> +		};
> >>>>
> >>>> I would strongly recommend having a unique cpu-release-addr for each CPU.
> >>>>
> >>>
> >>> This is more of a place holder, we intend to patch this address from U-Boot
> >>> and use individual release addresses for each CPU.
> >>
> >> If you are going to patch it in u-boot, than why not just have u-boot add
> the
> >> property and drop it from here.
> >>
> >> If you intend to keep it here, than make <0x0 0x0> and add a comment that
> says
> >> u-boot will fill it out
> >
> > As I said to Mark re: the comment on having different release addresses
> > per CPU, we are just following existing practice from the existing
> > arch/arm64 device trees:
> >   apm-storm.dtsi
> >   foundation-v8.dts
> >   rtsm_ve-aemv8a.dts
> >
> > I think one of the reasons the cpu-release-addr is not 0x0 is that
> > UEFI had(?)/has(?) limited ability to do device tree fix ups.  It's
> > not a problem at all in u-boot, but there is some reason all
> > existing device trees have the same hardcoded address for all
> > CPUs.
> 
> Are you guys planning on supporting UEFI on this platform?

Yes.

> > So we want to do the standard/conventional thing here that will
> > allow are device trees to be used in more than u-boot.
> 
> Well, I think the guys would say the standard thing is to move to PSCI.

Agree.  That is our plan.  But it looks like at this point in
time all the device tree have a common denominator spin table
mechanim that gets updated/overriden if PSCI is supported.

Stuart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stuart Yoder]

> -----Original Message-----
> From: Kumar Gala [mailto:galak at codeaurora.org]
> Sent: Friday, August 15, 2014 10:44 AM
> To: Yoder Stuart-B08248
> Cc: Basu Arnab-B45036; Mark Rutland; Sharma Bhupesh-B45370; arnd at arndb.de;
> Catalin Marinas; Will Deacon; grant.likely at secretlab.ca; linux-arm-
> kernel at lists.infradead.org; devicetree at vger.kernel.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> 
> On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder@freescale.com> wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak at codeaurora.org]
> >> Sent: Friday, August 15, 2014 10:26 AM
> >> To: Basu Arnab-B45036
> >> Cc: Mark Rutland; Sharma Bhupesh-B45370; arnd at arndb.de; Catalin Marinas;
> >> devicetree-discuss at lists.ozlabs.org; Will Deacon; Yoder Stuart-B08248;
> >> grant.likely at secretlab.ca; linux-arm-kernel at lists.infradead.org
> >> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> >>
> >>
> >> On Aug 15, 2014, at 10:21 AM, arnab.basu at freescale.com wrote:
> >>
> >>>>>
> >>>>> +	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>;
> >>>>> +			enable-method = "spin-table";
> >>>>> +			cpu-release-addr = <0x0 0x8000fff8>;
> >>>>> +		};
> >>>>
> >>>> I would strongly recommend having a unique cpu-release-addr for each CPU.
> >>>>
> >>>
> >>> This is more of a place holder, we intend to patch this address from U-Boot
> >>> and use individual release addresses for each CPU.
> >>
> >> If you are going to patch it in u-boot, than why not just have u-boot add
> the
> >> property and drop it from here.
> >>
> >> If you intend to keep it here, than make <0x0 0x0> and add a comment that
> says
> >> u-boot will fill it out
> >
> > As I said to Mark re: the comment on having different release addresses
> > per CPU, we are just following existing practice from the existing
> > arch/arm64 device trees:
> >   apm-storm.dtsi
> >   foundation-v8.dts
> >   rtsm_ve-aemv8a.dts
> >
> > I think one of the reasons the cpu-release-addr is not 0x0 is that
> > UEFI had(?)/has(?) limited ability to do device tree fix ups.  It's
> > not a problem at all in u-boot, but there is some reason all
> > existing device trees have the same hardcoded address for all
> > CPUs.
> 
> Are you guys planning on supporting UEFI on this platform?

Yes.

> > So we want to do the standard/conventional thing here that will
> > allow are device trees to be used in more than u-boot.
> 
> Well, I think the guys would say the standard thing is to move to PSCI.

Agree.  That is our plan.  But it looks like at this point in
time all the device tree have a common denominator spin table
mechanim that gets updated/overriden if PSCI is supported.

Stuart

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

[Stuart Yoder]

> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> Sent: Friday, August 15, 2014 10:29 AM
> To: Sharma Bhupesh-B45370
> Cc: Yoder Stuart-B08248; devicetree-discuss at lists.ozlabs.org; Will Deacon;
> arnd at arndb.de; grant.likely at secretlab.ca; linux-arm-kernel at lists.infradead.org;
> Basu Arnab-B45036
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> On Fri, Aug 15, 2014 at 03:31:48PM +0100, bhupesh.sharma at freescale.com wrote:
> > > On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote:
> > > > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote:
> > > > > > +	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>;
> > > > > > +			enable-method = "spin-table";
> > > > > > +			cpu-release-addr = <0x0 0x8000fff8>;
> > > > > > +		};
> > > > >
> > > > > Why not PSCI?
> > > >
> > > > It simply is where we are today-- we don't have functioning PSCI yet
> > > > but plan to get there over time.
> > >
> > > Thanks for clarification.
> > >
> > > > All the existing device trees
> > > > in arch/arm64 use "spin-table", so it seems that other platforms are
> > > > in the same situation:
> > > >    apm-storm.dtsi
> > >
> > > Not possible because there is no EL3 mode on the CPU implementation.
> > >
> > > >    foundation-v8.dts
> > > >    rtsm_ve-aemv8a.dts
> > >
> > > These work with the latest boot wrapper (which overrides the DT nodes and
> > > passes the PSCI information).
> >
> > Right. We are working on our PSCI handler implementation in EL3 and the spin-
> table
> > approach it something we are currently supporting on the simulator model
> using
> > u-boot bootloader setting up the spin-tables.
> >
> > Our patches for implementing spin-table approach in armv8 u-boot are already
> under
> > review and corresponding rework [1].
> 
> It would be better if you helped with this effort to bring PSCI to
> U-Boot (ARMv7 currently but easy to port to AArch64):
> 
> https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4
> https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4-
> a20

Is the intent to eventually purge the device trees of enable-method/cpu-release-addr
and have that set by the boot firmware?  Or, keep the spin-table method 
around as a least common denominator mechanism and override it when
necessary?   Wondering what the longer term thinking is...

Thanks,
Stuart

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

[Catalin Marinas]

On Fri, Aug 15, 2014 at 04:49:53PM +0100, Stuart Yoder wrote:
> > On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > So we want to do the standard/conventional thing here that will
> > > allow are device trees to be used in more than u-boot.
> > 
> > Well, I think the guys would say the standard thing is to move to PSCI.
> 
> Agree.  That is our plan.  But it looks like at this point in
> time all the device tree have a common denominator spin table
> mechanim that gets updated/overriden if PSCI is supported.

That's for historical reasons because at the time there was no PSCI and
now we have to preserve backwards compatibility with older boot
wrappers. The only hardware currently having a DT in the arm64 tree is
the APM one which cannot implement PSCI because there is no EL3.

(and I think we should really get a proper arm64 PSCI implementation in
U-Boot)

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Catalin Marinas]

On Fri, Aug 15, 2014 at 04:49:53PM +0100, Stuart Yoder wrote:
> > On Aug 15, 2014, at 10:41 AM, Stuart Yoder <stuart.yoder@freescale.com> wrote:
> > > So we want to do the standard/conventional thing here that will
> > > allow are device trees to be used in more than u-boot.
> > 
> > Well, I think the guys would say the standard thing is to move to PSCI.
> 
> Agree.  That is our plan.  But it looks like at this point in
> time all the device tree have a common denominator spin table
> mechanim that gets updated/overriden if PSCI is supported.

That's for historical reasons because at the time there was no PSCI and
now we have to preserve backwards compatibility with older boot
wrappers. The only hardware currently having a DT in the arm64 tree is
the APM one which cannot implement PSCI because there is no EL3.

(and I think we should really get a proper arm64 PSCI implementation in
U-Boot)

-- 
Catalin

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

[Mark Rutland]

Hi Stuart,

On Fri, Aug 15, 2014 at 04:37:06PM +0100, Stuart Yoder wrote:
> > > +/ {
> > > +	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>;
> > > +			enable-method = "spin-table";
> > > +			cpu-release-addr = <0x0 0x8000fff8>;
> > > +		};
> > 
> > I would strongly recommend having a unique cpu-release-addr for each
> > CPU.
> 
> We could do that, but we were just following existing practice in
> existing arch/arm64 device trees.  The 3 existing platforms upstream
> right now all have have the same cpu-release-addr value:
>    apm-storm.dtsi
>    foundation-v8.dts
>    rtsm_ve-aemv8a.dts

In general, following existing examples is a good idea. I'm not faulting
you for that.

Unfortunately there are plenty of bad examples in DTS in the kernel.

W.R.T. unique addresses for spin-table this is something we learnt after
those dts files were upstreamed. It's not possible to change those dts
files in the kernel without breaking older firmwares/bootwrappers which
don't patch the DTB.

Cheers,
Mark.

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

[Stuart Yoder]

> -----Original Message-----
> From: Kumar Gala [mailto:galak at codeaurora.org]
> Sent: Friday, August 15, 2014 9:41 AM
> To: Sharma Bhupesh-B45370
> Cc: arnd at arndb.de; Catalin.Marinas at arm.com; devicetree-
> discuss at lists.ozlabs.org; Will.Deacon at arm.com; Yoder Stuart-B08248;
> grant.likely at secretlab.ca; Basu Arnab-B45036; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> 
> On Aug 15, 2014, at 9:26 AM, bhupesh.sharma at freescale.com wrote:
> 
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak at codeaurora.org]
> >> Sent: Friday, August 15, 2014 7:00 PM
> >> To: Sharma Bhupesh-B45370
> >> Cc: devicetree-discuss at lists.ozlabs.org; Catalin.Marinas at arm.com;
> >> arnd at arndb.de; Will.Deacon at arm.com; Yoder Stuart-B08248;
> >> grant.likely at secretlab.ca; Basu Arnab-B45036; linux-arm-
> >> kernel at lists.infradead.org
> >> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> >>
> >>
> >> On Aug 15, 2014, at 4:49 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com>
> >> 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 |   29 ++++++
> >>
> >> Hmm, outside of something like qemu, we don't normally have simulation
> >> model dts/support in the kernel.
> >
> > Well for ARMv8 - foundation model is an existing simulation model having DTS
> > support.
> >
> > Regards,
> > Bhupesh
> 
> True but that model was generally available to the open source community and
> was to get the base armv8 support going.

Note, the LS2085A SoC definition itself is in fsl-ls2085a.dtsi.  The
fsl-ls2085a-simu is simply a simulation machine that uses that, 
and will generally reflect board-level differences from a physical
machine in things like Ethernet PHYs and so on.  The simulator is
available now to Freescale customers and I expect significant use
by them over the next few years.

If there is a hard rule that 'simulator-based machines are not allowed'
in the kernel, thats fine, but I don't understand why that should be
the case.

Thanks,
Stuart

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

[Mark Rutland]

Hi Stuart

> Is the intent to eventually purge the device trees of enable-method/cpu-release-addr
> and have that set by the boot firmware?  Or, keep the spin-table method 
> around as a least common denominator mechanism and override it when
> necessary?   Wondering what the longer term thinking is...

Personally I'd like to see anything that's not a fixed HW property be
omitted in the DTS and injected by the boot firmware. Certainly anything
which is a property of the FW should be injected by that FW.

That would cover:

- Any enable-method property and related properties and/or nodes. This
  is heavily dependent on the boot firmware configuration, and can
  differ substantially between instances of a given board.

- Most /memreserve/ uses (as these typically protect firmware or
  trampoline code).

- Any memory nodes where memory can be dynamically populated on the
  board.

- CPU nodes if the presence of said CPUs is dynamically determined. 
  
In the long term I'd like to see DTS get fully decoupled from the
kernel.

Cheers,
Mark.

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

[Catalin Marinas]

On Fri, Aug 15, 2014 at 04:57:13PM +0100, Stuart Yoder wrote:
> > On Fri, Aug 15, 2014 at 03:31:48PM +0100, bhupesh.sharma at freescale.com wrote:
> > > > On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote:
> > > > > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote:
> > > > > > > +	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>;
> > > > > > > +			enable-method = "spin-table";
> > > > > > > +			cpu-release-addr = <0x0 0x8000fff8>;
> > > > > > > +		};
> > > > > >
> > > > > > Why not PSCI?
> > > > >
> > > > > It simply is where we are today-- we don't have functioning PSCI yet
> > > > > but plan to get there over time.
> > > >
> > > > Thanks for clarification.
> > > >
> > > > > All the existing device trees
> > > > > in arch/arm64 use "spin-table", so it seems that other platforms are
> > > > > in the same situation:
> > > > >    apm-storm.dtsi
> > > >
> > > > Not possible because there is no EL3 mode on the CPU implementation.
> > > >
> > > > >    foundation-v8.dts
> > > > >    rtsm_ve-aemv8a.dts
> > > >
> > > > These work with the latest boot wrapper (which overrides the DT nodes and
> > > > passes the PSCI information).
> > >
> > > Right. We are working on our PSCI handler implementation in EL3 and the spin-
> > table
> > > approach it something we are currently supporting on the simulator model
> > using
> > > u-boot bootloader setting up the spin-tables.
> > >
> > > Our patches for implementing spin-table approach in armv8 u-boot are already
> > under
> > > review and corresponding rework [1].
> > 
> > It would be better if you helped with this effort to bring PSCI to
> > U-Boot (ARMv7 currently but easy to port to AArch64):
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4
> > https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/log/?h=wip/psci-v4-
> > a20
> 
> Is the intent to eventually purge the device trees of enable-method/cpu-release-addr
> and have that set by the boot firmware?  Or, keep the spin-table method 
> around as a least common denominator mechanism and override it when
> necessary?   Wondering what the longer term thinking is...

There are only two dts files that would support PSCI but because of
older boot wrappers, we can't change the default. However, the aim for
new platforms is to start with PSCI by default rather than spin-table
and looking at changing them later.

-- 
Catalin

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

[Stuart Yoder]

> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> Sent: Friday, August 15, 2014 11:25 AM
> To: Yoder Stuart-B08248
> Cc: Sharma Bhupesh-B45370; devicetree-discuss at lists.ozlabs.org; Will Deacon;
> arnd at arndb.de; grant.likely at secretlab.ca; linux-arm-kernel at lists.infradead.org;
> Basu Arnab-B45036
> Subject: Re: [PATCH 4/6] arm64: Add DTS support for FSL's LS2085A SoC
> 
> On Fri, Aug 15, 2014 at 04:57:13PM +0100, Stuart Yoder wrote:
> > > On Fri, Aug 15, 2014 at 03:31:48PM +0100, bhupesh.sharma at freescale.com
> wrote:
> > > > > On Fri, Aug 15, 2014 at 01:53:13PM +0100, Stuart Yoder wrote:
> > > > > > > On Fri, Aug 15, 2014 at 10:49:13AM +0100, Bhupesh Sharma wrote:
> > > > > > > > +	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>;
> > > > > > > > +			enable-method = "spin-table";
> > > > > > > > +			cpu-release-addr = <0x0 0x8000fff8>;
> > > > > > > > +		};
> > > > > > >
> > > > > > > Why not PSCI?
> > > > > >
> > > > > > It simply is where we are today-- we don't have functioning PSCI yet
> > > > > > but plan to get there over time.
> > > > >
> > > > > Thanks for clarification.
> > > > >
> > > > > > All the existing device trees
> > > > > > in arch/arm64 use "spin-table", so it seems that other platforms are
> > > > > > in the same situation:
> > > > > >    apm-storm.dtsi
> > > > >
> > > > > Not possible because there is no EL3 mode on the CPU implementation.
> > > > >
> > > > > >    foundation-v8.dts
> > > > > >    rtsm_ve-aemv8a.dts
> > > > >
> > > > > These work with the latest boot wrapper (which overrides the DT nodes
> and
> > > > > passes the PSCI information).
> > > >
> > > > Right. We are working on our PSCI handler implementation in EL3 and the
> spin-
> > > table
> > > > approach it something we are currently supporting on the simulator model
> > > using
> > > > u-boot bootloader setting up the spin-tables.
> > > >
> > > > Our patches for implementing spin-table approach in armv8 u-boot are
> already
> > > under
> > > > review and corresponding rework [1].
> > >
> > > It would be better if you helped with this effort to bring PSCI to
> > > U-Boot (ARMv7 currently but easy to port to AArch64):
> > >
> > > https://git.kernel.org/cgit/linux/kernel/git/maz/u-
> boot.git/log/?h=wip/psci-v4
> > > https://git.kernel.org/cgit/linux/kernel/git/maz/u-
> boot.git/log/?h=wip/psci-v4-
> > > a20
> >
> > Is the intent to eventually purge the device trees of enable-method/cpu-
> release-addr
> > and have that set by the boot firmware?  Or, keep the spin-table method
> > around as a least common denominator mechanism and override it when
> > necessary?   Wondering what the longer term thinking is...
> 
> There are only two dts files that would support PSCI but because of
> older boot wrappers, we can't change the default. However, the aim for
> new platforms is to start with PSCI by default rather than spin-table
> and looking at changing them later.

Ok.  There's no issue removing those properties and then
having u-boot do fixups of the release-method...which is 
"spin-table" for now, and PSCI eventually.  I'm not yet familiar
with what UEFI limitations exist regarding fixups, but assume
they can be solved in a bootwrapper if necessary.

Thanks,
Stuart

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

[bhupesh.sharma at freescale.com]

Hi Mark,

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Friday, August 15, 2014 8:34 PM
> To: Sharma Bhupesh-B45370
> Cc: devicetree-discuss at lists.ozlabs.org; Catalin Marinas; arnd at arndb.de;
> Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-
> B45036; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/6] Documentation: DT: Add bindings for FSL NS16550A
> The UART
> 
> Hi Bhupesh,
> 
> On Fri, Aug 15, 2014 at 03:42:09PM +0100, bhupesh.sharma at freescale.com
> wrote:
> > > -----Original Message-----
> > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > > Sent: Friday, August 15, 2014 4:16 PM
> > > To: Sharma Bhupesh-B45370
> > > Cc: devicetree-discuss at lists.ozlabs.org; Catalin Marinas;
> > > arnd at arndb.de; Will Deacon; Yoder Stuart-B08248;
> > > grant.likely at secretlab.ca; Basu Arnab- B45036;
> > > linux-arm-kernel at lists.infradead.org
> > > Subject: Re: [PATCH 1/6] Documentation: DT: Add bindings for FSL
> > > NS16550A UART
> > >
> > > On Fri, Aug 15, 2014 at 10:49:10AM +0100, Bhupesh Sharma wrote:
> > > > 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.
> > >
> > > Should this not go in
> > > Documentation/devicetree/bindings/serial/of-serial.txt as with other
> > > NS16550A variations?
> > >
> > > The only code for handling this string seems to live in
> > > arch/powerpc/kernel/legacy_serial.c. Is there a patch factoring that
> > > out into common code? Or is the erratum not applicable to the
> > > revision used in your ARMv8 SoC?
> > >
> >
> > The FSL specific 8250 (or NS16550A0 driver) at path
> > drivers/tty/serial/8250/8250_fsl.c
> > uses this string and provides the code to handle the erratum (see [1])
> 
> While the workaround itself is in that file, as far as I can see the
> detection and setup is not. Even in next-20140815 it seems that only
> happens in arch/powerpc/kernel/legacy_serial.c (see [2]):
> 
> [mark at leverpostej:~/src/linux]% git grep fsl8250_handle_irq next-20140815
> next-20140815:arch/powerpc/kernel/legacy_serial.c:              port-
> >handle_irq = fsl8250_handle_irq;
> next-20140815:drivers/tty/serial/8250/8250_fsl.c:int
> fsl8250_handle_irq(struct uart_port *port) next-
> 20140815:include/linux/serial_8250.h:extern int fsl8250_handle_irq(struct
> uart_port *port);
> 
> I cannot see any use of the string outside of arch/powerpc:
> 
> [mark at leverpostej:~/src/linux]% git grep fsl,ns16550 next-20140815 | wc -l
> 102
> [mark at leverpostej:~/src/linux]% git grep fsl,ns16550 next-20140815 --
> arch/powerpc | wc -l
> 102
> 
> Am I missing something? Perhaps some macro is getting in the way of a
> simple grep.
> 
> > The NS16550 UART present on our SoC and the corresponding simulator
> > model has this erratum and hence the specific way in which IRQ are
> > handled (fsl8250_handle_irq) by the driver (in [1]) is applicable here
> as well.
> 
> Assuming I've not missed something, do you need to factor out the
> detection and setup? Do things just happen to work on the simulator
> without the workaround?

You are right. The simulator platform doesn't take into account the erratum, however
we need to take is into account for the emulator and silicon platforms.

I am currently working to fork this out into a common code base so that both
PPC and ARM platforms can use the same and a patch for the same is in my to-do list.

So, I sent out the DT documentation patch early (as it is equally applicable to  both
PPC and ARM platforms) and the patch that makes this code leg usable for both ARM and
PPC platform will follow soon.

Regards,
Bhupesh

> Thanks,
> Mark.
> 
> [2] https://git.kernel.org/cgit/linux/kernel/git/next/linux-
> next.git/tree/arch/powerpc/kernel/legacy_serial.c?id=refs/tags/next-
> 20140815#n478
> 
> > [1]
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/
> > drivers/tty/serial/8250/8250_fsl.c?id=refs/tags/next-20140815
> >
> > Regards,
> > Bhupesh
> >
> > > Thanks,
> > > Mark.
> > >
> > > >
> > > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > > > ---
> > > >  .../devicetree/bindings/serial/fsl-ns16550.txt     |   24
> > > ++++++++++++++++++++
> > > >  1 file changed, 24 insertions(+)
> > > >  create mode 100644
> > > > Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > > > b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > > > new file mode 100644
> > > > index 0000000..9926e10
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/serial/fsl-ns16550.txt
> > > > @@ -0,0 +1,24 @@
> > > > +* 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).
> > > > +
> > > > +- compatible: "fsl,ns16550"
> > > > +
> > > > +  Represents a single port that is compatible with the DUART
> > > > + found on many Freescale chips (examples include mpc8349,
> > > > + mpc8548, mpc8641d, p4080 and ls2085a).
> > > > +
> > > > +- reg: The base address of the UART register bank.
> > > > +
> > > > +- interrupts: A single interrupt specifier.
> > > > +
> > > > +- clock-frequency = Input clock to the baud rate divider.
> > > > +
> > > > +Example:
> > > > +	serial1: serial at 21c4600 {
> > > > +		compatible = "fsl,ns16550", "ns16550a";
> > > > +		reg = <0x0 0x21c4600 0x0 0x100>;
> > > > +		clock-frequency = <0>;
> > > > +		interrupts = <0 32 0x1>;
> > > > +	};
> > > > +
> > > > --
> > > > 1.7.9.5
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > linux-arm-kernel mailing list
> > > > linux-arm-kernel at lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > >
> >

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

[Mark Rutland]

Hi Bhupesh,

[...]

> > > > -----Original Message-----
> > > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > > > Sent: Friday, August 15, 2014 4:16 PM
> > > > To: Sharma Bhupesh-B45370
> > > > Cc: devicetree-discuss at lists.ozlabs.org; Catalin Marinas;
> > > > arnd at arndb.de; Will Deacon; Yoder Stuart-B08248;
> > > > grant.likely at secretlab.ca; Basu Arnab- B45036;
> > > > linux-arm-kernel at lists.infradead.org
> > > > Subject: Re: [PATCH 1/6] Documentation: DT: Add bindings for FSL
> > > > NS16550A UART
> > > >
> > > > On Fri, Aug 15, 2014 at 10:49:10AM +0100, Bhupesh Sharma wrote:
> > > > > 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.
> > > >
> > > > Should this not go in
> > > > Documentation/devicetree/bindings/serial/of-serial.txt as with other
> > > > NS16550A variations?
> > > >
> > > > The only code for handling this string seems to live in
> > > > arch/powerpc/kernel/legacy_serial.c. Is there a patch factoring that
> > > > out into common code? Or is the erratum not applicable to the
> > > > revision used in your ARMv8 SoC?
> > > >
> > >
> > > The FSL specific 8250 (or NS16550A0 driver) at path
> > > drivers/tty/serial/8250/8250_fsl.c
> > > uses this string and provides the code to handle the erratum (see [1])
> > 
> > While the workaround itself is in that file, as far as I can see the
> > detection and setup is not. Even in next-20140815 it seems that only
> > happens in arch/powerpc/kernel/legacy_serial.c (see [2]):
> > 
> > [mark at leverpostej:~/src/linux]% git grep fsl8250_handle_irq next-20140815
> > next-20140815:arch/powerpc/kernel/legacy_serial.c:              port-
> > >handle_irq = fsl8250_handle_irq;
> > next-20140815:drivers/tty/serial/8250/8250_fsl.c:int
> > fsl8250_handle_irq(struct uart_port *port) next-
> > 20140815:include/linux/serial_8250.h:extern int fsl8250_handle_irq(struct
> > uart_port *port);
> > 
> > I cannot see any use of the string outside of arch/powerpc:
> > 
> > [mark at leverpostej:~/src/linux]% git grep fsl,ns16550 next-20140815 | wc -l
> > 102
> > [mark at leverpostej:~/src/linux]% git grep fsl,ns16550 next-20140815 --
> > arch/powerpc | wc -l
> > 102
> > 
> > Am I missing something? Perhaps some macro is getting in the way of a
> > simple grep.
> > 
> > > The NS16550 UART present on our SoC and the corresponding simulator
> > > model has this erratum and hence the specific way in which IRQ are
> > > handled (fsl8250_handle_irq) by the driver (in [1]) is applicable here
> > as well.
> > 
> > Assuming I've not missed something, do you need to factor out the
> > detection and setup? Do things just happen to work on the simulator
> > without the workaround?
> 
> You are right. The simulator platform doesn't take into account the
> erratum, however we need to take is into account for the emulator and
> silicon platforms.
> 
> I am currently working to fork this out into a common code base so
> that both PPC and ARM platforms can use the same and a patch for the
> same is in my to-do list.
>
> So, I sent out the DT documentation patch early (as it is equally
> applicable to  both PPC and ARM platforms) and the patch that makes
> this code leg usable for both ARM and PPC platform will follow soon.

Ok.

My only issue with the DT binding is the placement; I think that should
live with the other NS16550A variations.

Cheers,
Mark.

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

[bhupesh.sharma at freescale.com]

Hi Mark,

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Wednesday, August 20, 2014 5:02 PM
> To: Sharma Bhupesh-B45370
> Cc: devicetree-discuss at lists.ozlabs.org; Catalin Marinas; arnd at arndb.de;
> Will Deacon; Yoder Stuart-B08248; grant.likely at secretlab.ca; Basu Arnab-
> B45036; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/6] Documentation: DT: Add bindings for FSL NS16550A
> The UART
> 
> Hi Bhupesh,
> 
> [...]
> 
> > > > > -----Original Message-----
> > > > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > > > > Sent: Friday, August 15, 2014 4:16 PM
> > > > > To: Sharma Bhupesh-B45370
> > > > > Cc: devicetree-discuss at lists.ozlabs.org; Catalin Marinas;
> > > > > arnd at arndb.de; Will Deacon; Yoder Stuart-B08248;
> > > > > grant.likely at secretlab.ca; Basu Arnab- B45036;
> > > > > linux-arm-kernel at lists.infradead.org
> > > > > Subject: Re: [PATCH 1/6] Documentation: DT: Add bindings for FSL
> > > > > NS16550A UART
> > > > >
> > > > > On Fri, Aug 15, 2014 at 10:49:10AM +0100, Bhupesh Sharma wrote:
> > > > > > 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.
> > > > >
> > > > > Should this not go in
> > > > > Documentation/devicetree/bindings/serial/of-serial.txt as with
> > > > > other NS16550A variations?
> > > > >
> > > > > The only code for handling this string seems to live in
> > > > > arch/powerpc/kernel/legacy_serial.c. Is there a patch factoring
> > > > > that out into common code? Or is the erratum not applicable to
> > > > > the revision used in your ARMv8 SoC?
> > > > >
> > > >
> > > > The FSL specific 8250 (or NS16550A0 driver) at path
> > > > drivers/tty/serial/8250/8250_fsl.c
> > > > uses this string and provides the code to handle the erratum (see
> > > > [1])
> > >
> > > While the workaround itself is in that file, as far as I can see the
> > > detection and setup is not. Even in next-20140815 it seems that only
> > > happens in arch/powerpc/kernel/legacy_serial.c (see [2]):
> > >
> > > [mark at leverpostej:~/src/linux]% git grep fsl8250_handle_irq next-
> 20140815
> > > next-20140815:arch/powerpc/kernel/legacy_serial.c:              port-
> > > >handle_irq = fsl8250_handle_irq;
> > > next-20140815:drivers/tty/serial/8250/8250_fsl.c:int
> > > fsl8250_handle_irq(struct uart_port *port) next-
> > > 20140815:include/linux/serial_8250.h:extern int
> > > fsl8250_handle_irq(struct uart_port *port);
> > >
> > > I cannot see any use of the string outside of arch/powerpc:
> > >
> > > [mark at leverpostej:~/src/linux]% git grep fsl,ns16550 next-20140815 |
> > > wc -l
> > > 102
> > > [mark at leverpostej:~/src/linux]% git grep fsl,ns16550 next-20140815
> > > -- arch/powerpc | wc -l
> > > 102
> > >
> > > Am I missing something? Perhaps some macro is getting in the way of
> > > a simple grep.
> > >
> > > > The NS16550 UART present on our SoC and the corresponding
> > > > simulator model has this erratum and hence the specific way in
> > > > which IRQ are handled (fsl8250_handle_irq) by the driver (in [1])
> > > > is applicable here
> > > as well.
> > >
> > > Assuming I've not missed something, do you need to factor out the
> > > detection and setup? Do things just happen to work on the simulator
> > > without the workaround?
> >
> > You are right. The simulator platform doesn't take into account the
> > erratum, however we need to take is into account for the emulator and
> > silicon platforms.
> >
> > I am currently working to fork this out into a common code base so
> > that both PPC and ARM platforms can use the same and a patch for the
> > same is in my to-do list.
> >
> > So, I sent out the DT documentation patch early (as it is equally
> > applicable to  both PPC and ARM platforms) and the patch that makes
> > this code leg usable for both ARM and PPC platform will follow soon.
> 
> Ok.
> 
> My only issue with the DT binding is the placement; I think that should
> live with the other NS16550A variations.

Sure. I will look at how I can change the DT binding placement and then
address it in my v2.

Regards,
Bhupesh

> Cheers,
> Mark.