add initial imx6q support

arch/arm/boot/dts/imx6q.dtsi new file +4 -0

+
+       aips-bus at 02000000 { /* AIPS1 */
+               compatible = "fsl,aips-bus", "simple-bus";
+               #address-cells = <1>;

Quoted 9 lines · On Tuesday 06 September 2011 17:58:35 Shawn Guo wrote:

arch/arm/boot/dts/imx6q.dtsi new file +9 -0

+
+       aips-bus at 02000000 { /* AIPS1 */
+               compatible = "fsl,aips-bus", "simple-bus";
+               #address-cells = <1>;
+               #size-cells = <1>;
+               reg = <0x02000000 0x100000>;
+               ranges;
+
+               spba-bus at 02000000 {

arch/arm/boot/dts/imx6q.dtsi line 120

Quoted 5 lines

arch/arm/boot/dts/imx6q.dtsi new file +5 -0

+                       compatible = "fsl,spba-bus", "simple-bus";
+                       #address-cells = <1>;
+                       #size-cells = <1>;
+                       reg = <0x02000000 0x40000>;
+                       ranges;

Wouldn't it be better to have the ranges property translate bus-local addresses to global addresses, rather than having an empty ranges property?

arch/arm/plat-mxc/include/mach/mx6q.h line 5

Quoted 8 lines · On Tuesday 06 September 2011 17:58:36 Shawn Guo wrote:

arch/arm/plat-mxc/include/mach/mx6q.h new file +5 -0

@@ -0,0 +1,29 @@
+#ifndef __MACH_MX6Q_H__
+#define __MACH_MX6Q_H__
+
+/* static mappings */
+#define IMX6Q_VA(x)            (0xf4000000 + (x))

This should return a 'void __iomem *' pointer, not an integer.

Quoted 6 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +6 -0

+#define MX6Q_SCU_BASE_ADDR     0x00a00000
+#define MX6Q_CCM_BASE_ADDR     0x020c4000
+#define MX6Q_ANATOP_BASE_ADDR  0x020c8000
+#define MX6Q_UART4_BASE_ADDR   0x021f0000
+
+#define MX6Q_SCU_BASE_VADDR    IMX6Q_VA(MX6Q_SCU_BASE_ADDR)

arch/arm/plat-mxc/include/mach/mx6q.h line 27

Quoted 3 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +3 -0

+#define MX6Q_CCM_BASE_VADDR    IMX6Q_VA(MX6Q_CCM_BASE_ADDR)
+#define MX6Q_ANATOP_BASE_VADDR IMX6Q_VA(MX6Q_ANATOP_BASE_ADDR)
+#define MX6Q_UART4_BASE_VADDR  IMX6Q_VA(MX6Q_UART4_BASE_ADDR)

The list is reasonably short, but I think you can still try harder to remove some of the remaining elements. I can understand the need for UART4 (for ll_debug), but I don't really understand what the others are and why you cannot get the values from the device tree and ioremap them.

Maybe you can add a few comments to explain these if they are indeed necessary.

It adds the core definitions and low-level debug uart support for imx6q.

Signed-off-by Shawn Guo <[email protected]>

---
 arch/arm/Kconfig                             |    2 +-
 arch/arm/Kconfig.debug                       |    7 +++++
 arch/arm/Makefile                            |    1 +
 arch/arm/mach-imx/Kconfig                    |    4 +++
 arch/arm/mach-imx/Makefile                   |    2 +
 arch/arm/mach-imx/Makefile.boot              |    4 +++
 arch/arm/mach-imx/lluart.c                   |   33 ++++++++++++++++++++++++++
 arch/arm/plat-mxc/Kconfig                    |    5 ++++
 arch/arm/plat-mxc/include/mach/debug-macro.S |    5 ++++
 arch/arm/plat-mxc/include/mach/entry-macro.S |   15 +++++++++++-
 arch/arm/plat-mxc/include/mach/hardware.h    |    1 +
 arch/arm/plat-mxc/include/mach/irqs.h        |    9 ++++--
 arch/arm/plat-mxc/include/mach/memory.h      |    3 ++
 arch/arm/plat-mxc/include/mach/mx6q.h        |   29 ++++++++++++++++++++++
 14 files changed, 115 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-imx/lluart.c
 create mode 100644 arch/arm/plat-mxc/include/mach/mx6q.h

arch/arm/Kconfig +1 -1

index 4ea9974..37c20a4 100644
@@ -1348,7 +1348,7 @@ config SMP
 	depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \
 		 MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
 		 ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \
-		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE
+		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || SOC_IMX6Q
 	select USE_GENERIC_SMP_HELPERS
 	select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
 	help

arch/arm/Kconfig.debug +7 -0

index 965d59a..68fc155 100644
@@ -155,6 +155,13 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on i.MX50 or i.MX53.
 
+	config DEBUG_IMX6Q_UART
+		bool "i.MX6Q Debug UART"
+		depends on SOC_IMX6Q
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on i.MX6Q.
+
 	config DEBUG_S3C_UART0
 		depends on PLAT_SAMSUNG
 		bool "Use S3C UART 0 for low-level debug"

arch/arm/Makefile +1 -0

index 70c424e..3a0bbe4 100644
@@ -159,6 +159,7 @@ machine-$(CONFIG_ARCH_MX2)		:= imx
 machine-$(CONFIG_ARCH_MX25)		:= imx
 machine-$(CONFIG_ARCH_MX3)		:= imx
 machine-$(CONFIG_ARCH_MX5)		:= mx5
+machine-$(CONFIG_ARCH_MX6)		:= imx
 machine-$(CONFIG_ARCH_MXS)		:= mxs
 machine-$(CONFIG_ARCH_NETX)		:= netx
 machine-$(CONFIG_ARCH_NOMADIK)		:= nomadik

arch/arm/mach-imx/Kconfig +4 -0

index 0519dd7..4cf5178 100644
@@ -58,6 +58,10 @@ config SOC_IMX35
 	select ARCH_MX35
 	select MXC_AVIC
 
+config SOC_IMX6Q
+	bool
+	select ARM_GIC
+	select CPU_V7
 
 if ARCH_MX1
 

arch/arm/mach-imx/Makefile +2 -0

index e9eb36d..96ecc96 100644
@@ -61,3 +61,5 @@ obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
 obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
 obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd35-baseboard.o
 obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
+
+obj-$(CONFIG_DEBUG_LL) += lluart.o

arch/arm/mach-imx/Makefile.boot +0 -0

index ebee18b..389a0e3 100644

arch/arm/mach-imx/lluart.c new file +22 -0

new file mode 100644
index 0000000..34205cb
@@ -0,0 +1,33 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/init.h>
+#include <asm/page.h>
+#include <asm/sizes.h>
+#include <asm/mach/map.h>
+#include <mach/hardware.h>
+
+static struct map_desc imx_lluart_desc = {
+#ifdef CONFIG_DEBUG_IMX6Q_UART
+	.virtual	= MX6Q_UART4_BASE_VADDR,
+	.pfn		= __phys_to_pfn(MX6Q_UART4_BASE_ADDR),

arch/arm/mach-imx/lluart.c new file +1 -0

+

arch/arm/plat-mxc/Kconfig +5 -0

index a5353fc..e548f9b 100644
@@ -48,6 +48,11 @@ config ARCH_MX51
 	help
 	  This enables support for systems based on the Freescale i.MX51 family
 
+config ARCH_MX6
+	bool "i.MX6"
+	help
+	  This enables support for systems based on the Freescale i.MX6 family
+
 endchoice
 
 source "arch/arm/mach-imx/Kconfig"

arch/arm/plat-mxc/include/mach/debug-macro.S +0 -0

index 07cfdbe..471872a 100644

arch/arm/plat-mxc/include/mach/debug-macro.S +2 -0

 #endif
 
+#ifndef UART_VADDR
 #define UART_VADDR	IMX_IO_ADDRESS(UART_PADDR)
+#endif
 
 		.macro	addruart, rp, rv
 		ldr	\rp, =UART_PADDR	@ physical

arch/arm/plat-mxc/include/mach/entry-macro.S +2 -1

index 066d464..341f800 100644
@@ -1,6 +1,6 @@
 /*
  *  Copyright (C) 2007 Lennert Buytenhek <[email protected]>
- *  Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ *  Copyright 2004-2011 Freescale Semiconductor, Inc. All Rights Reserved.
  */
 
 /*

@@ -11,6 +11,17 @@
 
 #include <mach/hardware.h>
 
+#ifdef CONFIG_ARM_GIC

arch/arm/plat-mxc/include/mach/entry-macro.S +2 -0

 #define AVIC_NIMASK	0x04
 
 	@ this macro disables fast irq (not implemented)

@@ -78,3 +89,5 @@
 	movs \irqnr, \irqnr
 #endif
 	.endm
+
+#endif /* CONFIG_ARM_GIC */

arch/arm/plat-mxc/include/mach/hardware.h +1 -0

index a8bfd56..e1f84ce 100644
@@ -97,6 +97,7 @@
 
 #include <mach/mxc.h>
 
+#include <mach/mx6q.h>
 #include <mach/mx50.h>
 #include <mach/mx51.h>
 #include <mach/mx53.h>

arch/arm/plat-mxc/include/mach/irqs.h +2 -1

index 00e812b..3ae400f 100644
@@ -14,12 +14,15 @@
 #include <asm-generic/gpio.h>
 
 /*
- * SoCs with TZIC interrupt controller have 128 IRQs, those with AVIC have 64
+ * SoCs with AVIC interrupt controller have 64 IRQs, those with TZIC
+ * have 128, otherwise those with GIC have 160 IRQs.

arch/arm/plat-mxc/include/mach/irqs.h +0 -0

 #define MXC_GPIO_IRQ_START	MXC_INTERNAL_IRQS

arch/arm/plat-mxc/include/mach/memory.h +3 -0

index 11be5cd..2b8e186 100644
@@ -19,6 +19,7 @@
 #define MX50_PHYS_OFFSET	UL(0x70000000)
 #define MX51_PHYS_OFFSET	UL(0x90000000)
 #define MX53_PHYS_OFFSET	UL(0x70000000)
+#define MX6Q_PHYS_OFFSET	UL(0x10000000)
 
 #if !defined(CONFIG_RUNTIME_PHYS_OFFSET)
 # if defined CONFIG_ARCH_MX1

@@ -37,6 +38,8 @@
 #  define PLAT_PHYS_OFFSET		MX51_PHYS_OFFSET
 # elif defined CONFIG_ARCH_MX53
 #  define PLAT_PHYS_OFFSET		MX53_PHYS_OFFSET
+# elif defined CONFIG_SOC_IMX6Q
+#  define PLAT_PHYS_OFFSET		MX6Q_PHYS_OFFSET
 # endif
 #endif
 

arch/arm/plat-mxc/include/mach/mx6q.h new file +17 -0

new file mode 100644
index 0000000..7432310
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __MACH_MX6Q_H__
+#define __MACH_MX6Q_H__
+
+/* static mappings */
+#define IMX6Q_VA(x)		(0xf4000000 + (x))

arch/arm/plat-mxc/include/mach/mx6q.h new file +2 -0

+
+#endif	/* __MACH_MX6Q_H__ */

Quoted 96 lines · Shawn Guo

It adds the core definitions and low-level debug uart support for imx6q.

Signed-off-by Shawn Guo <[email protected]>

---
 arch/arm/Kconfig                             |    2 +-
 arch/arm/Kconfig.debug                       |    7 +++++
 arch/arm/Makefile                            |    1 +
 arch/arm/mach-imx/Kconfig                    |    4 +++
 arch/arm/mach-imx/Makefile                   |    2 +
 arch/arm/mach-imx/Makefile.boot              |    4 +++
 arch/arm/mach-imx/lluart.c                   |   33 ++++++++++++++++++++++++++
 arch/arm/plat-mxc/Kconfig                    |    5 ++++
 arch/arm/plat-mxc/include/mach/debug-macro.S |    5 ++++
 arch/arm/plat-mxc/include/mach/entry-macro.S |   15 +++++++++++-
 arch/arm/plat-mxc/include/mach/hardware.h    |    1 +
 arch/arm/plat-mxc/include/mach/irqs.h        |    9 ++++--
 arch/arm/plat-mxc/include/mach/memory.h      |    3 ++
 arch/arm/plat-mxc/include/mach/mx6q.h        |   29 ++++++++++++++++++++++
 14 files changed, 115 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-imx/lluart.c
 create mode 100644 arch/arm/plat-mxc/include/mach/mx6q.h

arch/arm/Kconfig +1 -1

index 4ea9974..37c20a4 100644
@@ -1348,7 +1348,7 @@ config SMP
 	depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \
 		 MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
 		 ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \
-		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE
+		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || SOC_IMX6Q
 	select USE_GENERIC_SMP_HELPERS
 	select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
 	help

arch/arm/Kconfig.debug +7 -0

index 965d59a..68fc155 100644
@@ -155,6 +155,13 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on i.MX50 or i.MX53.
 
+	config DEBUG_IMX6Q_UART
+		bool "i.MX6Q Debug UART"
+		depends on SOC_IMX6Q
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on i.MX6Q.
+
 	config DEBUG_S3C_UART0
 		depends on PLAT_SAMSUNG
 		bool "Use S3C UART 0 for low-level debug"

arch/arm/Makefile +1 -0

index 70c424e..3a0bbe4 100644
@@ -159,6 +159,7 @@ machine-$(CONFIG_ARCH_MX2)		:= imx
 machine-$(CONFIG_ARCH_MX25)		:= imx
 machine-$(CONFIG_ARCH_MX3)		:= imx
 machine-$(CONFIG_ARCH_MX5)		:= mx5
+machine-$(CONFIG_ARCH_MX6)		:= imx
 machine-$(CONFIG_ARCH_MXS)		:= mxs
 machine-$(CONFIG_ARCH_NETX)		:= netx
 machine-$(CONFIG_ARCH_NOMADIK)		:= nomadik

arch/arm/mach-imx/Kconfig +4 -0

index 0519dd7..4cf5178 100644
@@ -58,6 +58,10 @@ config SOC_IMX35
 	select ARCH_MX35
 	select MXC_AVIC
 
+config SOC_IMX6Q
+	bool
+	select ARM_GIC
+	select CPU_V7
 
 if ARCH_MX1
 

arch/arm/mach-imx/Makefile +2 -0

index e9eb36d..96ecc96 100644
@@ -61,3 +61,5 @@ obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
 obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
 obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd35-baseboard.o
 obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
+
+obj-$(CONFIG_DEBUG_LL) += lluart.o

arch/arm/mach-imx/Makefile.boot +0 -0

index ebee18b..389a0e3 100644
@@ -17,3 +17,7 @@ initrd_phys-$(CONFIG_MACH_MX27)	:= 0xA0800000

arch/arm/mach-imx/Makefile.boot initrd_phys-$(CONFIG_MACH_MX27) := 0xA0800000 · line 23

Quoted 7 lines

arch/arm/mach-imx/Makefile.boot +4 -0

 zreladdr-$(CONFIG_ARCH_MX3)	:= 0x80008000
 params_phys-$(CONFIG_ARCH_MX3)	:= 0x80000100
 initrd_phys-$(CONFIG_ARCH_MX3)	:= 0x80800000
+
+zreladdr-$(CONFIG_SOC_IMX6Q)	:= 0x10008000
+params_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10000100
+initrd_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10800000

Do you really need params_phys and initrd_phys?

Quoted 32 lines

arch/arm/mach-imx/lluart.c new file +26 -0

new file mode 100644
index 0000000..34205cb
@@ -0,0 +1,33 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/init.h>
+#include <asm/page.h>
+#include <asm/sizes.h>
+#include <asm/mach/map.h>
+#include <mach/hardware.h>
+
+static struct map_desc imx_lluart_desc = {
+#ifdef CONFIG_DEBUG_IMX6Q_UART
+	.virtual	= MX6Q_UART4_BASE_VADDR,
+	.pfn		= __phys_to_pfn(MX6Q_UART4_BASE_ADDR),
+	.length		= SZ_16K,
+	.type		= MT_DEVICE,
+#endif
+};

arch/arm/mach-imx/lluart.c line 32

Quoted 6 lines

arch/arm/mach-imx/lluart.c new file +6 -0

+
+void __init imx_lluart_map_io(void)
+{
+	if (imx_lluart_desc.virtual)
+		iotable_init(&imx_lluart_desc, 1);
+}

I don't see yet where this is called, but I wonder what happens on a non-imx6q machine (provided it is called there).

Quoted 22 lines

arch/arm/mach-imx/lluart.c new file +1 -0

+

arch/arm/plat-mxc/Kconfig +5 -0

index a5353fc..e548f9b 100644
@@ -48,6 +48,11 @@ config ARCH_MX51
 	help
 	  This enables support for systems based on the Freescale i.MX51 family
 
+config ARCH_MX6
+	bool "i.MX6"
+	help
+	  This enables support for systems based on the Freescale i.MX6 family
+
 endchoice
 
 source "arch/arm/mach-imx/Kconfig"

arch/arm/plat-mxc/include/mach/debug-macro.S +0 -0

index 07cfdbe..471872a 100644

arch/arm/plat-mxc/include/mach/debug-macro.S line 29

Quoted 6 lines

arch/arm/plat-mxc/include/mach/debug-macro.S +3 -0

@@ -24,9 +24,14 @@
 #define UART_PADDR	MX51_UART1_BASE_ADDR
 #elif defined (CONFIG_DEBUG_IMX50_IMX53_UART)
 #define UART_PADDR	MX53_UART1_BASE_ADDR
+#elif defined (CONFIG_DEBUG_IMX6Q_UART)
+#define UART_PADDR	MX6Q_UART4_BASE_ADDR
+#define UART_VADDR	MX6Q_UART4_BASE_VADDR

You cannot use the existing IMX_IO_P2V? I'd like to have a look into it to make it usable there, too. See below.

Quoted 24 lines

arch/arm/plat-mxc/include/mach/debug-macro.S +2 -0

 #endif
 
+#ifndef UART_VADDR
 #define UART_VADDR	IMX_IO_ADDRESS(UART_PADDR)
+#endif
 
 		.macro	addruart, rp, rv
 		ldr	\rp, =UART_PADDR	@ physical

arch/arm/plat-mxc/include/mach/entry-macro.S +1 -1

index 066d464..341f800 100644
@@ -1,6 +1,6 @@
 /*
  *  Copyright (C) 2007 Lennert Buytenhek <[email protected]>
- *  Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ *  Copyright 2004-2011 Freescale Semiconductor, Inc. All Rights Reserved.
  */
 
 /*

@@ -11,6 +11,17 @@
 
 #include <mach/hardware.h>
 

arch/arm/plat-mxc/include/mach/entry-macro.S line 24

Quoted 11 lines

arch/arm/plat-mxc/include/mach/entry-macro.S +11 -0

+#ifdef CONFIG_ARM_GIC
+#include <asm/hardware/entry-macro-gic.S>
+
+	.macro	disable_fiq
+	.endm
+
+	.macro	arch_ret_to_user, tmp1, tmp2
+	.endm
+
+#else
+

hmm, this essentially means mx6 support cannot go into a kernel image for the other imx machines :-(

Quoted 37 lines

arch/arm/plat-mxc/include/mach/entry-macro.S +2 -0

 #define AVIC_NIMASK	0x04
 
 	@ this macro disables fast irq (not implemented)

@@ -78,3 +89,5 @@
 	movs \irqnr, \irqnr
 #endif
 	.endm
+
+#endif /* CONFIG_ARM_GIC */

arch/arm/plat-mxc/include/mach/hardware.h +1 -0

index a8bfd56..e1f84ce 100644
@@ -97,6 +97,7 @@
 
 #include <mach/mxc.h>
 
+#include <mach/mx6q.h>
 #include <mach/mx50.h>
 #include <mach/mx51.h>
 #include <mach/mx53.h>

arch/arm/plat-mxc/include/mach/irqs.h +5 -2

index 00e812b..3ae400f 100644
@@ -14,12 +14,15 @@
 #include <asm-generic/gpio.h>
 
 /*
- * SoCs with TZIC interrupt controller have 128 IRQs, those with AVIC have 64
+ * SoCs with AVIC interrupt controller have 64 IRQs, those with TZIC
+ * have 128, otherwise those with GIC have 160 IRQs.
  */
-#ifdef CONFIG_MXC_TZIC
+#if defined CONFIG_MXC_AVIC
+#define MXC_INTERNAL_IRQS	64
+#elif defined CONFIG_MXC_TZIC

arch/arm/plat-mxc/include/mach/irqs.h line 26

Quoted 5 lines

arch/arm/plat-mxc/include/mach/irqs.h +1 -1

 #define MXC_INTERNAL_IRQS	128
 #else
-#define MXC_INTERNAL_IRQS	64
+#define MXC_INTERNAL_IRQS	160
 #endif

This is broken. The highest number has to go to the top. Otherwise if you have an image with at least 2 of the available irq controllers your MXC_INTERNAL_IRQS is too small.

Quoted 46 lines

arch/arm/plat-mxc/include/mach/irqs.h +0 -0

 #define MXC_GPIO_IRQ_START	MXC_INTERNAL_IRQS

arch/arm/plat-mxc/include/mach/memory.h +3 -0

index 11be5cd..2b8e186 100644
@@ -19,6 +19,7 @@
 #define MX50_PHYS_OFFSET	UL(0x70000000)
 #define MX51_PHYS_OFFSET	UL(0x90000000)
 #define MX53_PHYS_OFFSET	UL(0x70000000)
+#define MX6Q_PHYS_OFFSET	UL(0x10000000)
 
 #if !defined(CONFIG_RUNTIME_PHYS_OFFSET)
 # if defined CONFIG_ARCH_MX1

@@ -37,6 +38,8 @@
 #  define PLAT_PHYS_OFFSET		MX51_PHYS_OFFSET
 # elif defined CONFIG_ARCH_MX53
 #  define PLAT_PHYS_OFFSET		MX53_PHYS_OFFSET
+# elif defined CONFIG_SOC_IMX6Q
+#  define PLAT_PHYS_OFFSET		MX6Q_PHYS_OFFSET
 # endif
 #endif
 

arch/arm/plat-mxc/include/mach/mx6q.h new file +17 -0

new file mode 100644
index 0000000..7432310
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __MACH_MX6Q_H__
+#define __MACH_MX6Q_H__
+
+/* static mappings */
+#define IMX6Q_VA(x)		(0xf4000000 + (x))

arch/arm/plat-mxc/include/mach/mx6q.h line 27

Quoted 10 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +10 -0

+
+#define MX6Q_SCU_BASE_ADDR	0x00a00000
+#define MX6Q_CCM_BASE_ADDR	0x020c4000
+#define MX6Q_ANATOP_BASE_ADDR	0x020c8000
+#define MX6Q_UART4_BASE_ADDR	0x021f0000
+
+#define MX6Q_SCU_BASE_VADDR	IMX6Q_VA(MX6Q_SCU_BASE_ADDR)
+#define MX6Q_CCM_BASE_VADDR	IMX6Q_VA(MX6Q_CCM_BASE_ADDR)
+#define MX6Q_ANATOP_BASE_VADDR	IMX6Q_VA(MX6Q_ANATOP_BASE_ADDR)
+#define MX6Q_UART4_BASE_VADDR	IMX6Q_VA(MX6Q_UART4_BASE_ADDR)

Depending on the sizes of these memory regions you can use the existing IMX_IO_P2V here. The conditions are:

	SCU_SIZE <= 0x200000
	CCM_SIZE <= 0x4000
	ANATOP_SIZE <= 0x28000
	UART4 <= 0x100000

hmm, looking at patch 4 SCU_BASE is determined by a coprocessor instruction?!

Other than that these restrictions seem to be fulfilled.

Quoted 97 lines · Uwe Kleine-K?nig

Quoted 96 lines · Shawn Guo

It adds the core definitions and low-level debug uart support for imx6q.

Signed-off-by Shawn Guo <[email protected]>

---
 arch/arm/Kconfig                             |    2 +-
 arch/arm/Kconfig.debug                       |    7 +++++
 arch/arm/Makefile                            |    1 +
 arch/arm/mach-imx/Kconfig                    |    4 +++
 arch/arm/mach-imx/Makefile                   |    2 +
 arch/arm/mach-imx/Makefile.boot              |    4 +++
 arch/arm/mach-imx/lluart.c                   |   33 ++++++++++++++++++++++++++
 arch/arm/plat-mxc/Kconfig                    |    5 ++++
 arch/arm/plat-mxc/include/mach/debug-macro.S |    5 ++++
 arch/arm/plat-mxc/include/mach/entry-macro.S |   15 +++++++++++-
 arch/arm/plat-mxc/include/mach/hardware.h    |    1 +
 arch/arm/plat-mxc/include/mach/irqs.h        |    9 ++++--
 arch/arm/plat-mxc/include/mach/memory.h      |    3 ++
 arch/arm/plat-mxc/include/mach/mx6q.h        |   29 ++++++++++++++++++++++
 14 files changed, 115 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-imx/lluart.c
 create mode 100644 arch/arm/plat-mxc/include/mach/mx6q.h

arch/arm/Kconfig +1 -1

index 4ea9974..37c20a4 100644
@@ -1348,7 +1348,7 @@ config SMP
 	depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \
 		 MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
 		 ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \
-		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE
+		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || SOC_IMX6Q
 	select USE_GENERIC_SMP_HELPERS
 	select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
 	help

arch/arm/Kconfig.debug +7 -0

index 965d59a..68fc155 100644
@@ -155,6 +155,13 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on i.MX50 or i.MX53.
 
+	config DEBUG_IMX6Q_UART
+		bool "i.MX6Q Debug UART"
+		depends on SOC_IMX6Q
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on i.MX6Q.
+
 	config DEBUG_S3C_UART0
 		depends on PLAT_SAMSUNG
 		bool "Use S3C UART 0 for low-level debug"

arch/arm/Makefile +1 -0

index 70c424e..3a0bbe4 100644
@@ -159,6 +159,7 @@ machine-$(CONFIG_ARCH_MX2)		:= imx
 machine-$(CONFIG_ARCH_MX25)		:= imx
 machine-$(CONFIG_ARCH_MX3)		:= imx
 machine-$(CONFIG_ARCH_MX5)		:= mx5
+machine-$(CONFIG_ARCH_MX6)		:= imx
 machine-$(CONFIG_ARCH_MXS)		:= mxs
 machine-$(CONFIG_ARCH_NETX)		:= netx
 machine-$(CONFIG_ARCH_NOMADIK)		:= nomadik

arch/arm/mach-imx/Kconfig +4 -0

index 0519dd7..4cf5178 100644
@@ -58,6 +58,10 @@ config SOC_IMX35
 	select ARCH_MX35
 	select MXC_AVIC
 
+config SOC_IMX6Q
+	bool
+	select ARM_GIC
+	select CPU_V7
 
 if ARCH_MX1
 

arch/arm/mach-imx/Makefile +2 -0

index e9eb36d..96ecc96 100644
@@ -61,3 +61,5 @@ obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
 obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
 obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd35-baseboard.o
 obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
+
+obj-$(CONFIG_DEBUG_LL) += lluart.o

arch/arm/mach-imx/Makefile.boot +0 -0

index ebee18b..389a0e3 100644
@@ -17,3 +17,7 @@ initrd_phys-$(CONFIG_MACH_MX27)	:= 0xA0800000

Quoted 9 lines

arch/arm/mach-imx/Makefile.boot initrd_phys-$(CONFIG_MACH_MX27) := 0xA0800000 · line 23

Quoted 7 lines

arch/arm/mach-imx/Makefile.boot +4 -0

 zreladdr-$(CONFIG_ARCH_MX3)	:= 0x80008000
 params_phys-$(CONFIG_ARCH_MX3)	:= 0x80000100
 initrd_phys-$(CONFIG_ARCH_MX3)	:= 0x80800000
+
+zreladdr-$(CONFIG_SOC_IMX6Q)	:= 0x10008000
+params_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10000100
+initrd_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10800000

Do you really need params_phys and initrd_phys?

I added them to make IMX6Q look consistent with other soc in the file, and leave it to a global cleanup, if we decide to clean later.

Quoted 32 lines

Quoted 32 lines

arch/arm/mach-imx/lluart.c new file +26 -0

new file mode 100644
index 0000000..34205cb
@@ -0,0 +1,33 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/init.h>
+#include <asm/page.h>
+#include <asm/sizes.h>
+#include <asm/mach/map.h>
+#include <mach/hardware.h>
+
+static struct map_desc imx_lluart_desc = {
+#ifdef CONFIG_DEBUG_IMX6Q_UART
+	.virtual	= MX6Q_UART4_BASE_VADDR,
+	.pfn		= __phys_to_pfn(MX6Q_UART4_BASE_ADDR),
+	.length		= SZ_16K,
+	.type		= MT_DEVICE,
+#endif
+};

Quoted 8 lines

arch/arm/mach-imx/lluart.c line 32

Quoted 6 lines

arch/arm/mach-imx/lluart.c new file +6 -0

+
+void __init imx_lluart_map_io(void)
+{
+	if (imx_lluart_desc.virtual)
+		iotable_init(&imx_lluart_desc, 1);
+}

I don't see yet where this is called, but I wonder what happens on a non-imx6q machine (provided it is called there).

This is called by imx6q_map_io() in mach-imx6q.c. For non-imx6q machines, imx_lluart_desc will be all zero,

therefore iotable_init()
call will be bypassed.

Quoted 55 lines

Quoted 22 lines

arch/arm/mach-imx/lluart.c new file +1 -0

+

arch/arm/plat-mxc/Kconfig +5 -0

index a5353fc..e548f9b 100644
@@ -48,6 +48,11 @@ config ARCH_MX51
 	help
 	  This enables support for systems based on the Freescale i.MX51 family
 
+config ARCH_MX6
+	bool "i.MX6"
+	help
+	  This enables support for systems based on the Freescale i.MX6 family
+
 endchoice
 
 source "arch/arm/mach-imx/Kconfig"

arch/arm/plat-mxc/include/mach/debug-macro.S +0 -0

index 07cfdbe..471872a 100644

arch/arm/plat-mxc/include/mach/debug-macro.S line 29

Quoted 6 lines

arch/arm/plat-mxc/include/mach/debug-macro.S +3 -0

@@ -24,9 +24,14 @@
 #define UART_PADDR	MX51_UART1_BASE_ADDR
 #elif defined (CONFIG_DEBUG_IMX50_IMX53_UART)
 #define UART_PADDR	MX53_UART1_BASE_ADDR
+#elif defined (CONFIG_DEBUG_IMX6Q_UART)
+#define UART_PADDR	MX6Q_UART4_BASE_ADDR
+#define UART_VADDR	MX6Q_UART4_BASE_VADDR

You cannot use the existing IMX_IO_P2V? I'd like to have a look into it to make it usable there, too. See below.

Quoted 24 lines

arch/arm/plat-mxc/include/mach/debug-macro.S +2 -0

 #endif
 
+#ifndef UART_VADDR
 #define UART_VADDR	IMX_IO_ADDRESS(UART_PADDR)
+#endif
 
 		.macro	addruart, rp, rv
 		ldr	\rp, =UART_PADDR	@ physical

arch/arm/plat-mxc/include/mach/entry-macro.S +1 -1

index 066d464..341f800 100644
@@ -1,6 +1,6 @@
 /*
  *  Copyright (C) 2007 Lennert Buytenhek <[email protected]>
- *  Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ *  Copyright 2004-2011 Freescale Semiconductor, Inc. All Rights Reserved.
  */
 
 /*

@@ -11,6 +11,17 @@
 
 #include <mach/hardware.h>
 

Quoted 14 lines

arch/arm/plat-mxc/include/mach/entry-macro.S line 24

Quoted 11 lines

arch/arm/plat-mxc/include/mach/entry-macro.S +11 -0

+#ifdef CONFIG_ARM_GIC
+#include <asm/hardware/entry-macro-gic.S>
+
+	.macro	disable_fiq
+	.endm
+
+	.macro	arch_ret_to_user, tmp1, tmp2
+	.endm
+
+#else
+

hmm, this essentially means mx6 support cannot go into a kernel image for the other imx machines :-(

Ah, sorry. I totally forgot about this. Will fix it in the next version.

Quoted 37 lines

Quoted 37 lines

arch/arm/plat-mxc/include/mach/entry-macro.S +2 -0

 #define AVIC_NIMASK	0x04
 
 	@ this macro disables fast irq (not implemented)

@@ -78,3 +89,5 @@
 	movs \irqnr, \irqnr
 #endif
 	.endm
+
+#endif /* CONFIG_ARM_GIC */

arch/arm/plat-mxc/include/mach/hardware.h +1 -0

index a8bfd56..e1f84ce 100644
@@ -97,6 +97,7 @@
 
 #include <mach/mxc.h>
 
+#include <mach/mx6q.h>
 #include <mach/mx50.h>
 #include <mach/mx51.h>
 #include <mach/mx53.h>

arch/arm/plat-mxc/include/mach/irqs.h +5 -2

index 00e812b..3ae400f 100644
@@ -14,12 +14,15 @@
 #include <asm-generic/gpio.h>
 
 /*
- * SoCs with TZIC interrupt controller have 128 IRQs, those with AVIC have 64
+ * SoCs with AVIC interrupt controller have 64 IRQs, those with TZIC
+ * have 128, otherwise those with GIC have 160 IRQs.
  */
-#ifdef CONFIG_MXC_TZIC
+#if defined CONFIG_MXC_AVIC
+#define MXC_INTERNAL_IRQS	64
+#elif defined CONFIG_MXC_TZIC

Quoted 9 lines

arch/arm/plat-mxc/include/mach/irqs.h line 26

Quoted 5 lines

arch/arm/plat-mxc/include/mach/irqs.h +1 -1

 #define MXC_INTERNAL_IRQS	128
 #else
-#define MXC_INTERNAL_IRQS	64
+#define MXC_INTERNAL_IRQS	160
 #endif

This is broken. The highest number has to go to the top. Otherwise if you have an image with at least 2 of the available irq controllers your MXC_INTERNAL_IRQS is too small.

Yes, this is yet another one I forgot about single image support. I should probably put some documentation about the correct order, which can be forgot by people like me.

Quoted 58 lines

Quoted 45 lines

arch/arm/plat-mxc/include/mach/irqs.h +0 -0

 #define MXC_GPIO_IRQ_START	MXC_INTERNAL_IRQS

arch/arm/plat-mxc/include/mach/memory.h +3 -0

index 11be5cd..2b8e186 100644
@@ -19,6 +19,7 @@
 #define MX50_PHYS_OFFSET	UL(0x70000000)
 #define MX51_PHYS_OFFSET	UL(0x90000000)
 #define MX53_PHYS_OFFSET	UL(0x70000000)
+#define MX6Q_PHYS_OFFSET	UL(0x10000000)
 
 #if !defined(CONFIG_RUNTIME_PHYS_OFFSET)
 # if defined CONFIG_ARCH_MX1

@@ -37,6 +38,8 @@
 #  define PLAT_PHYS_OFFSET		MX51_PHYS_OFFSET
 # elif defined CONFIG_ARCH_MX53
 #  define PLAT_PHYS_OFFSET		MX53_PHYS_OFFSET
+# elif defined CONFIG_SOC_IMX6Q
+#  define PLAT_PHYS_OFFSET		MX6Q_PHYS_OFFSET
 # endif
 #endif
 

arch/arm/plat-mxc/include/mach/mx6q.h new file +17 -0

new file mode 100644
index 0000000..7432310
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __MACH_MX6Q_H__
+#define __MACH_MX6Q_H__
+
+/* static mappings */
+#define IMX6Q_VA(x)		(0xf4000000 + (x))

arch/arm/plat-mxc/include/mach/mx6q.h line 27

Quoted 10 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +10 -0

+
+#define MX6Q_SCU_BASE_ADDR	0x00a00000
+#define MX6Q_CCM_BASE_ADDR	0x020c4000
+#define MX6Q_ANATOP_BASE_ADDR	0x020c8000
+#define MX6Q_UART4_BASE_ADDR	0x021f0000
+
+#define MX6Q_SCU_BASE_VADDR	IMX6Q_VA(MX6Q_SCU_BASE_ADDR)
+#define MX6Q_CCM_BASE_VADDR	IMX6Q_VA(MX6Q_CCM_BASE_ADDR)
+#define MX6Q_ANATOP_BASE_VADDR	IMX6Q_VA(MX6Q_ANATOP_BASE_ADDR)
+#define MX6Q_UART4_BASE_VADDR	IMX6Q_VA(MX6Q_UART4_BASE_ADDR)

Depending on the sizes of these memory regions you can use the existing IMX_IO_P2V here. The conditions are:

Quoted 1 line

	SCU_SIZE <= 0x200000

Quoted 4 lines

	CCM_SIZE <= 0x4000
	ANATOP_SIZE <= 0x28000
	UART4 <= 0x100000

This is exactly what I dislike about IMX_IO_P2V(). We have to verify all these conditions manually. Looking at the static mapping below

(copied from arch/arm/plat-mxc/include/mach/hardware.h), do you think it's really scalable and easy to maintain for the long run?

/*
* This is rather complicated for humans and ugly to verify, but for a machine
* it's OK. Still more as it is usually only applied to constants. The upsides
* on using this approach are:
*

 *  - same mapping on all i.MX machines
 *  - works for assembler, too
 *  - no need to nurture #defines for virtual addresses

*
* The downside it, it's hard to verify (but I have a script for that).

* Obviously this needs to be injective for each SoC. In general it maps the
* whole address space to [0xf4000000, 0xf5ffffff]. So [0xf6000000,0xfeffffff]
* is free for per-machine use (e.g. KZM_ARM11_01 uses 64MiB there). *
* It applies the following mappings for the different SoCs:
*
* mx1:
* IO 0x00200000+0x100000 -> 0xf4000000+0x100000
* mx21:
* AIPI 0x10000000+0x100000 -> 0xf4400000+0x100000
* SAHB1 0x80000000+0x100000 -> 0xf4000000+0x100000
* X_MEMC 0xdf000000+0x004000 -> 0xf5f00000+0x004000
* mx25:
* AIPS1 0x43f00000+0x100000 -> 0xf5300000+0x100000
* AIPS2 0x53f00000+0x100000 -> 0xf5700000+0x100000
* AVIC 0x68000000+0x100000 -> 0xf5800000+0x100000
* mx27:
* AIPI 0x10000000+0x100000 -> 0xf4400000+0x100000
* SAHB1 0x80000000+0x100000 -> 0xf4000000+0x100000
* X_MEMC 0xd8000000+0x100000 -> 0xf5c00000+0x100000
* mx31:
* AIPS1 0x43f00000+0x100000 -> 0xf5300000+0x100000
* AIPS2 0x53f00000+0x100000 -> 0xf5700000+0x100000
* AVIC 0x68000000+0x100000 -> 0xf5800000+0x100000
* X_MEMC 0xb8000000+0x010000 -> 0xf4c00000+0x010000
* SPBA0 0x50000000+0x100000 -> 0xf5400000+0x100000
* mx35:
* AIPS1 0x43f00000+0x100000 -> 0xf5300000+0x100000
* AIPS2 0x53f00000+0x100000 -> 0xf5700000+0x100000
* AVIC 0x68000000+0x100000 -> 0xf5800000+0x100000
* X_MEMC 0xb8000000+0x010000 -> 0xf4c00000+0x010000
* SPBA0 0x50000000+0x100000 -> 0xf5400000+0x100000
* mx50:
* TZIC 0x0fffc000+0x004000 -> 0xf4bfc000+0x004000
* SPBA0 0x50000000+0x100000 -> 0xf5400000+0x100000
* AIPS1 0x53f00000+0x100000 -> 0xf5700000+0x100000
* AIPS2 0x63f00000+0x100000 -> 0xf5300000+0x100000
* mx51:
* IRAM 0x1ffe0000+0x020000 -> 0xf4fe0000+0x020000
* DEBUG 0x60000000+0x100000 -> 0xf5000000+0x100000
* SPBA0 0x70000000+0x100000 -> 0xf5400000+0x100000
* AIPS1 0x73f00000+0x100000 -> 0xf5700000+0x100000
* AIPS2 0x83f00000+0x100000 -> 0xf4300000+0x100000
*/

#define IMX_IO_P2V(x)	(						\
			0xf4000000 +					\
			(((x) & 0x50000000) >> 6) +			\
			(((x) & 0x0b000000) >> 4) +			\
			(((x) & 0x000fffff)))

Quoted 2 lines

hmm, looking at patch 4 SCU_BASE is determined by a coprocessor instruction?!

Ah, yes. The SCU physical base address can be retrieved from coprocessor.

But only if the image doesn't support imx6q, right? Anyhow, I hope imx6q_map_io isn't called for pre-imx6q SoCs. Ah, and I hope we don't need to argue here as Russell doesn't like the new DEBUG_LL changes :-)

Quoted 3 lines · Uwe Kleine-K?nig

But only if the image doesn't support imx6q, right? Anyhow, I hope imx6q_map_io isn't called for pre-imx6q SoCs. Ah, and I hope we don't need to argue here as Russell doesn't like the new DEBUG_LL changes :-)

I have no problem with the Kconfig menu approach or existing approaches to DEBUG_LL. What I have an objection to is trying to stuff the information for it into places which ultimately render the facility useless for its intended purpose - to permit debugging the _really_ _early_ assembly code.

That is what it was written for: if we introduce complicated ways to put behind it, we'll need to come up with a completely new debugging infrastructure to debug the now buggered debugging infrastructure.

Quoted 11 lines · Russell King - ARM Linux

Quoted 3 lines · Uwe Kleine-K?nig

But only if the image doesn't support imx6q, right? Anyhow, I hope imx6q_map_io isn't called for pre-imx6q SoCs. Ah, and I hope we don't need to argue here as Russell doesn't like the new DEBUG_LL changes :-)

I have no problem with the Kconfig menu approach or existing approaches to DEBUG_LL. What I have an objection to is trying to stuff the information for it into places which ultimately render the facility useless for its intended purpose - to permit debugging the really early assembly code.

Quoted 3 lines

That is what it was written for: if we introduce complicated ways to put behind it, we'll need to come up with a completely new debugging infrastructure to debug the now buggered debugging infrastructure.

For the record I now agree with Russell.

In order to have early serial output that works across multiple SOCs in the same kernel image intended to non developers we'll have to add a parallel infrastructure. Keeping the DEBUG_LL code as simple as possible for developers is the way to go (and that might be needed to debug that parallel infrastructure).

Quoted 17 lines · Nicolas Pitre

Quoted 11 lines · Russell King - ARM Linux

Quoted 3 lines · Uwe Kleine-K?nig

But only if the image doesn't support imx6q, right? Anyhow, I hope imx6q_map_io isn't called for pre-imx6q SoCs. Ah, and I hope we don't need to argue here as Russell doesn't like the new DEBUG_LL changes :-)

I have no problem with the Kconfig menu approach or existing approaches to DEBUG_LL. What I have an objection to is trying to stuff the information for it into places which ultimately render the facility useless for its intended purpose - to permit debugging the really early assembly code.

Quoted 3 lines

That is what it was written for: if we introduce complicated ways to put behind it, we'll need to come up with a completely new debugging infrastructure to debug the now buggered debugging infrastructure.

Quoted 7 lines

For the record I now agree with Russell.

In order to have early serial output that works across multiple SOCs in the same kernel image intended to non developers we'll have to add a parallel infrastructure. Keeping the DEBUG_LL code as simple as possible for developers is the way to go (and that might be needed to debug that parallel infrastructure).

Yes, agreed. It should not be too hard to provide more CON_BOOT consoles. For 8250, this can actually be done already using the code from drivers/tty/serial/8250_early.c with a custom command line, but there are better ways to do that in a generic way.

Quoted 2 lines · Shawn Guo

Quoted 1 line · Uwe Kleine-K?nig

On Tue, Sep 06, 2011 at 05:58:36PM +0800, Shawn Guo wrote:

Quoted 36 lines

Quoted 36 lines

Quoted 23 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +17 -0

new file mode 100644
index 0000000..7432310
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __MACH_MX6Q_H__
+#define __MACH_MX6Q_H__
+
+/* static mappings */
+#define IMX6Q_VA(x)		(0xf4000000 + (x))

arch/arm/plat-mxc/include/mach/mx6q.h line 27

Quoted 10 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +10 -0

+
+#define MX6Q_SCU_BASE_ADDR	0x00a00000
+#define MX6Q_CCM_BASE_ADDR	0x020c4000
+#define MX6Q_ANATOP_BASE_ADDR	0x020c8000
+#define MX6Q_UART4_BASE_ADDR	0x021f0000
+
+#define MX6Q_SCU_BASE_VADDR	IMX6Q_VA(MX6Q_SCU_BASE_ADDR)
+#define MX6Q_CCM_BASE_VADDR	IMX6Q_VA(MX6Q_CCM_BASE_ADDR)
+#define MX6Q_ANATOP_BASE_VADDR	IMX6Q_VA(MX6Q_ANATOP_BASE_ADDR)
+#define MX6Q_UART4_BASE_VADDR	IMX6Q_VA(MX6Q_UART4_BASE_ADDR)

Depending on the sizes of these memory regions you can use the existing IMX_IO_P2V here. The conditions are:

Quoted 1 line

Quoted 1 line

	SCU_SIZE <= 0x200000

Actually this should be 0x100000 as this is the size that is mapped in a continous chunk.

Quoted 6 lines

Quoted 4 lines

	CCM_SIZE <= 0x4000
	ANATOP_SIZE <= 0x28000
	UART4 <= 0x100000

This is exactly what I dislike about IMX_IO_P2V(). We have to verify all these conditions manually. Looking at the static mapping below

I did it semi-manual, I just put your constants for imx6q into my script (all with size=0x4000 for now) and it told me:

...
* mx6q:
* SCU 0x00a00000+0x004000 -> 0xf4000000+0x004000
* CCM 0x020c4000+0x004000 -> 0xf42c4000+0x004000
* ANATOP 0x020c8000+0x004000 -> 0xf42c8000+0x004000
* UART4 0x021f0000+0x004000 -> 0xf42f0000+0x004000
...

Quoted 2 lines

(copied from arch/arm/plat-mxc/include/mach/hardware.h), do you think it's really scalable and easy to maintain for the long run?

At least it provides a way to verify the correctness of the mapping. Before I introduced the mapping function there was a conflict IIRC.

Quoted 10 lines

/*
* This is rather complicated for humans and ugly to verify, but for a machine
* it's OK. Still more as it is usually only applied to constants. The upsides
* on using this approach are:
*

 *  - same mapping on all i.MX machines
 *  - works for assembler, too
 *  - no need to nurture #defines for virtual addresses

*
* The downside it, it's hard to verify (but I have a script for that).

If you want I can provide you that script.

Quoted 6 lines

#define IMX_IO_P2V(x)	(						\
			0xf4000000 +					\
			(((x) & 0x50000000) >> 6) +			\
			(((x) & 0x0b000000) >> 4) +			\
			(((x) & 0x000fffff)))

Quoted 5 lines

Quoted 2 lines

hmm, looking at patch 4 SCU_BASE is determined by a coprocessor instruction?!

Ah, yes. The SCU physical base address can be retrieved from coprocessor.

Is there an advantage in autodetecting the base address?

Quoted 3 lines · Uwe Kleine-K?nig

Quoted 2 lines · Shawn Guo

Quoted 1 line · Uwe Kleine-K?nig

On Tue, Sep 06, 2011 at 05:58:36PM +0800, Shawn Guo wrote:

[...]

Quoted 72 lines

Quoted 36 lines

Quoted 36 lines

Quoted 23 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +17 -0

new file mode 100644
index 0000000..7432310
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __MACH_MX6Q_H__
+#define __MACH_MX6Q_H__
+
+/* static mappings */
+#define IMX6Q_VA(x)		(0xf4000000 + (x))

arch/arm/plat-mxc/include/mach/mx6q.h line 27

Quoted 10 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +10 -0

+
+#define MX6Q_SCU_BASE_ADDR	0x00a00000
+#define MX6Q_CCM_BASE_ADDR	0x020c4000
+#define MX6Q_ANATOP_BASE_ADDR	0x020c8000
+#define MX6Q_UART4_BASE_ADDR	0x021f0000
+
+#define MX6Q_SCU_BASE_VADDR	IMX6Q_VA(MX6Q_SCU_BASE_ADDR)
+#define MX6Q_CCM_BASE_VADDR	IMX6Q_VA(MX6Q_CCM_BASE_ADDR)
+#define MX6Q_ANATOP_BASE_VADDR	IMX6Q_VA(MX6Q_ANATOP_BASE_ADDR)
+#define MX6Q_UART4_BASE_VADDR	IMX6Q_VA(MX6Q_UART4_BASE_ADDR)

Depending on the sizes of these memory regions you can use the existing IMX_IO_P2V here. The conditions are:

Quoted 1 line

Quoted 1 line

	SCU_SIZE <= 0x200000

Actually this should be 0x100000 as this is the size that is mapped in a continous chunk.

Quoted 6 lines

Quoted 4 lines

	CCM_SIZE <= 0x4000
	ANATOP_SIZE <= 0x28000
	UART4 <= 0x100000

This is exactly what I dislike about IMX_IO_P2V(). We have to verify all these conditions manually. Looking at the static mapping below

I did it semi-manual, I just put your constants for imx6q into my script (all with size=0x4000 for now) and it told me:

...
* mx6q:
* SCU 0x00a00000+0x004000 -> 0xf4000000+0x004000
* CCM 0x020c4000+0x004000 -> 0xf42c4000+0x004000
* ANATOP 0x020c8000+0x004000 -> 0xf42c8000+0x004000
* UART4 0x021f0000+0x004000 -> 0xf42f0000+0x004000
...

Quoted 2 lines

(copied from arch/arm/plat-mxc/include/mach/hardware.h), do you think it's really scalable and easy to maintain for the long run?

At least it provides a way to verify the correctness of the mapping. Before I introduced the mapping function there was a conflict IIRC.

Quoted 10 lines

/*
* This is rather complicated for humans and ugly to verify, but for a machine
* it's OK. Still more as it is usually only applied to constants. The upsides
* on using this approach are:
*

 *  - same mapping on all i.MX machines
 *  - works for assembler, too
 *  - no need to nurture #defines for virtual addresses

*
* The downside it, it's hard to verify (but I have a script for that).

Quoted 2 lines

If you want I can provide you that script.

Yes, please. I would use IMX_IO_P2V() in the next post.

[...]

Quoted 6 lines

Quoted 6 lines

#define IMX_IO_P2V(x)	(						\
			0xf4000000 +					\
			(((x) & 0x50000000) >> 6) +			\
			(((x) & 0x0b000000) >> 4) +			\
			(((x) & 0x000fffff)))

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

hmm, looking at patch 4 SCU_BASE is determined by a coprocessor instruction?!

Ah, yes. The SCU physical base address can be retrieved from coprocessor.

Is there an advantage in autodetecting the base address?

Any disadvantage for doing so?

Hello Shawn,

Quoted 79 lines · Shawn Guo

Quoted 3 lines · Uwe Kleine-K?nig

Quoted 2 lines · Shawn Guo

Quoted 1 line · Uwe Kleine-K?nig

On Tue, Sep 06, 2011 at 05:58:36PM +0800, Shawn Guo wrote:

[...]

Quoted 72 lines

Quoted 36 lines

Quoted 36 lines

Quoted 23 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +17 -0

new file mode 100644
index 0000000..7432310
@@ -0,0 +1,29 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __MACH_MX6Q_H__
+#define __MACH_MX6Q_H__
+
+/* static mappings */
+#define IMX6Q_VA(x)		(0xf4000000 + (x))

arch/arm/plat-mxc/include/mach/mx6q.h line 27

Quoted 10 lines

arch/arm/plat-mxc/include/mach/mx6q.h new file +10 -0

+
+#define MX6Q_SCU_BASE_ADDR	0x00a00000
+#define MX6Q_CCM_BASE_ADDR	0x020c4000
+#define MX6Q_ANATOP_BASE_ADDR	0x020c8000
+#define MX6Q_UART4_BASE_ADDR	0x021f0000
+
+#define MX6Q_SCU_BASE_VADDR	IMX6Q_VA(MX6Q_SCU_BASE_ADDR)
+#define MX6Q_CCM_BASE_VADDR	IMX6Q_VA(MX6Q_CCM_BASE_ADDR)
+#define MX6Q_ANATOP_BASE_VADDR	IMX6Q_VA(MX6Q_ANATOP_BASE_ADDR)
+#define MX6Q_UART4_BASE_VADDR	IMX6Q_VA(MX6Q_UART4_BASE_ADDR)

Depending on the sizes of these memory regions you can use the existing IMX_IO_P2V here. The conditions are:

Quoted 1 line

Quoted 1 line

	SCU_SIZE <= 0x200000

Actually this should be 0x100000 as this is the size that is mapped in a continous chunk.

Quoted 6 lines

Quoted 4 lines

	CCM_SIZE <= 0x4000
	ANATOP_SIZE <= 0x28000
	UART4 <= 0x100000

This is exactly what I dislike about IMX_IO_P2V(). We have to verify all these conditions manually. Looking at the static mapping below

I did it semi-manual, I just put your constants for imx6q into my script (all with size=0x4000 for now) and it told me:

...
* mx6q:
* SCU 0x00a00000+0x004000 -> 0xf4000000+0x004000
* CCM 0x020c4000+0x004000 -> 0xf42c4000+0x004000
* ANATOP 0x020c8000+0x004000 -> 0xf42c8000+0x004000
* UART4 0x021f0000+0x004000 -> 0xf42f0000+0x004000
...

Quoted 2 lines

(copied from arch/arm/plat-mxc/include/mach/hardware.h), do you think it's really scalable and easy to maintain for the long run?

At least it provides a way to verify the correctness of the mapping. Before I introduced the mapping function there was a conflict IIRC.

Quoted 10 lines

/*
* This is rather complicated for humans and ugly to verify, but for a machine
* it's OK. Still more as it is usually only applied to constants. The upsides
* on using this approach are:
*

 *  - same mapping on all i.MX machines
 *  - works for assembler, too
 *  - no need to nurture #defines for virtual addresses

*
* The downside it, it's hard to verify (but I have a script for that).

Quoted 3 lines

Quoted 2 lines

If you want I can provide you that script.

Yes, please. I would use IMX_IO_P2V() in the next post.

I just found a bug in the conflict detection code, so I put it in a repository to prevent the broken script to enter the archives. You can find it on

git://git.pengutronix.de/git/ukl/imx-iop2v.git

Quoted 13 lines

[...]

Quoted 11 lines

Quoted 11 lines

#define IMX_IO_P2V(x)	(						\
			0xf4000000 +					\
			(((x) & 0x50000000) >> 6) +			\
			(((x) & 0x0b000000) >> 4) +			\
			(((x) & 0x000fffff)))

Quoted 2 lines

hmm, looking at patch 4 SCU_BASE is determined by a coprocessor instruction?!

Ah, yes. The SCU physical base address can be retrieved from coprocessor.

Quoted 3 lines

Quoted 2 lines

Is there an advantage in autodetecting the base address?

Any disadvantage for doing so?

It makes

	#define MX6Q_SCU_BASE_ADDR       0x00a00000

superfluous.

And in case the real address is different it might make

	IMX_IO_P2V(real scu address) != scu_io_desc.virtual

which makes the scriptable check for conflicts kind of useless and might come as a surprise.

Quoted 97 lines · Uwe Kleine-K?nig

Quoted 96 lines · Shawn Guo

It adds the core definitions and low-level debug uart support for imx6q.

Signed-off-by Shawn Guo <[email protected]>

---
 arch/arm/Kconfig                             |    2 +-
 arch/arm/Kconfig.debug                       |    7 +++++
 arch/arm/Makefile                            |    1 +
 arch/arm/mach-imx/Kconfig                    |    4 +++
 arch/arm/mach-imx/Makefile                   |    2 +
 arch/arm/mach-imx/Makefile.boot              |    4 +++
 arch/arm/mach-imx/lluart.c                   |   33 ++++++++++++++++++++++++++
 arch/arm/plat-mxc/Kconfig                    |    5 ++++
 arch/arm/plat-mxc/include/mach/debug-macro.S |    5 ++++
 arch/arm/plat-mxc/include/mach/entry-macro.S |   15 +++++++++++-
 arch/arm/plat-mxc/include/mach/hardware.h    |    1 +
 arch/arm/plat-mxc/include/mach/irqs.h        |    9 ++++--
 arch/arm/plat-mxc/include/mach/memory.h      |    3 ++
 arch/arm/plat-mxc/include/mach/mx6q.h        |   29 ++++++++++++++++++++++
 14 files changed, 115 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-imx/lluart.c
 create mode 100644 arch/arm/plat-mxc/include/mach/mx6q.h

arch/arm/Kconfig +1 -1

index 4ea9974..37c20a4 100644
@@ -1348,7 +1348,7 @@ config SMP
 	depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \
 		 MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
 		 ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \
-		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE
+		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || SOC_IMX6Q
 	select USE_GENERIC_SMP_HELPERS
 	select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
 	help

arch/arm/Kconfig.debug +7 -0

index 965d59a..68fc155 100644
@@ -155,6 +155,13 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on i.MX50 or i.MX53.
 
+	config DEBUG_IMX6Q_UART
+		bool "i.MX6Q Debug UART"
+		depends on SOC_IMX6Q
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on i.MX6Q.
+
 	config DEBUG_S3C_UART0
 		depends on PLAT_SAMSUNG
 		bool "Use S3C UART 0 for low-level debug"

arch/arm/Makefile +1 -0

index 70c424e..3a0bbe4 100644
@@ -159,6 +159,7 @@ machine-$(CONFIG_ARCH_MX2)		:= imx
 machine-$(CONFIG_ARCH_MX25)		:= imx
 machine-$(CONFIG_ARCH_MX3)		:= imx
 machine-$(CONFIG_ARCH_MX5)		:= mx5
+machine-$(CONFIG_ARCH_MX6)		:= imx
 machine-$(CONFIG_ARCH_MXS)		:= mxs
 machine-$(CONFIG_ARCH_NETX)		:= netx
 machine-$(CONFIG_ARCH_NOMADIK)		:= nomadik

arch/arm/mach-imx/Kconfig +4 -0

index 0519dd7..4cf5178 100644
@@ -58,6 +58,10 @@ config SOC_IMX35
 	select ARCH_MX35
 	select MXC_AVIC
 
+config SOC_IMX6Q
+	bool
+	select ARM_GIC
+	select CPU_V7
 
 if ARCH_MX1
 

arch/arm/mach-imx/Makefile +2 -0

index e9eb36d..96ecc96 100644
@@ -61,3 +61,5 @@ obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
 obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
 obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd35-baseboard.o
 obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
+
+obj-$(CONFIG_DEBUG_LL) += lluart.o

arch/arm/mach-imx/Makefile.boot +0 -0

index ebee18b..389a0e3 100644
@@ -17,3 +17,7 @@ initrd_phys-$(CONFIG_MACH_MX27)	:= 0xA0800000

Quoted 9 lines

arch/arm/mach-imx/Makefile.boot initrd_phys-$(CONFIG_MACH_MX27) := 0xA0800000 · line 23

Quoted 7 lines

arch/arm/mach-imx/Makefile.boot +4 -0

 zreladdr-$(CONFIG_ARCH_MX3)	:= 0x80008000
 params_phys-$(CONFIG_ARCH_MX3)	:= 0x80000100
 initrd_phys-$(CONFIG_ARCH_MX3)	:= 0x80800000
+
+zreladdr-$(CONFIG_SOC_IMX6Q)	:= 0x10008000
+params_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10000100
+initrd_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10800000

Do you really need params_phys and initrd_phys?

I added them to make IMX6Q look consistent with other soc in the file, and leave it to a global cleanup, if we decide to clean later.

Quoted 107 lines · Shawn Guo

Quoted 106 lines · Uwe Kleine-K?nig

Quoted 96 lines · Shawn Guo

It adds the core definitions and low-level debug uart support for imx6q.

Signed-off-by Shawn Guo <[email protected]>

---
 arch/arm/Kconfig                             |    2 +-
 arch/arm/Kconfig.debug                       |    7 +++++
 arch/arm/Makefile                            |    1 +
 arch/arm/mach-imx/Kconfig                    |    4 +++
 arch/arm/mach-imx/Makefile                   |    2 +
 arch/arm/mach-imx/Makefile.boot              |    4 +++
 arch/arm/mach-imx/lluart.c                   |   33 ++++++++++++++++++++++++++
 arch/arm/plat-mxc/Kconfig                    |    5 ++++
 arch/arm/plat-mxc/include/mach/debug-macro.S |    5 ++++
 arch/arm/plat-mxc/include/mach/entry-macro.S |   15 +++++++++++-
 arch/arm/plat-mxc/include/mach/hardware.h    |    1 +
 arch/arm/plat-mxc/include/mach/irqs.h        |    9 ++++--
 arch/arm/plat-mxc/include/mach/memory.h      |    3 ++
 arch/arm/plat-mxc/include/mach/mx6q.h        |   29 ++++++++++++++++++++++
 14 files changed, 115 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-imx/lluart.c
 create mode 100644 arch/arm/plat-mxc/include/mach/mx6q.h

arch/arm/Kconfig +1 -1

index 4ea9974..37c20a4 100644
@@ -1348,7 +1348,7 @@ config SMP
 	depends on REALVIEW_EB_ARM11MP || REALVIEW_EB_A9MP || \
 		 MACH_REALVIEW_PB11MP || MACH_REALVIEW_PBX || ARCH_OMAP4 || \
 		 ARCH_EXYNOS4 || ARCH_TEGRA || ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || \
-		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE
+		 ARCH_MSM_SCORPIONMP || ARCH_SHMOBILE || SOC_IMX6Q
 	select USE_GENERIC_SMP_HELPERS
 	select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
 	help

arch/arm/Kconfig.debug +7 -0

index 965d59a..68fc155 100644
@@ -155,6 +155,13 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on i.MX50 or i.MX53.
 
+	config DEBUG_IMX6Q_UART
+		bool "i.MX6Q Debug UART"
+		depends on SOC_IMX6Q
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on i.MX6Q.
+
 	config DEBUG_S3C_UART0
 		depends on PLAT_SAMSUNG
 		bool "Use S3C UART 0 for low-level debug"

arch/arm/Makefile +1 -0

index 70c424e..3a0bbe4 100644
@@ -159,6 +159,7 @@ machine-$(CONFIG_ARCH_MX2)		:= imx
 machine-$(CONFIG_ARCH_MX25)		:= imx
 machine-$(CONFIG_ARCH_MX3)		:= imx
 machine-$(CONFIG_ARCH_MX5)		:= mx5
+machine-$(CONFIG_ARCH_MX6)		:= imx
 machine-$(CONFIG_ARCH_MXS)		:= mxs
 machine-$(CONFIG_ARCH_NETX)		:= netx
 machine-$(CONFIG_ARCH_NOMADIK)		:= nomadik

arch/arm/mach-imx/Kconfig +4 -0

index 0519dd7..4cf5178 100644
@@ -58,6 +58,10 @@ config SOC_IMX35
 	select ARCH_MX35
 	select MXC_AVIC
 
+config SOC_IMX6Q
+	bool
+	select ARM_GIC
+	select CPU_V7
 
 if ARCH_MX1
 

arch/arm/mach-imx/Makefile +2 -0

index e9eb36d..96ecc96 100644
@@ -61,3 +61,5 @@ obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
 obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
 obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd35-baseboard.o
 obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
+
+obj-$(CONFIG_DEBUG_LL) += lluart.o

arch/arm/mach-imx/Makefile.boot +0 -0

index ebee18b..389a0e3 100644

arch/arm/mach-imx/Makefile.boot initrd_phys-$(CONFIG_MACH_MX27) := 0xA0800000 · line 23

Quoted 7 lines

arch/arm/mach-imx/Makefile.boot +4 -0

@@ -17,3 +17,7 @@ initrd_phys-$(CONFIG_MACH_MX27)	:= 0xA0800000
 zreladdr-$(CONFIG_ARCH_MX3)	:= 0x80008000
 params_phys-$(CONFIG_ARCH_MX3)	:= 0x80000100
 initrd_phys-$(CONFIG_ARCH_MX3)	:= 0x80800000
+
+zreladdr-$(CONFIG_SOC_IMX6Q)	:= 0x10008000
+params_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10000100
+initrd_phys-$(CONFIG_SOC_IMX6Q)	:= 0x10800000

Do you really need params_phys and initrd_phys?

Quoted 2 lines

I added them to make IMX6Q look consistent with other soc in the file, and leave it to a global cleanup, if we decide to clean later.

I vote to skip params_phys and initrd_phys now. Every recent bootloader does not need them. As the i.MX6 is a new SoC, we have no reason to handle legacy bootloaders. When we want to to a global cleanup for these variables we already know that i.MX6 has no legacy bootloader problems.

BTW many variables have the name imx6q, I suppose the 'q' is for quad cpu. From the FSL website I know that there are other versions of the i.MX6 planned. Are these variables really imx6q specific? Otherwise please skip the 'q'.

I vote to skip params_phys and initrd_phys now. Every recent bootloader does not need them. As the i.MX6 is a new SoC, we have no reason to handle legacy bootloaders.

Quoted 3 lines · Sascha Hauer

I vote to skip params_phys and initrd_phys now. Every recent bootloader does not need them. As the i.MX6 is a new SoC, we have no reason to handle legacy bootloaders.

Can we stop this misunderstanding right now.

It's NOT about legacy boot loaders. It's about the bootp code which allows an initrd to be packaged up together with a zImage file as one single file.

That's used to be able to boot with an initrd on platforms which can only obtain one file from the boot media, and they specify where the parameters are expected to be (which can be solved by updating the code to use r2) and where to place the initrd image (which can't be solved as it would mean encoding memory information for every platform into the bootp code.)

An example of a current boot loader which requires this: Simtec's Able boot loader.

On Tue, Sep 06, 2011 at 05:58:36PM +0800, Shawn Guo wrote:

Quoted 16 lines

arch/arm/plat-mxc/include/mach/entry-macro.S +1 -1

index 066d464..341f800 100644
@@ -1,6 +1,6 @@
 /*
  *  Copyright (C) 2007 Lennert Buytenhek <[email protected]>
- *  Copyright 2004-2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ *  Copyright 2004-2011 Freescale Semiconductor, Inc. All Rights Reserved.
  */
 
 /*

@@ -11,6 +11,17 @@
 
 #include <mach/hardware.h>
 

arch/arm/plat-mxc/include/mach/entry-macro.S line 24

Quoted 11 lines

arch/arm/plat-mxc/include/mach/entry-macro.S +11 -0

+#ifdef CONFIG_ARM_GIC
+#include <asm/hardware/entry-macro-gic.S>
+
+	.macro	disable_fiq
+	.endm
+
+	.macro	arch_ret_to_user, tmp1, tmp2
+	.endm
+
+#else
+

hmm, this essentially means mx6 support cannot go into a kernel image for the other imx machines :-(

It adds a number of core drivers support for imx6q, including clock, General Power Controller (gpc), Multi Mode DDR Controller(mmdc) and System Reset Controller (src).

Signed-off-by Ranjani Vaidyanathan <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

---
 arch/arm/mach-imx/Kconfig       |   13 +
 arch/arm/mach-imx/Makefile      |    4 +
 arch/arm/mach-imx/clock-imx6q.c | 1990 +++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/gpc.c         |  110 +++
 arch/arm/mach-imx/mmdc.c        |   71 ++
 arch/arm/mach-imx/src.c         |   52 +
 6 files changed, 2240 insertions(+), 0 deletions(-)

Quoted 6 lines · On Tuesday 06 September 2011 17:58:37 Shawn Guo wrote:

It adds a number of core drivers support for imx6q, including clock, General Power Controller (gpc), Multi Mode DDR Controller(mmdc) and System Reset Controller (src).

Signed-off-by Ranjani Vaidyanathan <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Quoted 8 lines

---
 arch/arm/mach-imx/Kconfig       |   13 +
 arch/arm/mach-imx/Makefile      |    4 +
 arch/arm/mach-imx/clock-imx6q.c | 1990 +++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/gpc.c         |  110 +++
 arch/arm/mach-imx/mmdc.c        |   71 ++
 arch/arm/mach-imx/src.c         |   52 +
 6 files changed, 2240 insertions(+), 0 deletions(-)

This is unfortunately still a major problem.

I realize that we don't
yet have a good framework to do this with significantly less code, but adding a platform that is mostly consisting of stupid additions of clock descriptions that really should be in the device tree does not scale much longer.

We decided to let this still get in for prima2, which was also ugly in this regard but much simpler than imx6.

My feeling is that this time, we should wait for the common clock framework to get in and simplify this. I believe Thomas is now planning to do this, but I haven't followed what the current state is.

The other three drivers in this patch are basically ok, so you can definitely post them as a separate patch and perhaps get minor comments for those, similar to what I commented on the other patches.

For the clock-imx6q.c file, what I first want to hear from someone is how this is supposed to look like in the long run with device tree integration, and how far away from that we are.

Can you comment on how far we get without the clock driver with imx6? Is is basically useless, or is there a way we can merge the remaining imx6 code and other drivers but postpone the large clock driver?

Quoted 9 lines

Quoted 7 lines

 arch/arm/mach-imx/Kconfig       |   13 +
 arch/arm/mach-imx/Makefile      |    4 +
 arch/arm/mach-imx/clock-imx6q.c | 1990 +++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/gpc.c         |  110 +++
 arch/arm/mach-imx/mmdc.c        |   71 ++
 arch/arm/mach-imx/src.c         |   52 +
 6 files changed, 2240 insertions(+), 0 deletions(-)

This is unfortunately still a major problem.

It's so sad to still get this comment. Back to Linaro Connect on Cambridge, I believe I asked for your opinion on new SoC clock support without waiting for the clock framework. You said you do not have a strong position on this and would defer to others' judgement. Then I talked to Russell and Grant respectively, and they both agree that we should not be blocked by the clock framework. That's why I decided to start upstreaming imx6q.

Quoted 5 lines

I realize that we don't
yet have a good framework to do this with significantly less code, but adding a platform that is mostly consisting of stupid additions of clock descriptions that really should be in the device tree does not scale much longer.

I definitely agree this does not scale for long term. And I would immediately migrate it to clock framework once it gets ready and put the description into device tree when clock binding is ready. Before we get there, we need a way out. It's unreasonable for us to hold the new soc support for an unspecified time. It's been 20 months since we saw the common clock patches[1] from Jeremy, and we do not know yet how many months we still have to wait. Grant worked out the auxdata to remove the device tree dependency on clock framework. I think we should not get new soc support blocked by clock framework either.

Quoted 3 lines

We decided to let this still get in for prima2, which was also ugly in this regard but much simpler than imx6.

It's unfair to me that you reject imx6q clock code just because it's an implementation for a hardware complexer than prima2.

Quoted 4 lines

My feeling is that this time, we should wait for the common clock framework to get in and simplify this. I believe Thomas is now planning to do this, but I haven't followed what the current state is.

Sadly, if this is the position of entire arm-soc maintainer group, I think I have made a wrong decision to start upstreaming imx6q now.

Quoted 4 lines

The other three drivers in this patch are basically ok, so you can definitely post them as a separate patch and perhaps get minor comments for those, similar to what I commented on the other patches.

Quoted 8 lines

For the clock-imx6q.c file, what I first want to hear from someone is how this is supposed to look like in the long run with device tree integration, and how far away from that we are.

Can you comment on how far we get without the clock driver with imx6? Is is basically useless, or is there a way we can merge the remaining imx6 code and other drivers but postpone the large clock driver?

Unfortunately, clock is pretty fundamental for imx6q support. Without clock support, imx6q platform is useless. We have a real example here. Back to Dec. 2010, Sascha refused to take clock patch when Freescale was submitting imx50 platform support, because he thought the clock framework will get merged pretty soon. But we end up with the facts that clock framework is still up in the air and imx50 platform support on mainline is totally useless.

I have been tried very hard to reduce the LOC of clock-imx6q.c. It's a 5K LOC file in the Freescale internal tree. Now it's 2K LOC. I know it's still large enough for you to dislike it. But this is the clock that the hardware has. I'm afraid we can not do much to reduce the LOC significantly, unless we only implement the small portion other than the full clock tree, which is what I really hate to do.

Quoted 10 lines · On Wednesday 07 September 2011 14:05:03 Shawn Guo wrote:

Quoted 9 lines

Quoted 7 lines

 arch/arm/mach-imx/Kconfig       |   13 +
 arch/arm/mach-imx/Makefile      |    4 +
 arch/arm/mach-imx/clock-imx6q.c | 1990 +++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/gpc.c         |  110 +++
 arch/arm/mach-imx/mmdc.c        |   71 ++
 arch/arm/mach-imx/src.c         |   52 +
 6 files changed, 2240 insertions(+), 0 deletions(-)

This is unfortunately still a major problem.

Quoted 7 lines

It's so sad to still get this comment. Back to Linaro Connect on Cambridge, I believe I asked for your opinion on new SoC clock support without waiting for the clock framework. You said you do not have a strong position on this and would defer to others' judgement. Then I talked to Russell and Grant respectively, and they both agree that we should not be blocked by the clock framework. That's why I decided to start upstreaming imx6q.

I don't mind being overruled on this if Russell, Grant or others have a good feeling about the clock code going in like this.

I thought that the discussion we had in Cambridge was about migrating the existing i.mx code to device tree without waiting for the clock framework. If I misremember that and we had actually made a different decision back then, then please forgive my overreaction.

Quoted 16 lines

Quoted 5 lines

I realize that we don't
yet have a good framework to do this with significantly less code, but adding a platform that is mostly consisting of stupid additions of clock descriptions that really should be in the device tree does not scale much longer.

I definitely agree this does not scale for long term. And I would immediately migrate it to clock framework once it gets ready and put the description into device tree when clock binding is ready. Before we get there, we need a way out. It's unreasonable for us to hold the new soc support for an unspecified time. It's been 20 months since we saw the common clock patches[1] from Jeremy, and we do not know yet how many months we still have to wait. Grant worked out the auxdata to remove the device tree dependency on clock framework. I think we should not get new soc support blocked by clock framework either.

Quoted 5 lines

Quoted 3 lines

We decided to let this still get in for prima2, which was also ugly in this regard but much simpler than imx6.

It's unfair to me that you reject imx6q clock code just because it's an implementation for a hardware complexer than prima2.

We have to stop taking new platform clock code at some point and get all new platforms to use common code as much as possible. The unresolved question here is when that will be. My feeling is that prima2 was borderline and this is too far, but I may be pushing it here given that we are still waiting for the clock framework to actually get merged.

However, if there is no pressure at all, we might never see that framework.

Quoted 6 lines

Quoted 4 lines

My feeling is that this time, we should wait for the common clock framework to get in and simplify this. I believe Thomas is now planning to do this, but I haven't followed what the current state is.

Sadly, if this is the position of entire arm-soc maintainer group, I think I have made a wrong decision to start upstreaming imx6q now.

We haven't discussed it as a group, it's my own opinion.

Quoted 20 lines

Quoted 4 lines

The other three drivers in this patch are basically ok, so you can definitely post them as a separate patch and perhaps get minor comments for those, similar to what I commented on the other patches.

Quoted 8 lines

For the clock-imx6q.c file, what I first want to hear from someone is how this is supposed to look like in the long run with device tree integration, and how far away from that we are.

Can you comment on how far we get without the clock driver with imx6? Is is basically useless, or is there a way we can merge the remaining imx6 code and other drivers but postpone the large clock driver?

Unfortunately, clock is pretty fundamental for imx6q support. Without clock support, imx6q platform is useless. We have a real example here. Back to Dec. 2010, Sascha refused to take clock patch when Freescale was submitting imx50 platform support, because he thought the clock framework will get merged pretty soon. But we end up with the facts that clock framework is still up in the air and imx50 platform support on mainline is totally useless.

Quoted 6 lines

I have been tried very hard to reduce the LOC of clock-imx6q.c. It's a 5K LOC file in the Freescale internal tree. Now it's 2K LOC. I know it's still large enough for you to dislike it. But this is the clock that the hardware has. I'm afraid we can not do much to reduce the LOC significantly, unless we only implement the small portion other than the full clock tree, which is what I really hate to do.

I actually think that you have done a great job on the code and that it certainly looks better than a lot of the other implementations that we have in the tree.

Also, at least half of the code is now real driver code that we won't be able to reduce any further even with the clock framework. However, when I look at long sets of DEF_CLK and DEF_*MUX and _REGISTER_CLOCK, it feels like exactly the stuff that we should be moving into the device tree and have automatically parsed.

Arnd

Quoted 10 lines · Arnd Bergmann

Quoted 6 lines · On Wednesday 07 September 2011 14:05:03 Shawn Guo wrote:

Quoted 4 lines

My feeling is that this time, we should wait for the common clock framework to get in and simplify this. I believe Thomas is now planning to do this, but I haven't followed what the current state is.

Sadly, if this is the position of entire arm-soc maintainer group, I think I have made a wrong decision to start upstreaming imx6q now.

We haven't discussed it as a group, it's my own opinion.

Hi Thomas, Grant,

Could you please share your opinion here?

I really do not see the hope that clock framework and device tree binding could possibly catch v3.2 window, while I'm hoping that imx6q series can go into v3.2.

Can you please agree that we can let the imx6q clock code in and then migrate it to clock framework and device tree once they get ready?

Quoted 14 lines · Shawn Guo

Quoted 10 lines · Arnd Bergmann

Quoted 6 lines · On Wednesday 07 September 2011 14:05:03 Shawn Guo wrote:

Quoted 4 lines

My feeling is that this time, we should wait for the common clock framework to get in and simplify this. I believe Thomas is now planning to do this, but I haven't followed what the current state is.

Sadly, if this is the position of entire arm-soc maintainer group, I think I have made a wrong decision to start upstreaming imx6q now.

We haven't discussed it as a group, it's my own opinion.

Hi Thomas, Grant,

Quoted 8 lines

Could you please share your opinion here?

I really do not see the hope that clock framework and device tree binding could possibly catch v3.2 window, while I'm hoping that imx6q series can go into v3.2.

Can you please agree that we can let the imx6q clock code in and then migrate it to clock framework and device tree once they get ready?

I've not looked very deeply at this patch, but I completely agree that we cannot block new platforms on infrastructure that isn't remotely mergable at this point in time.

However, imx6 is a new platform. There isn't any non-DT board support code to continue to support. At the very least, the configurable parameters, like what is passed into mx6q_clocks_init() should be obtained from the device tree (maybe it already does this though, I haven't looked that closely).

In general, I say merge it.

Quoted 34 lines · On Monday 12 September 2011 13:40:33 Grant Likely wrote:

Quoted 14 lines · Shawn Guo

Quoted 10 lines · Arnd Bergmann

Quoted 6 lines · On Wednesday 07 September 2011 14:05:03 Shawn Guo wrote:

Quoted 4 lines

My feeling is that this time, we should wait for the common clock framework to get in and simplify this. I believe Thomas is now planning to do this, but I haven't followed what the current state is.

Sadly, if this is the position of entire arm-soc maintainer group, I think I have made a wrong decision to start upstreaming imx6q now.

We haven't discussed it as a group, it's my own opinion.

Hi Thomas, Grant,

Quoted 8 lines

Could you please share your opinion here?

I really do not see the hope that clock framework and device tree binding could possibly catch v3.2 window, while I'm hoping that imx6q series can go into v3.2.

Can you please agree that we can let the imx6q clock code in and then migrate it to clock framework and device tree once they get ready?

I've not looked very deeply at this patch, but I completely agree that we cannot block new platforms on infrastructure that isn't remotely mergable at this point in time.

However, imx6 is a new platform. There isn't any non-DT board support code to continue to support. At the very least, the configurable parameters, like what is passed into mx6q_clocks_init() should be obtained from the device tree (maybe it already does this though, I haven't looked that closely).

Quoted 1 line

In general, I say merge it.

Ok, thanks for taking a look. Do you believe that the clock binding is any closer to being finalized than the actual code implementing it? I think

it would be very helpful to at least put all the clock related settings into the device tree in a way that is going to be stable, even if the code is still in flux.

Moreover, if we have a binding document, we can start implementing code for one platform and then generalize it later.

Quoted 14 lines · Shawn Guo

Quoted 10 lines · Arnd Bergmann

Quoted 6 lines · On Wednesday 07 September 2011 14:05:03 Shawn Guo wrote:

Quoted 4 lines

My feeling is that this time, we should wait for the common clock framework to get in and simplify this. I believe Thomas is now planning to do this, but I haven't followed what the current state is.

Sadly, if this is the position of entire arm-soc maintainer group, I think I have made a wrong decision to start upstreaming imx6q now.

We haven't discussed it as a group, it's my own opinion.

Hi Thomas, Grant,

Quoted 8 lines

Could you please share your opinion here?

I really do not see the hope that clock framework and device tree binding could possibly catch v3.2 window, while I'm hoping that imx6q series can go into v3.2.

Can you please agree that we can let the imx6q clock code in and then migrate it to clock framework and device tree once they get ready?

I've not looked very deeply at this patch, but I completely agree that we cannot block new platforms on infrastructure that isn't remotely mergable at this point in time.

However, imx6 is a new platform. There isn't any non-DT board support code to continue to support. At the very least, the configurable parameters, like what is passed into mx6q_clocks_init() should be obtained from the device tree (maybe it already does this though, I haven't looked that closely).

In general, I say merge it.

Hi Arnd,

Quoted 16 lines · Arnd Bergmann

Quoted 6 lines · On Tuesday 06 September 2011 17:58:37 Shawn Guo wrote:

It adds a number of core drivers support for imx6q, including clock, General Power Controller (gpc), Multi Mode DDR Controller(mmdc) and System Reset Controller (src).

Signed-off-by Ranjani Vaidyanathan <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Quoted 8 lines

---

?arch/arm/mach-imx/Kconfig ? ? ? | ? 13 +
?arch/arm/mach-imx/Makefile ? ? ?| ? ?4 +
?arch/arm/mach-imx/clock-imx6q.c | 1990 +++++++++++++++++++++++++++++++++++++++
?arch/arm/mach-imx/gpc.c ? ? ? ? | ?110 +++
?arch/arm/mach-imx/mmdc.c ? ? ? ?| ? 71 ++
?arch/arm/mach-imx/src.c ? ? ? ? | ? 52 +

?6 files changed, 2240 insertions(+), 0 deletions(-)

Quoted 1 line

This is unfortunately still a major problem.

It's so sad to still get this comment. ?Back to Linaro Connect on Cambridge, I believe I asked for your opinion on new SoC clock support without waiting for the clock framework. ?You said you do not have a strong position on this and would defer to others' judgement. ?Then I talked to Russell and Grant respectively, and they both agree that we should not be blocked by the clock framework. ?That's why I decided to start upstreaming imx6q.

Quoted 5 lines

I realize that we don't
yet have a good framework to do this with significantly less code, but adding a platform that is mostly consisting of stupid additions of clock descriptions that really should be in the device tree does not scale much longer.

I definitely agree this does not scale for long term. ?And I would immediately migrate it to clock framework once it gets ready and put the description into device tree when clock binding is ready. ?Before we get there, we need a way out. ?It's unreasonable for us to hold the new soc support for an unspecified time. ?It's been 20 months since we saw the common clock patches[1] from Jeremy, and we do not know yet how many months we still have to wait. ?Grant worked out the auxdata to remove the device tree dependency on clock framework. ?I think we should not get new soc support blocked by clock framework either.

Quoted 3 lines

We decided to let this still get in for prima2, which was also ugly in this regard but much simpler than imx6.

It's unfair to me that you reject imx6q clock code just because it's an implementation for a hardware complexer than prima2.

Quoted 5 lines

My feeling is that this time, we should wait for the common clock framework to get in and simplify this. I believe Thomas is now planning to do this, but I haven't followed what the current state is.

Sadly, if this is the position of entire arm-soc maintainer group, I think I have made a wrong decision to start upstreaming imx6q now.

Quoted 4 lines

The other three drivers in this patch are basically ok, so you can definitely post them as a separate patch and perhaps get minor comments for those, similar to what I commented on the other patches.

Quoted 8 lines

For the clock-imx6q.c file, what I first want to hear from someone is how this is supposed to look like in the long run with device tree integration, and how far away from that we are.

Can you comment on how far we get without the clock driver with imx6? Is is basically useless, or is there a way we can merge the remaining imx6 code and other drivers but postpone the large clock driver?

Unfortunately, clock is pretty fundamental for imx6q support. ?Without clock support, imx6q platform is useless. ?We have a real example here. Back to Dec. 2010, Sascha refused to take clock patch when Freescale was submitting imx50 platform support, because he thought the clock framework will get merged pretty soon. ?But we end up with the facts that clock framework is still up in the air and imx50 platform support on mainline is totally useless.

I have been tried very hard to reduce the LOC of clock-imx6q.c. ?It's a 5K LOC file in the Freescale internal tree. ?Now it's 2K LOC. ?I know it's still large enough for you to dislike it. ?But this is the clock that the hardware has. ?I'm afraid we can not do much to reduce the LOC significantly, unless we only implement the small portion other than the full clock tree, which is what I really hate to do.

Regards,
Shawn

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-January/007238.html

2011/9/7 Shawn Guo <[email protected]>:

Quoted 45 lines

Hi Arnd,

Quoted 16 lines · Arnd Bergmann

Quoted 6 lines · On Tuesday 06 September 2011 17:58:37 Shawn Guo wrote:

It adds a number of core drivers support for imx6q, including clock, General Power Controller (gpc), Multi Mode DDR Controller(mmdc) and System Reset Controller (src).

Signed-off-by Ranjani Vaidyanathan <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Quoted 8 lines

---

?arch/arm/mach-imx/Kconfig ? ? ? | ? 13 +
?arch/arm/mach-imx/Makefile ? ? ?| ? ?4 +
?arch/arm/mach-imx/clock-imx6q.c | 1990 +++++++++++++++++++++++++++++++++++++++
?arch/arm/mach-imx/gpc.c ? ? ? ? | ?110 +++
?arch/arm/mach-imx/mmdc.c ? ? ? ?| ? 71 ++
?arch/arm/mach-imx/src.c ? ? ? ? | ? 52 +

?6 files changed, 2240 insertions(+), 0 deletions(-)

Quoted 1 line

This is unfortunately still a major problem.

It's so sad to still get this comment. ?Back to Linaro Connect on Cambridge, I believe I asked for your opinion on new SoC clock support without waiting for the clock framework. ?You said you do not have a strong position on this and would defer to others' judgement. ?Then I talked to Russell and Grant respectively, and they both agree that we should not be blocked by the clock framework. ?That's why I decided to start upstreaming imx6q.

Quoted 5 lines

I realize that we don't
yet have a good framework to do this with significantly less code, but adding a platform that is mostly consisting of stupid additions of clock descriptions that really should be in the device tree does not scale much longer.

I definitely agree this does not scale for long term. ?And I would immediately migrate it to clock framework once it gets ready and put the description into device tree when clock binding is ready. ?Before we get there, we need a way out. ?It's unreasonable for us to hold the new soc support for an unspecified time. ?It's been 20 months since we saw the common clock patches[1] from Jeremy, and we do not know yet how many months we still have to wait. ?Grant worked out the auxdata to remove the device tree dependency on clock framework. ?I think we should not get new soc support blocked by clock framework either.

Quoted 5 lines

Quoted 3 lines

We decided to let this still get in for prima2, which was also ugly in this regard but much simpler than imx6.

It's unfair to me that you reject imx6q clock code just because it's an implementation for a hardware complexer than prima2.

i understand your feeling.

actually i am also waiting for the common clock framework to finish the whole prima2 clock tree driver. now prima2 only includes a little part of clock trees, actually if i list all of them, the file will be large too. And codes are ugly too.

auxdata is really a temp solution, it really brings many details to kernel, which should not be in kernel at all.

Quoted 46 lines

2011/9/7 Shawn Guo <[email protected]>:

Quoted 45 lines

Hi Arnd,

Quoted 16 lines · Arnd Bergmann

Quoted 6 lines · On Tuesday 06 September 2011 17:58:37 Shawn Guo wrote:

It adds a number of core drivers support for imx6q, including clock, General Power Controller (gpc), Multi Mode DDR Controller(mmdc) and System Reset Controller (src).

Signed-off-by Ranjani Vaidyanathan <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Quoted 8 lines

---

?arch/arm/mach-imx/Kconfig ? ? ? | ? 13 +
?arch/arm/mach-imx/Makefile ? ? ?| ? ?4 +
?arch/arm/mach-imx/clock-imx6q.c | 1990 +++++++++++++++++++++++++++++++++++++++
?arch/arm/mach-imx/gpc.c ? ? ? ? | ?110 +++
?arch/arm/mach-imx/mmdc.c ? ? ? ?| ? 71 ++
?arch/arm/mach-imx/src.c ? ? ? ? | ? 52 +

?6 files changed, 2240 insertions(+), 0 deletions(-)

Quoted 1 line

This is unfortunately still a major problem.

It's so sad to still get this comment. ?Back to Linaro Connect on Cambridge, I believe I asked for your opinion on new SoC clock support without waiting for the clock framework. ?You said you do not have a strong position on this and would defer to others' judgement. ?Then I talked to Russell and Grant respectively, and they both agree that we should not be blocked by the clock framework. ?That's why I decided to start upstreaming imx6q.

Quoted 5 lines

I realize that we don't
yet have a good framework to do this with significantly less code, but adding a platform that is mostly consisting of stupid additions of clock descriptions that really should be in the device tree does not scale much longer.

I definitely agree this does not scale for long term. ?And I would immediately migrate it to clock framework once it gets ready and put the description into device tree when clock binding is ready. ?Before we get there, we need a way out. ?It's unreasonable for us to hold the new soc support for an unspecified time. ?It's been 20 months since we saw the common clock patches[1] from Jeremy, and we do not know yet how many months we still have to wait. ?Grant worked out the auxdata to remove the device tree dependency on clock framework. ?I think we should not get new soc support blocked by clock framework either.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

We decided to let this still get in for prima2, which was also ugly in this regard but much simpler than imx6.

It's unfair to me that you reject imx6q clock code just because it's an implementation for a hardware complexer than prima2.

i understand your feeling.

No, you do not :) ?With the talking at Cambridge, I thought I'm allowed to add new platform support without being blocked by clock framework. That's why I have been worked very hard for 3 weeks to come up with this patch series. ?Now I'm getting a "no", which really frustrates me.

Quoted 5 lines

actually i am also waiting for the common clock framework to finish the whole prima2 clock tree driver. now prima2 only includes a little part of clock trees, actually if i list all of them, the file will be large too. And codes are ugly too.

I did not hear "ugly" from Arnd on imx6q-clock.c. ?Instead, he said the description of the clocks and the tree should be migrated to clock frame and device tree clock bindings, which unfortunately have not been available yet.

Quoted 4 lines

auxdata is really a temp solution, it really brings many details to kernel, which should not be in kernel at all.

The auxdata was originally designed to be a temp solution. ?But we will see if it's really temp, considering it could also be used to carry platform callbacks and attach device id. ?There are some other cases beside clock lookup that we have not been able to sort out just by device tree and will probably have to use auxdata as well.

--
Regards,
Shawn

Quoted 3 lines · Barry Song

auxdata is really a temp solution, it really brings many details to kernel, which should not be in kernel at all.

The auxdata was originally designed to be a temp solution. But we will see if it's really temp, considering it could also be used to carry platform callbacks and attach device id. There are some other cases beside clock lookup that we have not been able to sort out just by device tree and will probably have to use auxdata as well.

It adds a number of core drivers support for imx6q, including clock, General Power Controller (gpc), Multi Mode DDR Controller(mmdc) and System Reset Controller (src).

Signed-off-by Ranjani Vaidyanathan <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

---

arch/arm/mach-imx/src.c new file +42 -0

new file mode 100644
index 0000000..95fdd65
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <asm/unified.h>
+
+#define SRC_SCR				0x000
+#define SRC_GPR1			0x020
+#define BP_SRC_SCR_CORE1_RST		14
+#define BP_SRC_SCR_CORE1_ENABLE		22
+
+static void __iomem *src_base;
+
+void imx_enable_cpu(int cpu, bool enable)
+{
+	u32 mask, val;
+
+	mask = 1 << (BP_SRC_SCR_CORE1_ENABLE + cpu - 1);
+	val = __raw_readl(src_base + SRC_SCR);
+	val = enable ? val | mask : val & ~mask;
+	__raw_writel(val, src_base + SRC_SCR);
+}
+
+void imx_set_cpu_jump(int cpu, void *jump_addr)
+{
+	__raw_writel(BSYM(virt_to_phys(jump_addr)),
+		     src_base + SRC_GPR1 + cpu * 8);
+}
+
+static int __init imx_src_init(void)

Quoted 62 lines · Shawn Guo

It adds a number of core drivers support for imx6q, including clock, General Power Controller (gpc), Multi Mode DDR Controller(mmdc) and System Reset Controller (src).

Signed-off-by Ranjani Vaidyanathan <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

---

arch/arm/mach-imx/src.c new file +49 -0

new file mode 100644
index 0000000..95fdd65
@@ -0,0 +1,52 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <asm/unified.h>
+
+#define SRC_SCR				0x000
+#define SRC_GPR1			0x020
+#define BP_SRC_SCR_CORE1_RST		14
+#define BP_SRC_SCR_CORE1_ENABLE		22
+
+static void __iomem *src_base;
+
+void imx_enable_cpu(int cpu, bool enable)
+{
+	u32 mask, val;
+
+	mask = 1 << (BP_SRC_SCR_CORE1_ENABLE + cpu - 1);
+	val = __raw_readl(src_base + SRC_SCR);
+	val = enable ? val | mask : val & ~mask;
+	__raw_writel(val, src_base + SRC_SCR);
+}
+
+void imx_set_cpu_jump(int cpu, void *jump_addr)
+{
+	__raw_writel(BSYM(virt_to_phys(jump_addr)),
+		     src_base + SRC_GPR1 + cpu * 8);
+}
+
+static int __init imx_src_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-src");
+	src_base = of_iomap(np, 0);
+	WARN_ON(!src_base);
+

arch/arm/mach-imx/src.c line 52

Quoted 3 lines

arch/arm/mach-imx/src.c new file +3 -0

+	return 0;
+}
+early_initcall(imx_src_init);

What I'm concerned about is that we carefully removed all assumptions about which SoC the code runs on in the past. Now with this patchset many of them come back. Here we have a initcall without any check whether we really run on i.MX6.

Above we have a imx_enable_cpu function
but this is really a imx6 specific function.

Nevertheless it is called
from generic code in arch/arm/mach-imx/platsmp.c.

We've been there before and it was hard to remove all the implicit assumptions on which SoC we are on. Please do not reintroduce it.

Quoted 17 lines · Sascha Hauer

arch/arm/mach-imx/src.c line 52

Quoted 11 lines · Shawn Guo

arch/arm/mach-imx/src.c new file +11 -0

+static int __init imx_src_init(void)
+{
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-src");
+	src_base = of_iomap(np, 0);
+	WARN_ON(!src_base);
+
+	return 0;
+}
+early_initcall(imx_src_init);

What I'm concerned about is that we carefully removed all assumptions about which SoC the code runs on in the past. Now with this patchset many of them come back. Here we have a initcall without any check whether we really run on i.MX6.

The "check" has been done on Kconfig level as below.

config SOC_IMX6Q
bool "i.MX6 Quad support"
select HAVE_IMX_SRC

obj-$(CONFIG_HAVE_IMX_SRC) += src.o

Quoted 19 lines · Shawn Guo

Quoted 17 lines · Sascha Hauer

arch/arm/mach-imx/src.c line 52

Quoted 11 lines · Shawn Guo

arch/arm/mach-imx/src.c new file +11 -0

+static int __init imx_src_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-src");
+ src_base = of_iomap(np, 0);
+ WARN_ON(!src_base);
+
+ return 0;
+}
+early_initcall(imx_src_init);

What I'm concerned about is that we carefully removed all assumptions about which SoC the code runs on in the past. Now with this patchset many of them come back. Here we have a initcall without any check whether we really run on i.MX6.

Quoted 7 lines

The "check" has been done on Kconfig level as below.

config SOC_IMX6Q
bool "i.MX6 Quad support"
select HAVE_IMX_SRC

obj-$(CONFIG_HAVE_IMX_SRC) += src.o

Think multi-SoC-kernel that has SOC_IMX6Q and say SOC_IMX51.

Quoted 20 lines · Uwe Kleine-K?nig

Quoted 19 lines · Shawn Guo

Quoted 17 lines · Sascha Hauer

arch/arm/mach-imx/src.c line 52

Quoted 11 lines · Shawn Guo

arch/arm/mach-imx/src.c new file +11 -0

+static int __init imx_src_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-src");
+ src_base = of_iomap(np, 0);
+ WARN_ON(!src_base);
+
+ return 0;
+}
+early_initcall(imx_src_init);

What I'm concerned about is that we carefully removed all assumptions about which SoC the code runs on in the past. Now with this patchset many of them come back. Here we have a initcall without any check whether we really run on i.MX6.

Quoted 8 lines

Quoted 7 lines

The "check" has been done on Kconfig level as below.

config SOC_IMX6Q
bool "i.MX6 Quad support"
select HAVE_IMX_SRC

obj-$(CONFIG_HAVE_IMX_SRC) += src.o

Think multi-SoC-kernel that has SOC_IMX6Q and say SOC_IMX51.

I think the code is almost ok, since it's only active when there is a "fsl,imx6q-src" device node. However, the WARN_ON must be removed if we want this to work well on a multi-soc kernel.

The more important point is to ensure that src_base is not being used on other SoCs, but that's probably covered as well.

Quoted 21 lines · Arnd Bergmann

Quoted 20 lines · Uwe Kleine-K?nig

Quoted 19 lines · Shawn Guo

Quoted 17 lines · Sascha Hauer

arch/arm/mach-imx/src.c line 52

Quoted 11 lines · Shawn Guo

arch/arm/mach-imx/src.c new file +11 -0

+static int __init imx_src_init(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-src");
+ src_base = of_iomap(np, 0);
+ WARN_ON(!src_base);
+
+ return 0;
+}
+early_initcall(imx_src_init);

What I'm concerned about is that we carefully removed all assumptions about which SoC the code runs on in the past. Now with this patchset many of them come back. Here we have a initcall without any check whether we really run on i.MX6.

Quoted 9 lines

Quoted 8 lines

Quoted 7 lines

The "check" has been done on Kconfig level as below.

config SOC_IMX6Q
bool "i.MX6 Quad support"
select HAVE_IMX_SRC

obj-$(CONFIG_HAVE_IMX_SRC) += src.o

Think multi-SoC-kernel that has SOC_IMX6Q and say SOC_IMX51.

Aha, I did miss the point. I was misled by "Now with this patchset many of them come back". SRC is the only one being called by initcall. MMDC is a real platform driver. GPC and Clock init are called by specific platform code.

Quoted 7 lines

I think the code is almost ok, since it's only active when there is a "fsl,imx6q-src" device node. However, the WARN_ON must be removed if we want this to work well on a multi-soc kernel.

The more important point is to ensure that src_base is not being used on other SoCs, but that's probably covered as well.

Thanks, Arnd.

It adds smp and cpu hotplug support for imx6q.

arch/arm/mach-imx/localtimer.c new file +16 -0

+static u32 twd_saved_regs[4];
+static int twd_irq;
+
+/*
+ * Resuming from ARM Dormant/Shutdown mode, the boot procedure will
+ * re-setup local timer for secondary cores.  For primary core, it
+ * has to take care of itself with the following pair of functions
+ * during suspend/resume.
+ */
+void imx_local_timer_pre_suspend(void)
+{
+	twd_saved_regs[0] = __raw_readl(twd_base + TWD_TIMER_LOAD);
+	twd_saved_regs[1] = __raw_readl(twd_base + TWD_TIMER_COUNTER);
+	twd_saved_regs[2] = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+	twd_saved_regs[3] = __raw_readl(twd_base + TWD_TIMER_INTSTAT);
+}

arch/arm/mach-imx/platsmp.c new file +7 -0

+static struct map_desc scu_io_desc __initdata = {
+	.virtual	= IMX_SCU_VIRT_BASE,
+	.pfn		= 0, /* run-time */
+	.length		= SZ_4K,
+	.type		= MT_DEVICE,
+};
+

arch/arm/mach-imx/platsmp.c new file +15 -0

+/*
+ * Initialise the CPU possible map early - this describes the CPUs
+ * which may be present or become present in the system.
+ */
+void __init smp_init_cpus(void)
+{
+	int i, ncores;
+
+	ncores = scu_get_core_count(scu_base);
+
+	for (i = 0; i < ncores; i++)
+		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
+}

Quoted 21 lines · On Tuesday 06 September 2011 17:58:38 Shawn Guo wrote:

It adds smp and cpu hotplug support for imx6q.

arch/arm/mach-imx/localtimer.c new file +20 -0

+static u32 twd_saved_regs[4];
+static int twd_irq;
+
+/*
+ * Resuming from ARM Dormant/Shutdown mode, the boot procedure will
+ * re-setup local timer for secondary cores.  For primary core, it
+ * has to take care of itself with the following pair of functions
+ * during suspend/resume.
+ */
+void imx_local_timer_pre_suspend(void)
+{
+	twd_saved_regs[0] = __raw_readl(twd_base + TWD_TIMER_LOAD);
+	twd_saved_regs[1] = __raw_readl(twd_base + TWD_TIMER_COUNTER);
+	twd_saved_regs[2] = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+	twd_saved_regs[3] = __raw_readl(twd_base + TWD_TIMER_INTSTAT);
+}
+
+void imx_local_timer_post_resume(void)
+{
+	__raw_writel(twd_saved_regs[0], twd_base + TWD_TIMER_LOAD);

arch/arm/mach-imx/localtimer.c line 45

Quoted 6 lines

arch/arm/mach-imx/localtimer.c new file +6 -0

+	__raw_writel(twd_saved_regs[1], twd_base + TWD_TIMER_COUNTER);
+	__raw_writel(twd_saved_regs[2], twd_base + TWD_TIMER_CONTROL);
+	__raw_writel(twd_saved_regs[3], twd_base + TWD_TIMER_INTSTAT);
+
+	gic_enable_ppi(twd_irq);
+}

readl_relaxed()?

arch/arm/mach-imx/platsmp.c line 25

Quoted 5 lines

arch/arm/mach-imx/platsmp.c new file +5 -0

+extern void v7_secondary_startup(void);
+
+#define IMX_SCU_VIRT_BASE	0xf4a00000
+
+static void __iomem *scu_base = ((void __iomem *)(IMX_SCU_VIRT_BASE));

It's a little bit silly to have a variable for the base and then initialize it statically. Not sure what the best solution is here.

Quoted 13 lines

arch/arm/mach-imx/platsmp.c new file +13 -0

+static struct map_desc scu_io_desc __initdata = {
+	.virtual	= IMX_SCU_VIRT_BASE,
+	.pfn		= 0, /* run-time */
+	.length		= SZ_4K,
+	.type		= MT_DEVICE,
+};
+
+void __init imx_scu_map_io(void)
+{
+	unsigned long base;
+
+	/* Get SCU base */
+	asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));

arch/arm/mach-imx/platsmp.c line 43

Quoted 4 lines

arch/arm/mach-imx/platsmp.c new file +4 -0

+
+	scu_io_desc.pfn = __phys_to_pfn(base);
+	iotable_init(&scu_io_desc, 1);
+}

Maybe we can simply define a platform-independent where the SCU gets mapped? That would get rid of most of the platform specific SCU code, at least for those platforms that can reliably read the scu base.

Quoted 15 lines

arch/arm/mach-imx/platsmp.c new file +15 -0

+/*
+ * Initialise the CPU possible map early - this describes the CPUs
+ * which may be present or become present in the system.
+ */
+void __init smp_init_cpus(void)
+{
+	int i, ncores;
+
+	ncores = scu_get_core_count(scu_base);
+
+	for (i = 0; i < ncores; i++)
+		set_cpu_possible(i, true);
+
+	set_smp_cross_call(gic_raise_softirq);
+}

arch/arm/mach-imx/platsmp.c line 86

Quoted 10 lines

arch/arm/mach-imx/platsmp.c new file +10 -0

+
+void imx_smp_prepare(void)
+{
+	scu_enable(scu_base);
+}
+
+void __init platform_smp_prepare_cpus(unsigned int max_cpus)
+{
+	imx_smp_prepare();
+}

Then these functions could also be moved into the smp_scu file as generic helpers that can be used by all similar platforms.

Quoted 22 lines · Arnd Bergmann

Quoted 21 lines · On Tuesday 06 September 2011 17:58:38 Shawn Guo wrote:

It adds smp and cpu hotplug support for imx6q.

arch/arm/mach-imx/localtimer.c new file +20 -0

+static u32 twd_saved_regs[4];
+static int twd_irq;
+
+/*
+ * Resuming from ARM Dormant/Shutdown mode, the boot procedure will
+ * re-setup local timer for secondary cores. ?For primary core, it
+ * has to take care of itself with the following pair of functions
+ * during suspend/resume.
+ */
+void imx_local_timer_pre_suspend(void)
+{
+ ? twd_saved_regs[0] = __raw_readl(twd_base + TWD_TIMER_LOAD);
+ ? twd_saved_regs[1] = __raw_readl(twd_base + TWD_TIMER_COUNTER);
+ ? twd_saved_regs[2] = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+ ? twd_saved_regs[3] = __raw_readl(twd_base + TWD_TIMER_INTSTAT);
+}
+
+void imx_local_timer_post_resume(void)
+{
+ ? __raw_writel(twd_saved_regs[0], twd_base + TWD_TIMER_LOAD);

Quoted 9 lines

arch/arm/mach-imx/hotplug.c line 20

Quoted 6 lines

+ ? __raw_writel(twd_saved_regs[1], twd_base + TWD_TIMER_COUNTER);
+ ? __raw_writel(twd_saved_regs[2], twd_base + TWD_TIMER_CONTROL);
+ ? __raw_writel(twd_saved_regs[3], twd_base + TWD_TIMER_INTSTAT);

arch/arm/mach-imx/hotplug.c new file +3 -0

+
+ ? gic_enable_ppi(twd_irq);
+}

readl_relaxed()?

Ok. ?You get the best judgement on this.

Quoted 32 lines · Shawn Guo

Quoted 31 lines · Arnd Bergmann

Quoted 17 lines · On Tuesday 06 September 2011 17:58:38 Shawn Guo wrote:

It adds smp and cpu hotplug support for imx6q.

arch/arm/mach-imx/localtimer.c new file +16 -0

+static u32 twd_saved_regs[4];
+static int twd_irq;
+
+/*
+ * Resuming from ARM Dormant/Shutdown mode, the boot procedure will
+ * re-setup local timer for secondary cores. ?For primary core, it
+ * has to take care of itself with the following pair of functions
+ * during suspend/resume.
+ */
+void imx_local_timer_pre_suspend(void)
+{
+ ? twd_saved_regs[0] = __raw_readl(twd_base + TWD_TIMER_LOAD);
+ ? twd_saved_regs[1] = __raw_readl(twd_base + TWD_TIMER_COUNTER);
+ ? twd_saved_regs[2] = __raw_readl(twd_base + TWD_TIMER_CONTROL);
+ ? twd_saved_regs[3] = __raw_readl(twd_base + TWD_TIMER_INTSTAT);
+}

arch/arm/mach-imx/localtimer.c line 45

Quoted 10 lines

arch/arm/mach-imx/localtimer.c new file +10 -0

+
+void imx_local_timer_post_resume(void)
+{
+ ? __raw_writel(twd_saved_regs[0], twd_base + TWD_TIMER_LOAD);
+ ? __raw_writel(twd_saved_regs[1], twd_base + TWD_TIMER_COUNTER);
+ ? __raw_writel(twd_saved_regs[2], twd_base + TWD_TIMER_CONTROL);
+ ? __raw_writel(twd_saved_regs[3], twd_base + TWD_TIMER_INTSTAT);
+
+ ? gic_enable_ppi(twd_irq);
+}

readl_relaxed()?

Quoted 2 lines

Ok. ?You get the best judgement on this.

You don't have to save local timer registers any more. The local timer is always re-configued and this is already handled in common kernel.

You can drop above change and test your patches. I am sure they will still work.

arch/arm/mach-imx/Kconfig +3 -0

index 13e0301..3364b59 100644
@@ -624,3 +624,16 @@ config MACH_VPR200
 	  configurations for the board and its peripherals.
 
 endif
+
+if ARCH_MX6
+comment "i.MX6 machines:"

Quoted 18 lines · On Tuesday 06 September 2011 17:58:39 Shawn Guo wrote:

arch/arm/mach-imx/Kconfig +10 -0

index 13e0301..3364b59 100644
@@ -624,3 +624,16 @@ config MACH_VPR200
 	  configurations for the board and its peripherals.
 
 endif
+
+if ARCH_MX6
+comment "i.MX6 machines:"
+
+config MACH_IMX6Q
+	bool "Support i.MX6 Quad platforms from device tree"
+	select SOC_IMX6Q
+	select USE_OF
+	help
+	  Include support for Freescale i.MX6 Quad based platforms

arch/arm/mach-imx/Kconfig config MACH_VPR200 · line 639

Quoted 3 lines

arch/arm/mach-imx/Kconfig +3 -0

+	  using the device tree for discovery
+
+endif

As we have done on zynq and prima2, I would suggest not to add multiple machines types at all. You already have the intialization in a generic imx6q file, it would be logical to get rid of the configuration entry as well.

Quoted 20 lines · Arnd Bergmann

Quoted 18 lines · On Tuesday 06 September 2011 17:58:39 Shawn Guo wrote:

arch/arm/mach-imx/Kconfig +10 -0

index 13e0301..3364b59 100644
@@ -624,3 +624,16 @@ config MACH_VPR200
      configurations for the board and its peripherals.
 
 endif
+
+if ARCH_MX6
+comment "i.MX6 machines:"
+
+config MACH_IMX6Q
+   bool "Support i.MX6 Quad platforms from device tree"
+   select SOC_IMX6Q
+   select USE_OF
+   help
+     Include support for Freescale i.MX6 Quad based platforms

Quoted 9 lines

arch/arm/mach-imx/Kconfig config MACH_VPR200 · line 639

Quoted 3 lines

arch/arm/mach-imx/Kconfig +3 -0

+     using the device tree for discovery
+
+endif

As we have done on zynq and prima2, I would suggest not to add multiple machines types at all. You already have the intialization in a generic imx6q file, it would be logical to get rid of the configuration entry as well.

This MACH_IMX6Q was added to make the IMX6Q Kconfig hierarchy look consistent with other SoCs in arch/arm/mach-imx/Kconfig. If you do not like it, I can kill it.

It adds suspend/resume support for imx6q.

Signed-off-by Anson Huang <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

(quoted diff) +6 -0

+
+static int imx6q_pm_enter(suspend_state_t state)
+{
+ ? ? ? switch (state) {
+ ? ? ? case PM_SUSPEND_MEM:
+ ? ? ? ? ? ? ? imx_local_timer_pre_suspend();