[PATCH v2 00/10] ARM64: Update support for FSL's LS2085A SoC

[PATCH v2 00/10] ARM64: Update support for FSL's LS2085A SoC

[Bhupesh Sharma]

This is the v2 of the patchset which updates the support for FSL's LS2085A SoC
which is now being renamed to LS2080A (and is based on ARMv8 architecture).

Here is a description of what this patchset tries to achieve:

  - Patch 1:
    Freescale will be a churning out a host of ARMv8 based SoCs which
    will be based on a similar overall SoC architecture. So, this patch
    converts the existing infrastructure to use the generic convention
    ARCH_LAYERSCAPE. Also since Freescale is renaming LS2085A to LS2080A
    this patch fixes the same as well.

    Further details of the LS2080a based platforms can be seen here:
    http://www.freescale.com/products/arm-processors/qoriq-arm-processors/qoriq-ls2080a-40a-multicore-communications-processors:LS2080A?fsrch=1&sr=1&pageNum=1

  - Patch 2:
    Adds DTS binding documentation for Freescale's LS2080A QDS and RDB boards

  - Patch 3:
    This patch adds bindings for QIXIS FPGA controller found on FSL boards.

  - Patch 4:
    Updates PCIe devicetree binding documentation for LS2080A.

  - Patch 5:
    Updates clk-qoriq bindings for FSL's chassis-3.0 SoCs
  
  - Patch 6:
    Addresses changes required in clk-qoriq driver to handle
    little-endian clockgen SoCs like LS2080A.

  - Patch 7:
    Updates the support of various peripherals (PMU, Watchdog, SMMU,
    SATA, PCI, SPI, etc.) present on FSL LS2080a SoC in the SoC DTSI.

  - Patch 8:
    Updates the DTS LS2085a simulator platform to reflect the new
    peripherals added in the DTSI.

  - Patch 9:
    Adds new DTS files for LS2085a based QDS and RDB boards.
  
  - Patch 10:
    Adds build support for LS2085a QDS and RDB board DTS files.

Rebasing details:
-----------------
- Rebased against arm-soc git tree, branch: next/dt

- Rebased against Scott's latest v2 of QorIQ clk fixes, which can be
  viewed here:
  https://patchwork.kernel.org/patch/7020471/
  https://patchwork.kernel.org/patch/7020541/
  https://patchwork.kernel.org/patch/7020491/
  https://patchwork.kernel.org/patch/7020481/
  https://patchwork.kernel.org/patch/7020501/

Changes since v1:
----------------
(v1 can be viewed here: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/334990.html)

- Addressed Mark's comments regarding the FTM alarm timer node.
	Removed the node for now as the FTM binding change related discussion is
	underway with the maintainers.
- Added support for Layerscape family of SoCs and changed name of
  LS2085a chip to LS2080a chip.
- Updated QorIQ clk driver to support LS2080a like SoCs.
- Added support for SATA nodes in the DTSI.
- Added binding document for on-board QIXIS FPGA controllers.

Note:
-----
I get a checkpatch warning for the amba-bus compatible string being missing from
Documentation/devicetree/bindings/ . I am not aware if some patch is already
being worked on, to solve the same:
	compatible = "arm,amba-bus";

If not, I can try to send a patch, with the re-spin of this patchset.

Bhupesh Sharma (9):
  arm64: Use generic Layerscape SoC family naming & rename LS2085A to
    LS2080A
  Documentation: DT: Add entry for FSL LS2080A QDS and RDB boards
  Documentation/dts: Add bindings for QIXIS FPGA controller found on
    FSL boards
  doc/bindings: Update PCIe devicetree binding documentation for
    LS2080A
  doc/bindings: Update clk-qoriq bindings for FSL's chassis-3.0 SoCs
  dts/ls2085a: Update DTSI to add support of various peripherals
  dts/ls2085a: Update Simulator DTS to add support of various
    peripherals
  dts/ls2080a: Add DTS support for LS2080a QDS & RDB boards
  dts/Makefile: Add build support for LS2080a QDS & RDB board DTS

Scott Wood (1):
  clk: qoriq: Add ls2080a support.

 .../devicetree/bindings/arm/fsl,board.txt          |   31 +
 Documentation/devicetree/bindings/arm/fsl.txt      |   16 +-
 .../devicetree/bindings/clock/qoriq-clock.txt      |   16 +-
 .../devicetree/bindings/pci/layerscape-pci.txt     |    3 +-
 arch/arm64/Kconfig                                 |    6 +-
 arch/arm64/boot/dts/freescale/Makefile             |    2 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts  |  198 +++++++
 .../{fsl-ls2085a-simu.dts => fsl-ls2080a-rdb.dts}  |  126 +++-
 .../{fsl-ls2085a-simu.dts => fsl-ls2080a-simu.dts} |   64 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi     |  612 ++++++++++++++++++++
 arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi     |  163 ------
 arch/arm64/configs/defconfig                       |    2 +-
 drivers/clk/Kconfig                                |    2 +-
 drivers/clk/clk-qoriq.c                            |   78 ++-
 14 files changed, 1107 insertions(+), 212 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/fsl,board.txt
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
 copy arch/arm64/boot/dts/freescale/{fsl-ls2085a-simu.dts => fsl-ls2080a-rdb.dts} (52%)
 rename arch/arm64/boot/dts/freescale/{fsl-ls2085a-simu.dts => fsl-ls2080a-simu.dts} (76%)
 create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
 delete mode 100644 arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi

-- 
1.7.9.5

[PATCH v2 01/10] arm64: Use generic Layerscape SoC family naming & rename LS2085A to LS2080A

[Bhupesh Sharma]

Freescale will be a churning out a host of ARMv8 based SoCs which
will be based on a similar overall SoC architecture. So, this patch
converts the existing infrastructure in the arm64/dts, arm64/Kconfig
and arm64/configs to use the generic convention ARCH_LAYERSCAPE
in place of the more specific FSL_LS2085A, to save code duplication
later-on.

Also Freescale is renaming LS2085A to LS2080A.

This patch addresses the above two points.

Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
---
 Documentation/devicetree/bindings/arm/fsl.txt      |    8 ++++----
 arch/arm64/Kconfig                                 |    6 +++---
 arch/arm64/boot/dts/freescale/Makefile             |    2 +-
 .../{fsl-ls2085a-simu.dts => fsl-ls2080a-simu.dts} |   10 +++++-----
 .../{fsl-ls2085a.dtsi => fsl-ls2080a.dtsi}         |    6 +++---
 arch/arm64/configs/defconfig                       |    2 +-
 6 files changed, 17 insertions(+), 17 deletions(-)
 rename arch/arm64/boot/dts/freescale/{fsl-ls2085a-simu.dts => fsl-ls2080a-simu.dts} (90%)
 rename arch/arm64/boot/dts/freescale/{fsl-ls2085a.dtsi => fsl-ls2080a.dtsi} (97%)

diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 2a3ba73..53f229a 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -128,10 +128,10 @@ Example:
 		reg = <0x0 0x1ee0000 0x0 0x10000>;
 	};
 
-Freescale LS2085A SoC Device Tree Bindings
-------------------------------------------
+Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
+----------------------------------------------------------------
 
-LS2085A ARMv8 based Simulator model
+LS2080A ARMv8 based Simulator model
 Required root node properties:
-    - compatible = "fsl,ls2085a-simu", "fsl,ls2085a";
+    - compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
 
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 318175f..65b335b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -179,10 +179,10 @@ config ARCH_EXYNOS7
 	help
 	  This enables support for Samsung Exynos7 SoC family
 
-config ARCH_FSL_LS2085A
-	bool "Freescale LS2085A SOC"
+config ARCH_LAYERSCAPE
+	bool "ARMv8 based Freescale Layerscape SoC family"
 	help
-	  This enables support for Freescale LS2085A SOC.
+	  This enables support for Freescale Layerscape SoC family.
 
 config ARCH_HISI
 	bool "Hisilicon SoC Family"
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 4f2de3e7..932001a 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_FSL_LS2085A) += fsl-ls2085a-simu.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
  
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2085a-simu.dts b/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts
similarity index 90%
rename from arch/arm64/boot/dts/freescale/fsl-ls2085a-simu.dts
rename to arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts
index 82e2a6f..cf45d38 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2085a-simu.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-simu.dts
@@ -1,7 +1,7 @@
 /*
- * Device Tree file for Freescale LS2085a software Simulator model
+ * Device Tree file for Freescale LS2080a software Simulator model
  *
- * Copyright (C) 2014, Freescale Semiconductor
+ * Copyright (C) 2014-15, Freescale Semiconductor
  *
  * Bhupesh Sharma <bhupesh.sharma@freescale.com>
  *
@@ -51,11 +51,11 @@
 
 /dts-v1/;
 
-/include/ "fsl-ls2085a.dtsi"
+/include/ "fsl-ls2080a.dtsi"
 
 / {
-	model = "Freescale Layerscape 2085a software Simulator model";
-	compatible = "fsl,ls2085a-simu", "fsl,ls2085a";
+	model = "Freescale Layerscape 2080a software Simulator model";
+	compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
 
 	ethernet at 2210000 {
 		compatible = "smsc,lan91c111";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
similarity index 97%
rename from arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
rename to arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index e281ceb..333d942 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -1,7 +1,7 @@
 /*
- * Device Tree Include file for Freescale Layerscape-2085A family SoC.
+ * Device Tree Include file for Freescale Layerscape-2080A family SoC.
  *
- * Copyright (C) 2014, Freescale Semiconductor
+ * Copyright (C) 2014-15, Freescale Semiconductor
  *
  * Bhupesh Sharma <bhupesh.sharma@freescale.com>
  *
@@ -50,7 +50,7 @@
  */
 
 / {
-	compatible = "fsl,ls2085a";
+	compatible = "fsl,ls2080a";
 	interrupt-parent = <&gic>;
 	#address-cells = <2>;
 	#size-cells = <2>;
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 4e17e7e..fa6aa9f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -32,7 +32,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
 CONFIG_ARCH_EXYNOS7=y
-CONFIG_ARCH_FSL_LS2085A=y
+CONFIG_ARCH_LAYERSCAPE=y
 CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_SEATTLE=y
-- 
1.7.9.5

[PATCH v2 02/10] Documentation: DT: Add entry for FSL LS2080A QDS and RDB boards

[Bhupesh Sharma]

This patch adds a devicetree binding documentation for Freescale's
LS2080A QDS and RDB boards.

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 53f229a..34c88b0 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -135,3 +135,11 @@ LS2080A ARMv8 based Simulator model
 Required root node properties:
     - compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
 
+LS2080A ARMv8 based QDS Board
+Required root node properties:
+    - compatible = "fsl,ls2080a-qds", "fsl,ls2080a";
+
+LS2080A ARMv8 based RDB Board
+Required root node properties:
+    - compatible = "fsl,ls2080a-rdb", "fsl,ls2080a";
+
-- 
1.7.9.5

[PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Bhupesh Sharma]

This patch adds bindings for QIXIS FPGA controller found on FSL boards.

Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board FPGA/CPLD
connected to the IFC controller. The bindings specified in this patch
cater to those on-board FPGA/CPLD controllers.

Signed-off-by: Jaiprakash Singh <b44839@freescale.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
---
 .../devicetree/bindings/arm/fsl,board.txt          |   31 ++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/fsl,board.txt

diff --git a/Documentation/devicetree/bindings/arm/fsl,board.txt b/Documentation/devicetree/bindings/arm/fsl,board.txt
new file mode 100644
index 0000000..756b730
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/fsl,board.txt
@@ -0,0 +1,31 @@
+Freescale Reference Board Bindings
+----------------------------------
+
+This document describes device tree bindings for various devices that
+exist on some Freescale reference boards.
+
+* Freescale on-board FPGA connected to IFC controller
+
+Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board FPGA/CPLD
+connected to the IFC controller.
+
+Required properties:
+- compatible: Should be a board-specific string followed by a string
+  indicating the type of FPGA.  Example:
+       "fsl,ls2080a-qds-qixis", "fsl,fpga-qixis"
+       "fsl,ls2080a-rdb-qixis", "fsl,fpga-qixis"
+- reg: The register set for the device
+
+Example:
+       &ifc {
+               status = "okay";
+               #address-cells = <2>;
+               #size-cells <1>;
+               ranges = <0x3 0x0 0x5 0x20000000 0x00010000>;
+
+               cpld at 3,0 {
+                       compatible = "fsl,ls2080a-qds-qixis", "fsl,fpga-qixis";
+                       reg = <0x3 0 0x10000>;
+               };
+       };
+
-- 
1.7.9.5

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Bhupesh Sharma]

Add the documentation for compatible string "fsl,ls2080a-pcie"
for Freescale's LS2080A platform.

Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
---
 .../devicetree/bindings/pci/layerscape-pci.txt     |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 6286f04..e72e68f 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
 and thus inherits all the common properties defined in designware-pcie.txt.
 
 Required properties:
-- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
+- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
+  "fsl,ls2080a-pcie".
 - reg: base addresses and lengths of the PCIe controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
-- 
1.7.9.5

[PATCH v2 05/10] doc/bindings: Update clk-qoriq bindings for FSL's chassis-3.0 SoCs

[Bhupesh Sharma]

This patch updates the 'clk-qoriq' device-tree bindings for
chassis-3.0 compliant SoCs from FSL, for e.g. LS2080A

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

diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
index 16a3ec4..f0a4b1c 100644
--- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -14,6 +14,7 @@ Chassis Version		Example Chips
 ---------------		-------------
 1.0			p4080, p5020, p5040
 2.0			t4240, b4860
+3.0			ls2080a
 
 1. Clock Block Binding
 
@@ -32,9 +33,11 @@ Required properties:
 	* "fsl,b4420-clockgen"
 	* "fsl,b4860-clockgen"
 	* "fsl,ls1021a-clockgen"
-	Chassis-version clock strings include:
+	* "fsl,ls2080a-clockgen"
+	Chassis clock strings include:
 	* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
 	* "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
+	* "fsl,qoriq-clockgen-3.0": for chassis 3.0 clocks
 - reg: Describes the address of the device's resources within the
 	address space defined by its parent bus, and resource zero
 	represents the clock register set
@@ -96,18 +99,23 @@ Required properties:
 - compatible : Should include one of the following:
 	* "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
 	* "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
+	* "fsl,qoriq-core-pll-3.0" for core PLL clocks (v3.0)
 	* "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
 	* "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
+	* "fsl,qoriq-core-mux-3.0" for core mux clocks (v3.0)
 	* "fsl,qoriq-sysclk-1.0": for input system clock (v1.0).
 		It takes parent's clock-frequency as its clock.
 	* "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
 		It takes parent's clock-frequency as its clock.
+	* "fsl,qoriq-sysclk-3.0": for input system clock (v3.0).
+		It takes parent's clock-frequency as its clock.
 	* "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
 	* "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
+	* "fsl,qoriq-platform-pll-3.0" for the platform PLL clock (v3.0)
 - #clock-cells: From common clock binding. The number of cells in a
-	clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
-	clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
-	For "fsl,qoriq-core-pll-[1,2].0" clocks, the single
+	clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2,3].0"
+	clocks, or <1> for "fsl,qoriq-core-pll-[1,2,3].0" clocks.
+	For "fsl,qoriq-core-pll-[1,2,3].0" clocks, the single
 	clock-specifier cell may take the following values:
 	* 0 - equal to the PLL frequency
 	* 1 - equal to the PLL frequency divided by 2
-- 
1.7.9.5

[PATCH v2 06/10] clk: qoriq: Add ls2080a support.

[Bhupesh Sharma]

From: Scott Wood <scottwood@freescale.com>

LS2080A is the first implementation of the chassis 3 clockgen, which
has a different register layout than previous chips.  It is also little
endian, unlike previous chips.

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
 drivers/clk/Kconfig     |    2 +-
 drivers/clk/clk-qoriq.c |   78 +++++++++++++++++++++++++++++++++++++++++------
 2 files changed, 70 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 42f7120..9f1970c 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -121,7 +121,7 @@ config COMMON_CLK_AXI_CLKGEN
 
 config CLK_QORIQ
 	bool "Clock driver for Freescale QorIQ platforms"
-	depends on (PPC_E500MC || ARM) && OF
+	depends on (PPC_E500MC || ARM || ARM64) && OF
 	---help---
 	  This adds the clock driver support for Freescale QorIQ platforms
 	  using common clock framework.
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index d9e4402..bae82ac 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -68,7 +68,10 @@ struct clockgen;
  * If not set, cmux freq must be >= platform pll/2
  */
 #define CG_CMUX_GE_PLAT		1
+
 #define CG_PLL_8BIT		2	/* PLLCnGSR[CFG] is 8 bits, not 6 */
+#define CG_VER3			4	/* version 3 cg: reg layout different */
+#define CG_LITTLE_ENDIAN	8
 
 struct clockgen_chipinfo {
 	const char *compat, *guts_compat;
@@ -94,6 +97,26 @@ struct clockgen {
 
 static struct clockgen clockgen;
 
+static void cg_out(struct clockgen *cg, u32 val, u32 __iomem *reg)
+{
+	if (cg->info.flags & CG_LITTLE_ENDIAN)
+		iowrite32(val, reg);
+	else
+		iowrite32be(val, reg);
+}
+
+static u32 cg_in(struct clockgen *cg, u32 __iomem *reg)
+{
+	u32 val;
+
+	if (cg->info.flags & CG_LITTLE_ENDIAN)
+		val = ioread32(reg);
+	else
+		val = ioread32be(reg);
+
+	return val;
+}
+
 static const struct clockgen_muxinfo p2041_cmux_grp1 = {
 	{
 		[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
@@ -429,6 +452,17 @@ static const struct clockgen_chipinfo chipinfo[] = {
 		.pll_mask = 0x03,
 	},
 	{
+		.compat = "fsl,ls2080a-clockgen",
+		.cmux_groups = {
+			&clockgen2_cmux_cga12, &clockgen2_cmux_cgb
+		},
+		.cmux_to_group = {
+			0, 0, 1, 1, -1
+		},
+		.pll_mask = 0x37,
+		.flags = CG_VER3 | CG_LITTLE_ENDIAN,
+	},
+	{
 		.compat = "fsl,p2041-clockgen",
 		.guts_compat = "fsl,qoriq-device-config-1.0",
 		.init_periph = p2041_init_periph,
@@ -575,7 +609,7 @@ static int mux_set_parent(struct clk_hw *hw, u8 idx)
 		return -EINVAL;
 
 	clksel = hwc->parent_to_clksel[idx];
-	iowrite32be((clksel << CLKSEL_SHIFT) & CLKSEL_MASK, hwc->reg);
+	cg_out(hwc->cg, (clksel << CLKSEL_SHIFT) & CLKSEL_MASK, hwc->reg);
 
 	return 0;
 }
@@ -586,7 +620,7 @@ static u8 mux_get_parent(struct clk_hw *hw)
 	u32 clksel;
 	s8 ret;
 
-	clksel = (ioread32be(hwc->reg) & CLKSEL_MASK) >> CLKSEL_SHIFT;
+	clksel = (cg_in(hwc->cg, hwc->reg) & CLKSEL_MASK) >> CLKSEL_SHIFT;
 
 	ret = hwc->clksel_to_parent[clksel];
 	if (ret < 0) {
@@ -694,6 +728,7 @@ static struct clk * __init create_one_cmux(struct clockgen *cg, int idx)
 	if (!hwc)
 		return NULL;
 
+	hwc->cg = cg;
 	hwc->reg = cg->regs + 0x20 * idx;
 	hwc->info = cg->info.cmux_groups[cg->info.cmux_to_group[idx]];
 
@@ -704,7 +739,7 @@ static struct clk * __init create_one_cmux(struct clockgen *cg, int idx)
 	 * default clksel) may be inappropriately excluded on certain
 	 * chips.
 	 */
-	clksel = (ioread32be(hwc->reg) & CLKSEL_MASK) >> CLKSEL_SHIFT;
+	clksel = (cg_in(cg, hwc->reg) & CLKSEL_MASK) >> CLKSEL_SHIFT;
 	div = get_pll_div(cg, hwc, clksel);
 	if (!div)
 		return NULL;
@@ -873,13 +908,36 @@ static void __init create_one_pll(struct clockgen *cg, int idx)
 	if (!(cg->info.pll_mask & (1 << idx)))
 		return;
 
-	if (idx == PLATFORM_PLL)
-		reg = cg->regs + 0xc00;
-	else
-		reg = cg->regs + 0x800 + 0x20 * (idx - 1);
+	if (cg->info.flags & CG_VER3) {
+		switch (idx) {
+		case PLATFORM_PLL:
+			reg = cg->regs + 0x60080;
+			break;
+		case CGA_PLL1:
+			reg = cg->regs + 0x80;
+			break;
+		case CGA_PLL2:
+			reg = cg->regs + 0xa0;
+			break;
+		case CGB_PLL1:
+			reg = cg->regs + 0x10080;
+			break;
+		case CGB_PLL2:
+			reg = cg->regs + 0x100a0;
+			break;
+		default:
+			WARN_ONCE(1, "index %d\n", idx);
+			return;
+		}
+	} else {
+		if (idx == PLATFORM_PLL)
+			reg = cg->regs + 0xc00;
+		else
+			reg = cg->regs + 0x800 + 0x20 * (idx - 1);
+	}
 
 	/* Get the multiple of PLL */
-	mult = ioread32be(reg);
+	mult = cg_in(cg, reg);
 
 	/* Check if this PLL is disabled */
 	if (mult & PLL_KILL) {
@@ -887,7 +945,8 @@ static void __init create_one_pll(struct clockgen *cg, int idx)
 		return;
 	}
 
-	if ((cg->info.flags & CG_PLL_8BIT) && idx != PLATFORM_PLL)
+	if ((cg->info.flags & CG_VER3) ||
+	    ((cg->info.flags & CG_PLL_8BIT) && idx != PLATFORM_PLL))
 		mult = (mult & GENMASK(8, 1)) >> 1;
 	else
 		mult = (mult & GENMASK(6, 1)) >> 1;
@@ -1168,6 +1227,7 @@ err:
 CLK_OF_DECLARE(qoriq_clockgen_1, "fsl,qoriq-clockgen-1.0", clockgen_init);
 CLK_OF_DECLARE(qoriq_clockgen_2, "fsl,qoriq-clockgen-2.0", clockgen_init);
 CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen", clockgen_init);
+CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen", clockgen_init);
 
 /* Legacy nodes */
 CLK_OF_DECLARE(qoriq_sysclk_1, "fsl,qoriq-sysclk-1.0", sysclk_init);
-- 
1.7.9.5

[PATCH v2 01/10] arm64: Use generic Layerscape SoC family naming & rename LS2085A to LS2080A

[Li Yang]

On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
<bhupesh.sharma@freescale.com> wrote:
> Freescale will be a churning out a host of ARMv8 based SoCs which
> will be based on a similar overall SoC architecture. So, this patch
> converts the existing infrastructure in the arm64/dts, arm64/Kconfig
> and arm64/configs to use the generic convention ARCH_LAYERSCAPE
> in place of the more specific FSL_LS2085A, to save code duplication
> later-on.
>
> Also Freescale is renaming LS2085A to LS2080A.
>
> This patch addresses the above two points.
>
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> ---
{snip}
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -1,7 +1,7 @@
>  /*
> - * Device Tree Include file for Freescale Layerscape-2085A family SoC.
> + * Device Tree Include file for Freescale Layerscape-2080A family SoC.
>   *
> - * Copyright (C) 2014, Freescale Semiconductor
> + * Copyright (C) 2014-15, Freescale Semiconductor

Normally we spell out the whole 2015.  The preferred copyright template is:

Copyright 2014-2015 Freescale Semiconductor, Inc.

- Leo

[PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Li Yang]

On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
<bhupesh.sharma@freescale.com> wrote:
> This patch adds bindings for QIXIS FPGA controller found on FSL boards.

A general comment: when you are updating the device tree bindings.
You should cc the devicetree at vger.kernel.org mailing list.

>
> Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board FPGA/CPLD
> connected to the IFC controller. The bindings specified in this patch
> cater to those on-board FPGA/CPLD controllers.

We already have the binding defined in
Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
should just move it to a more generic location.

Regards,
Leo

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Leo Li]

On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
<bhupesh.sharma@freescale.com> wrote:
> Add the documentation for compatible string "fsl,ls2080a-pcie"
> for Freescale's LS2080A platform.
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> ---
>  .../devicetree/bindings/pci/layerscape-pci.txt     |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index 6286f04..e72e68f 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
>  and thus inherits all the common properties defined in designware-pcie.txt.
>
>  Required properties:
> -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
> +- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
> +  "fsl,ls2080a-pcie".

Make it generic like "fsl,<chip>-pcie"

- Leo

[PATCH v2 06/10] clk: qoriq: Add ls2080a support.

[Li Yang]

On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
<bhupesh.sharma@freescale.com> wrote:
> From: Scott Wood <scottwood@freescale.com>
>
> LS2080A is the first implementation of the chassis 3 clockgen, which
> has a different register layout than previous chips.  It is also little
> endian, unlike previous chips.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---

You should probably mention here that the patch is depending on
another pending patch to apply.  And this patch should be going
through the same sub-system tree as the dependency patch.  Otherwise,
there is no way it can be applied.

Regards,
Leo

[PATCH v2 06/10] clk: qoriq: Add ls2080a support.

[Sharma Bhupesh]

> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
> Sent: Saturday, September 05, 2015 1:32 AM
> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
> <bhupesh.sharma@freescale.com> wrote:
> > From: Scott Wood <scottwood@freescale.com>
> >
> > LS2080A is the first implementation of the chassis 3 clockgen, which
> > has a different register layout than previous chips.  It is also
> > little endian, unlike previous chips.
> >
> > Signed-off-by: Scott Wood <scottwood@freescale.com>
> > ---
> 
> You should probably mention here that the patch is depending on another
> pending patch to apply.  And this patch should be going through the same
> sub-system tree as the dependency patch.  Otherwise, there is no way it
> can be applied.
> 

Cover-letter already captures this: 
http://www.spinics.net/lists/arm-kernel/msg442910.html

See the section 'Rebasing details'. linux-clk is already copied.

Regards,
Bhupesh

[PATCH v2 01/10] arm64: Use generic Layerscape SoC family naming & rename LS2085A to LS2080A

[Sharma Bhupesh]

> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
> Sent: Friday, September 04, 2015 10:01 PM
> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
> <bhupesh.sharma@freescale.com> wrote:
> > Freescale will be a churning out a host of ARMv8 based SoCs which will
> > be based on a similar overall SoC architecture. So, this patch
> > converts the existing infrastructure in the arm64/dts, arm64/Kconfig
> > and arm64/configs to use the generic convention ARCH_LAYERSCAPE in
> > place of the more specific FSL_LS2085A, to save code duplication
> > later-on.
> >
> > Also Freescale is renaming LS2085A to LS2080A.
> >
> > This patch addresses the above two points.
> >
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > ---
> {snip}
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> > @@ -1,7 +1,7 @@
> >  /*
> > - * Device Tree Include file for Freescale Layerscape-2085A family SoC.
> > + * Device Tree Include file for Freescale Layerscape-2080A family SoC.
> >   *
> > - * Copyright (C) 2014, Freescale Semiconductor
> > + * Copyright (C) 2014-15, Freescale Semiconductor
> 
> Normally we spell out the whole 2015.  The preferred copyright template
> is:
> 
> Copyright 2014-2015 Freescale Semiconductor, Inc.
> 

Ok.

Regards,
Bhupesh

[PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Sharma Bhupesh]

> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
> Sent: Friday, September 04, 2015 10:27 PM
> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
> <bhupesh.sharma@freescale.com> wrote:
> > This patch adds bindings for QIXIS FPGA controller found on FSL boards.
> 
> A general comment: when you are updating the device tree bindings.
> You should cc the devicetree at vger.kernel.org mailing list.
> 
> >
> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board
> > FPGA/CPLD connected to the IFC controller. The bindings specified in
> > this patch cater to those on-board FPGA/CPLD controllers.
> 
> We already have the binding defined in
> Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
> should just move it to a more generic location.

Consolidation of powerpc and ARM bindings is something that needs to be
targeted by a separate patch-series, perhaps in future.

There are a number of duplications that can be looked into, but I don't
think this patchset should depend on that.

Regards,
Bhupesh

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Sharma Bhupesh]

> From: Leo Li [mailto:pku.leo at gmail.com]
> Sent: Friday, September 04, 2015 11:27 PM
> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
> <bhupesh.sharma@freescale.com> wrote:
> > Add the documentation for compatible string "fsl,ls2080a-pcie"
> > for Freescale's LS2080A platform.
> >
> > Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > ---
> >  .../devicetree/bindings/pci/layerscape-pci.txt     |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > index 6286f04..e72e68f 100644
> > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> > Designware PCIe IP  and thus inherits all the common properties defined
> in designware-pcie.txt.
> >
> >  Required properties:
> > -- compatible: should contain the platform identifier such as
> "fsl,ls1021a-pcie"
> > +- compatible: should contain the platform identifier such as
> > +"fsl,ls1021a-pcie",
> > +  "fsl,ls2080a-pcie".
> 
> Make it generic like "fsl,<chip>-pcie"

Minghuan, if you don't have an objection, I would like to address Leo's suggestion
in v3 of this series as I think it is a valid one.

Please share your views. 

Regards,
Bhupesh

[PATCH v2 06/10] clk: qoriq: Add ls2080a support.

[Li Yang]

On Fri, Sep 4, 2015 at 3:09 PM, Sharma Bhupesh
<bhupesh.sharma@freescale.com> wrote:
>> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
>> Sent: Saturday, September 05, 2015 1:32 AM
>> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
>> <bhupesh.sharma@freescale.com> wrote:
>> > From: Scott Wood <scottwood@freescale.com>
>> >
>> > LS2080A is the first implementation of the chassis 3 clockgen, which
>> > has a different register layout than previous chips.  It is also
>> > little endian, unlike previous chips.
>> >
>> > Signed-off-by: Scott Wood <scottwood@freescale.com>
>> > ---
>>
>> You should probably mention here that the patch is depending on another
>> pending patch to apply.  And this patch should be going through the same
>> sub-system tree as the dependency patch.  Otherwise, there is no way it
>> can be applied.
>>
>
> Cover-letter already captures this:
> http://www.spinics.net/lists/arm-kernel/msg442910.html
>
> See the section 'Rebasing details'. linux-clk is already copied.

But not all the patches are depending on the clk patches.  You should
probably break up the series to patches that can be applied cleanly
and patches that are depending on the clock patches and should go
through the clk tree.

Regards,
Leo

[PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Li Yang]

On Fri, Sep 4, 2015 at 3:16 PM, Sharma Bhupesh
<bhupesh.sharma@freescale.com> wrote:
>> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
>> Sent: Friday, September 04, 2015 10:27 PM
>> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
>> <bhupesh.sharma@freescale.com> wrote:
>> > This patch adds bindings for QIXIS FPGA controller found on FSL boards.
>>
>> A general comment: when you are updating the device tree bindings.
>> You should cc the devicetree at vger.kernel.org mailing list.
>>
>> >
>> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board
>> > FPGA/CPLD connected to the IFC controller. The bindings specified in
>> > this patch cater to those on-board FPGA/CPLD controllers.
>>
>> We already have the binding defined in
>> Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
>> should just move it to a more generic location.
>
> Consolidation of powerpc and ARM bindings is something that needs to be
> targeted by a separate patch-series, perhaps in future.
>
> There are a number of duplications that can be looked into, but I don't
> think this patchset should depend on that.

There might be some duplication, but we shouldn't be adding more.  :)
I would rather you directly updating that file than creating a new
file even though the original one was in a wrong directory.

Regards,
Leo

[PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Sharma Bhupesh]

> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
> Sent: Saturday, September 05, 2015 2:43 AM
> On Fri, Sep 4, 2015 at 3:16 PM, Sharma Bhupesh
> <bhupesh.sharma@freescale.com> wrote:
> >> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
> >> Sent: Friday, September 04, 2015 10:27 PM On Fri, Sep 4, 2015 at 1:57
> >> AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> wrote:
> >> > This patch adds bindings for QIXIS FPGA controller found on FSL
> boards.
> >>
> >> A general comment: when you are updating the device tree bindings.
> >> You should cc the devicetree at vger.kernel.org mailing list.
> >>
> >> >
> >> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board
> >> > FPGA/CPLD connected to the IFC controller. The bindings specified
> >> > in this patch cater to those on-board FPGA/CPLD controllers.
> >>
> >> We already have the binding defined in
> >> Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
> >> should just move it to a more generic location.
> >
> > Consolidation of powerpc and ARM bindings is something that needs to
> > be targeted by a separate patch-series, perhaps in future.
> >
> > There are a number of duplications that can be looked into, but I
> > don't think this patchset should depend on that.
> 
> There might be some duplication, but we shouldn't be adding more.  :) I
> would rather you directly updating that file than creating a new file
> even though the original one was in a wrong directory.
> 

IMO a PowerPC binding update makes no sense in a ARM machine patchset sent
on a arm specific mailing list.

I would like to wait to hear what maintainers have to say on the same.

Regards,
Bhupesh

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Lian M.H.]

Hi Bhupesh

I agree with Leo whose suggestion is a better.

Thanks,
Minghuan 

> -----Original Message-----
> From: Sharma Bhupesh-B45370
> Sent: Saturday, September 05, 2015 4:20 AM
> To: Leo Li <pku.leo@gmail.com>; Lian Minghuan-B31939
> <Minghuan.Lian@freescale.com>
> Cc: Arnd Bergmann <arnd@arndb.de>; Mark Rutland
> <mark.rutland@arm.com>; linux-arm-kernel at lists.infradead.org;
> marc.zyngier at arm.com; linux-clk at vger.kernel.org;
> Catalin.Marinas at arm.com; will.deacon at arm.com; olof at lixom.net; Bhupesh
> SHARMA <bhupesh.linux@gmail.com>; devicetree at vger.kernel.org
> Subject: RE: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding
> documentation for LS2080A
> 
> > From: Leo Li [mailto:pku.leo at gmail.com]
> > Sent: Friday, September 04, 2015 11:27 PM On Fri, Sep 4, 2015 at 1:57
> > AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> wrote:
> > > Add the documentation for compatible string "fsl,ls2080a-pcie"
> > > for Freescale's LS2080A platform.
> > >
> > > Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > > ---
> > >  .../devicetree/bindings/pci/layerscape-pci.txt     |    3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > index 6286f04..e72e68f 100644
> > > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> > > Designware PCIe IP  and thus inherits all the common properties
> > > defined
> > in designware-pcie.txt.
> > >
> > >  Required properties:
> > > -- compatible: should contain the platform identifier such as
> > "fsl,ls1021a-pcie"
> > > +- compatible: should contain the platform identifier such as
> > > +"fsl,ls1021a-pcie",
> > > +  "fsl,ls2080a-pcie".
> >
> > Make it generic like "fsl,<chip>-pcie"
> 
> Minghuan, if you don't have an objection, I would like to address Leo's
> suggestion in v3 of this series as I think it is a valid one.
> 
> Please share your views.
> 
> Regards,
> Bhupesh

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Sharma Bhupesh]

> From: Lian Minghuan-B31939
> Sent: Sunday, September 06, 2015 7:56 AM
> Hi Bhupesh
> 
> I agree with Leo whose suggestion is a better.

Ok, thanks.

I will make this change in v3 patchset then.

Regards,
Bhupesh

> > From: Sharma Bhupesh-B45370
> > Sent: Saturday, September 05, 2015 4:20 AM
> > > From: Leo Li [mailto:pku.leo at gmail.com]
> > > Sent: Friday, September 04, 2015 11:27 PM On Fri, Sep 4, 2015 at
> > > 1:57 AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> wrote:
> > > > Add the documentation for compatible string "fsl,ls2080a-pcie"
> > > > for Freescale's LS2080A platform.
> > > >
> > > > Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> > > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> > > > ---
> > > >  .../devicetree/bindings/pci/layerscape-pci.txt     |    3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > index 6286f04..e72e68f 100644
> > > > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > > > @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> > > > Designware PCIe IP  and thus inherits all the common properties
> > > > defined
> > > in designware-pcie.txt.
> > > >
> > > >  Required properties:
> > > > -- compatible: should contain the platform identifier such as
> > > "fsl,ls1021a-pcie"
> > > > +- compatible: should contain the platform identifier such as
> > > > +"fsl,ls1021a-pcie",
> > > > +  "fsl,ls2080a-pcie".
> > >
> > > Make it generic like "fsl,<chip>-pcie"
> >
> > Minghuan, if you don't have an objection, I would like to address
> > Leo's suggestion in v3 of this series as I think it is a valid one.
> >
> > Please share your views.
> >
> > Regards,
> > Bhupesh

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Arnd Bergmann]

On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
>  and thus inherits all the common properties defined in designware-pcie.txt.
>  
>  Required properties:
> -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
> +- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
> +  "fsl,ls2080a-pcie".
>  - reg: base addresses and lengths of the PCIe controller
>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>    entry for each entry in the interrupt-names property.
> 

Are the two PCIe hosts mutually compatible? If they are, you should mandate
one of the strings as the base model for identification, with the additional
model being optional for identification of the specific SoC.

It would also be good to add a string with the specific version number of the
designware PCIe block that is being used there.

	Arnd

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Li Yang]

On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
>> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
>>  and thus inherits all the common properties defined in designware-pcie.txt.
>>
>>  Required properties:
>> -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
>> +- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
>> +  "fsl,ls2080a-pcie".
>>  - reg: base addresses and lengths of the PCIe controller
>>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>>    entry for each entry in the interrupt-names property.
>>
>
> Are the two PCIe hosts mutually compatible? If they are, you should mandate
> one of the strings as the base model for identification, with the additional
> model being optional for identification of the specific SoC.

It seems that controllers on these chips are not exactly the same.
They will get different driver data by matching the compatible
strings.  Probably we could define a more generic compatible string,
such as "fsl,layerscape-pcie" or "fsl,ls-pcie".

>
> It would also be good to add a string with the specific version number of the
> designware PCIe block that is being used there.

The binding has mentioned to reference the designware-pcie.txt.  But
it might be more clear to mention the designware compatible string
"snps,dw-pcie" again in the compatible part.  Currently there is no
version number defined in the designware-pcie binding.  It might be
hard to get this information for some SoCs.

Regards,
Leo

[PATCH v2 01/10] arm64: Use generic Layerscape SoC family naming & rename LS2085A to LS2080A

[Stuart Yoder]

On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
<bhupesh.sharma@freescale.com> wrote:
> Freescale will be a churning out a host of ARMv8 based SoCs which
> will be based on a similar overall SoC architecture. So, this patch
> converts the existing infrastructure in the arm64/dts, arm64/Kconfig
> and arm64/configs to use the generic convention ARCH_LAYERSCAPE
> in place of the more specific FSL_LS2085A, to save code duplication
> later-on.
>
> Also Freescale is renaming LS2085A to LS2080A.
>
> This patch addresses the above two points.

Suggest splitting this into 2 patches because these 2 changes are really
orthogonal-- one patch for the ARCH config name change, one for the rename
ls2085a to ls2080a rename.

Not sure why you're describing it as "churning out a host of ARMv8 based SoCs".
Just get to the point--  Layerscape is an SoC family so we're changing from the
SoC specific ARCH kconfig option to a more general SoC family option.

Thanks,
Stuart

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Sharma Bhupesh]

> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
> Sent: Wednesday, September 09, 2015 1:36 AM
> On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
> >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> >> Designware PCIe IP  and thus inherits all the common properties
> defined in designware-pcie.txt.
> >>
> >>  Required properties:
> >> -- compatible: should contain the platform identifier such as
> "fsl,ls1021a-pcie"
> >> +- compatible: should contain the platform identifier such as
> >> +"fsl,ls1021a-pcie",
> >> +  "fsl,ls2080a-pcie".
> >>  - reg: base addresses and lengths of the PCIe controller
> >>  - interrupts: A list of interrupt outputs of the controller. Must
> contain an
> >>    entry for each entry in the interrupt-names property.
> >>
> >
> > Are the two PCIe hosts mutually compatible? If they are, you should
> > mandate one of the strings as the base model for identification, with
> > the additional model being optional for identification of the specific
> SoC.
> 
> It seems that controllers on these chips are not exactly the same.
> They will get different driver data by matching the compatible strings.
> Probably we could define a more generic compatible string, such as
> "fsl,layerscape-pcie" or "fsl,ls-pcie".

Yes, Minghaun captured the differences in the two versions in the v1 review
discussion for the DTS here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-April/338343.html

Regards,
Bhupesh

[PATCH v2 01/10] arm64: Use generic Layerscape SoC family naming & rename LS2085A to LS2080A

[Sharma Bhupesh]

> From: Stuart Yoder [mailto:b08248 at gmail.com]
> Sent: Wednesday, September 09, 2015 1:55 AM
> On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
> <bhupesh.sharma@freescale.com> wrote:
> > Freescale will be a churning out a host of ARMv8 based SoCs which will
> > be based on a similar overall SoC architecture. So, this patch
> > converts the existing infrastructure in the arm64/dts, arm64/Kconfig
> > and arm64/configs to use the generic convention ARCH_LAYERSCAPE in
> > place of the more specific FSL_LS2085A, to save code duplication
> > later-on.
> >
> > Also Freescale is renaming LS2085A to LS2080A.
> >
> > This patch addresses the above two points.
> 
> Suggest splitting this into 2 patches because these 2 changes are really
> orthogonal-- one patch for the ARCH config name change, one for the
> rename ls2085a to ls2080a rename.

I was seeing the compilation breaking up at patch level if I did so.
Will try to see if this can be achieved without breaking up the compilation
for individual patches in v3.
 
> Not sure why you're describing it as "churning out a host of ARMv8 based
> SoCs".
> Just get to the point--  Layerscape is an SoC family so we're changing
> from the SoC specific ARCH kconfig option to a more general SoC family
> option.

The prologue is to describe that other ARMv8 SoCs with similar architecture
will be put-out, which will be part of the overall Layerscape family. 

Regards,
Bhupesh

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Arnd Bergmann]

On Tuesday 08 September 2015 15:06:16 Li Yang wrote:
> On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
> >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
> >>  and thus inherits all the common properties defined in designware-pcie.txt.
> >>
> >>  Required properties:
> >> -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
> >> +- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
> >> +  "fsl,ls2080a-pcie".
> >>  - reg: base addresses and lengths of the PCIe controller
> >>  - interrupts: A list of interrupt outputs of the controller. Must contain an
> >>    entry for each entry in the interrupt-names property.
> >>
> >
> > Are the two PCIe hosts mutually compatible? If they are, you should mandate
> > one of the strings as the base model for identification, with the additional
> > model being optional for identification of the specific SoC.
> 
> It seems that controllers on these chips are not exactly the same.
> They will get different driver data by matching the compatible
> strings.  Probably we could define a more generic compatible string,
> such as "fsl,layerscape-pcie" or "fsl,ls-pcie".
> 
> >
> > It would also be good to add a string with the specific version number of the
> > designware PCIe block that is being used there.
> 
> The binding has mentioned to reference the designware-pcie.txt.  But
> it might be more clear to mention the designware compatible string
> "snps,dw-pcie" again in the compatible part.  Currently there is no
> version number defined in the designware-pcie binding.  It might be
> hard to get this information for some SoCs.

For most of them, the information is available and then it should be
added. Obviously if you can't find it out, it's hard to guess and
you have to leave it out for that particular chip.

A lot of devices also have some internal version register that you
can read out.

	Arnd

[PATCH v2 06/10] clk: qoriq: Add ls2080a support.

[Scott Wood]

On Fri, 2015-09-04 at 12:27 +0530, Bhupesh Sharma wrote:
> From: Scott Wood <scottwood@freescale.com>
> 
> LS2080A is the first implementation of the chassis 3 clockgen, which
> has a different register layout than previous chips.  It is also little
> endian, unlike previous chips.
> 
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---

You should add your own signoff when passing on someone else's patch.

FWIW, I'm likely to squash this with my previous clk-qoriq patches when I 
resubmit.

-Scott

[PATCH v2 06/10] clk: qoriq: Add ls2080a support.

[Scott Wood]

On Fri, 2015-09-04 at 16:06 -0500, Li Yang wrote:
> On Fri, Sep 4, 2015 at 3:09 PM, Sharma Bhupesh
> <bhupesh.sharma@freescale.com> wrote:
> > > From:  pku.leo at gmail.com[mailto:pku.leo at gmail.com]
> > > Sent: Saturday, September 05, 2015 1:32 AM
> > > On Fri, Sep 4, 2015 at 1:57 AM, Bhupesh Sharma
> > > <bhupesh.sharma@freescale.com> wrote:
> > > > From: Scott Wood <scottwood@freescale.com>
> > > > 
> > > > LS2080A is the first implementation of the chassis 3 clockgen, which
> > > > has a different register layout than previous chips.  It is also
> > > > little endian, unlike previous chips.
> > > > 
> > > > Signed-off-by: Scott Wood <scottwood@freescale.com>
> > > > ---
> > > 
> > > You should probably mention here that the patch is depending on another
> > > pending patch to apply.  And this patch should be going through the same
> > > sub-system tree as the dependency patch.  Otherwise, there is no way it
> > > can be applied.
> > > 
> > 
> > Cover-letter already captures this:
> > http://www.spinics.net/lists/arm-kernel/msg442910.html
> > 
> > See the section 'Rebasing details'. linux-clk is already copied.
> 
> But not all the patches are depending on the clk patches.  You should
> probably break up the series to patches that can be applied cleanly
> and patches that are depending on the clock patches and should go
> through the clk tree.

The clock patches have already been acked, so they don't necessarily need to 
go via the clock tree.  However, there are both ARM and PPC patches that 
depend on them, so maybe we should create a topic branch?

-Scott

[PATCH v2 05/10] doc/bindings: Update clk-qoriq bindings for FSL's chassis-3.0 SoCs

[Scott Wood]

On Fri, 2015-09-04 at 12:27 +0530, Bhupesh Sharma wrote:
> This patch updates the 'clk-qoriq' device-tree bindings for
> chassis-3.0 compliant SoCs from FSL, for e.g. LS2080A
> 
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
> ---
>  .../devicetree/bindings/clock/qoriq-clock.txt      |   16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)

Why didn't you CC me on this?

> diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt 
> b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> index 16a3ec4..f0a4b1c 100644
> --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
> @@ -14,6 +14,7 @@ Chassis Version             Example Chips
>  ---------------              -------------
>  1.0                  p4080, p5020, p5040
>  2.0                  t4240, b4860
> +3.0                  ls2080a
>  
>  1. Clock Block Binding
>  
> @@ -32,9 +33,11 @@ Required properties:
>       * "fsl,b4420-clockgen"
>       * "fsl,b4860-clockgen"
>       * "fsl,ls1021a-clockgen"
> -     Chassis-version clock strings include:
> +     * "fsl,ls2080a-clockgen"

We don't need to update this for every new chip.  It says "such as".

> +     Chassis clock strings include:
>       * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
>       * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
> +     * "fsl,qoriq-clockgen-3.0": for chassis 3.0 clocks

With the new binding I don't see value in the generic version compatible.

>  - reg: Describes the address of the device's resources within the
>       address space defined by its parent bus, and resource zero
>       represents the clock register set
> @@ -96,18 +99,23 @@ Required properties:
>  - compatible : Should include one of the following:
>       * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
>       * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
> +     * "fsl,qoriq-core-pll-3.0" for core PLL clocks (v3.0)
>       * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
>       * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
> +     * "fsl,qoriq-core-mux-3.0" for core mux clocks (v3.0)
>       * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0).
>               It takes parent's clock-frequency as its clock.
>       * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
>               It takes parent's clock-frequency as its clock.
> +     * "fsl,qoriq-sysclk-3.0": for input system clock (v3.0).
> +             It takes parent's clock-frequency as its clock.
>       * "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
>       * "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
> +     * "fsl,qoriq-platform-pll-3.0" for the platform PLL clock (v3.0)

No new legacy compatibles please.

-Scott

[PATCH v2 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Li Yang]

On Sat, Sep 5, 2015 at 3:11 AM, Sharma Bhupesh
<bhupesh.sharma@freescale.com> wrote:
>> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
>> Sent: Saturday, September 05, 2015 2:43 AM
>> On Fri, Sep 4, 2015 at 3:16 PM, Sharma Bhupesh
>> <bhupesh.sharma@freescale.com> wrote:
>> >> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com]
>> >> Sent: Friday, September 04, 2015 10:27 PM On Fri, Sep 4, 2015 at 1:57
>> >> AM, Bhupesh Sharma <bhupesh.sharma@freescale.com> wrote:
>> >> > This patch adds bindings for QIXIS FPGA controller found on FSL
>> boards.
>> >>
>> >> A general comment: when you are updating the device tree bindings.
>> >> You should cc the devicetree at vger.kernel.org mailing list.
>> >>
>> >> >
>> >> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board
>> >> > FPGA/CPLD connected to the IFC controller. The bindings specified
>> >> > in this patch cater to those on-board FPGA/CPLD controllers.
>> >>
>> >> We already have the binding defined in
>> >> Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
>> >> should just move it to a more generic location.
>> >
>> > Consolidation of powerpc and ARM bindings is something that needs to
>> > be targeted by a separate patch-series, perhaps in future.
>> >
>> > There are a number of duplications that can be looked into, but I
>> > don't think this patchset should depend on that.
>>
>> There might be some duplication, but we shouldn't be adding more.  :) I
>> would rather you directly updating that file than creating a new file
>> even though the original one was in a wrong directory.
>>
>
> IMO a PowerPC binding update makes no sense in a ARM machine patchset sent
> on a arm specific mailing list.

So the best approach is to merge the change with the original binding
and put it into a common place.  Although there were a lot of non-arch
specific bindings placed into the arch folder, we should stop adding
more now.

Regards,
Leo

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Li Yang]

On Wed, Sep 9, 2015 at 4:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 08 September 2015 15:06:16 Li Yang wrote:
>> On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
>> >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
>> >>  and thus inherits all the common properties defined in designware-pcie.txt.
>> >>
>> >>  Required properties:
>> >> -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie"
>> >> +- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie",
>> >> +  "fsl,ls2080a-pcie".
>> >>  - reg: base addresses and lengths of the PCIe controller
>> >>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>> >>    entry for each entry in the interrupt-names property.
>> >>
>> >
>> > Are the two PCIe hosts mutually compatible? If they are, you should mandate
>> > one of the strings as the base model for identification, with the additional
>> > model being optional for identification of the specific SoC.
>>
>> It seems that controllers on these chips are not exactly the same.
>> They will get different driver data by matching the compatible
>> strings.  Probably we could define a more generic compatible string,
>> such as "fsl,layerscape-pcie" or "fsl,ls-pcie".
>>
>> >
>> > It would also be good to add a string with the specific version number of the
>> > designware PCIe block that is being used there.
>>
>> The binding has mentioned to reference the designware-pcie.txt.  But
>> it might be more clear to mention the designware compatible string
>> "snps,dw-pcie" again in the compatible part.  Currently there is no
>> version number defined in the designware-pcie binding.  It might be
>> hard to get this information for some SoCs.
>
> For most of them, the information is available and then it should be
> added. Obviously if you can't find it out, it's hard to guess and
> you have to leave it out for that particular chip.

Actually I don't know any approach to get the version number of the
designware block used.  Maybe they are actually using the same version
of the IP block, and the differences in the driver are actually caused
by the differences in SoC integration.

>
> A lot of devices also have some internal version register that you
> can read out.

There doesn't seem to be this kind of register for the PCIe block.

Minghuan,

Please correct me if you know more. :)

Regards,
Leo

[PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Lian M.H.]

Hi Leo and Bergmann,

Please see my comments inline.

> -----Original Message-----
> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com] On Behalf Of Li Yang
> Sent: Thursday, September 10, 2015 7:50 AM
> To: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; Mark
> Rutland <mark.rutland@arm.com>; Sharma Bhupesh-B45370
> <bhupesh.sharma@freescale.com>; Catalin.Marinas at arm.com;
> olof at lixom.net; will.deacon at arm.com; Lian Minghuan-B31939
> <Minghuan.Lian@freescale.com>; marc.zyngier at arm.com; Bhupesh SHARMA
> <bhupesh.linux@gmail.com>; linux-clk at vger.kernel.org
> Subject: Re: [PATCH v2 04/10] doc/bindings: Update PCIe devicetree binding
> documentation for LS2080A
> 
> On Wed, Sep 9, 2015 at 4:07 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 08 September 2015 15:06:16 Li Yang wrote:
> >> On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
> >> >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis
> >> >> Designware PCIe IP  and thus inherits all the common properties
> defined in designware-pcie.txt.
> >> >>
> >> >>  Required properties:
> >> >> -- compatible: should contain the platform identifier such as
> "fsl,ls1021a-pcie"
> >> >> +- compatible: should contain the platform identifier such as
> >> >> +"fsl,ls1021a-pcie",
> >> >> +  "fsl,ls2080a-pcie".
> >> >>  - reg: base addresses and lengths of the PCIe controller
> >> >>  - interrupts: A list of interrupt outputs of the controller. Must contain
> an
> >> >>    entry for each entry in the interrupt-names property.
> >> >>
> >> >
> >> > Are the two PCIe hosts mutually compatible? If they are, you should
> >> > mandate one of the strings as the base model for identification,
> >> > with the additional model being optional for identification of the specific
> SoC.
> >>
> >> It seems that controllers on these chips are not exactly the same.
> >> They will get different driver data by matching the compatible
> >> strings.  Probably we could define a more generic compatible string,
> >> such as "fsl,layerscape-pcie" or "fsl,ls-pcie".
> >>
> >> >
> >> > It would also be good to add a string with the specific version
> >> > number of the designware PCIe block that is being used there.
> >>
> >> The binding has mentioned to reference the designware-pcie.txt.  But
> >> it might be more clear to mention the designware compatible string
> >> "snps,dw-pcie" again in the compatible part.  Currently there is no
> >> version number defined in the designware-pcie binding.  It might be
> >> hard to get this information for some SoCs.
> >
> > For most of them, the information is available and then it should be
> > added. Obviously if you can't find it out, it's hard to guess and you
> > have to leave it out for that particular chip.
> 
> Actually I don't know any approach to get the version number of the
> designware block used.  Maybe they are actually using the same version of
> the IP block, and the differences in the driver are actually caused by the
> differences in SoC integration.
> 
> >
> > A lot of devices also have some internal version register that you can
> > read out.
> 
> There doesn't seem to be this kind of register for the PCIe block.
> 
[Lian Minghuan-B31939]  Yes. There is no register to show PCIe block version according to reference manual.
I agree that differences in the driver are caused by the differences in SoC integration.

> Minghuan,
> 
> Please correct me if you know more. :)
> 
> Regards,
> Leo