[RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X

[RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X

[Richard Zhao]

Remove legacy support of ARCH_MX5X. Move to SOC_SOC_IMX5X.

My understanding is ARCH_MX5 selects Kconfig in arch/arm/mach-mx5,
and every board can be selected/unselected, and SOC_XXX be selected
by the board config. MACH_XXXX/SOC_XXXX then select those HAVE_XXXX.

If everyone is happty with that, I'd like to clean up ARCH_MX3X too.

Signed-off-by: Richard Zhao <richard.zhao@freescale.com>

diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index f065a0d..518a39e 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -1,14 +1,4 @@
 if ARCH_MX5
-# ARCH_MX51 and ARCH_MX50 are left for compatibility
-
-config ARCH_MX50
-	bool
-
-config ARCH_MX51
-	bool
-
-config ARCH_MX53
-	bool
 
 config SOC_IMX50
 	bool
@@ -16,7 +6,6 @@ config SOC_IMX50
 	select ARCH_MXC_IOMUX_V3
 	select ARCH_MXC_AUDMUX_V2
 	select ARCH_HAS_CPUFREQ
-	select ARCH_MX50
 
 config	SOC_IMX51
 	bool
@@ -24,13 +13,11 @@ config	SOC_IMX51
 	select ARCH_MXC_IOMUX_V3
 	select ARCH_MXC_AUDMUX_V2
 	select ARCH_HAS_CPUFREQ
-	select ARCH_MX51
 
 config	SOC_IMX53
 	bool
 	select MXC_TZIC
 	select ARCH_MXC_IOMUX_V3
-	select ARCH_MX53
 
 comment "MX5 platforms:"
 
diff --git a/arch/arm/mach-mx5/Makefile.boot b/arch/arm/mach-mx5/Makefile.boot
index e928be1..cdc70b3 100644
--- a/arch/arm/mach-mx5/Makefile.boot
+++ b/arch/arm/mach-mx5/Makefile.boot
@@ -1,9 +1,9 @@
-   zreladdr-$(CONFIG_ARCH_MX50)	:= 0x70008000
-params_phys-$(CONFIG_ARCH_MX50)	:= 0x70000100
-initrd_phys-$(CONFIG_ARCH_MX50)	:= 0x70800000
-   zreladdr-$(CONFIG_ARCH_MX51)	:= 0x90008000
-params_phys-$(CONFIG_ARCH_MX51)	:= 0x90000100
-initrd_phys-$(CONFIG_ARCH_MX51)	:= 0x90800000
-   zreladdr-$(CONFIG_ARCH_MX53)	:= 0x70008000
-params_phys-$(CONFIG_ARCH_MX53)	:= 0x70000100
-initrd_phys-$(CONFIG_ARCH_MX53)	:= 0x70800000
+   zreladdr-$(CONFIG_SOC_MX50)	:= 0x70008000
+params_phys-$(CONFIG_SOC_MX50)	:= 0x70000100
+initrd_phys-$(CONFIG_SOC_MX50)	:= 0x70800000
+   zreladdr-$(CONFIG_SOC_MX51)	:= 0x90008000
+params_phys-$(CONFIG_SOC_MX51)	:= 0x90000100
+initrd_phys-$(CONFIG_SOC_MX51)	:= 0x90800000
+   zreladdr-$(CONFIG_SOC_MX53)	:= 0x70008000
+params_phys-$(CONFIG_SOC_MX53)	:= 0x70000100
+initrd_phys-$(CONFIG_SOC_MX53)	:= 0x70800000
diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
index 33530d2..be7df13 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
@@ -194,7 +194,7 @@ static int __init imxXX_add_imx_dma(void)
 	} else
 #endif
 
-#if defined(CONFIG_ARCH_MX51)
+#if defined(CONFIG_SOC_IMX51)
 	if (cpu_is_mx51()) {
 		imx51_imx_sdma_data.pdata.script_addrs = &addr_imx51_to1;
 		ret = imx_add_imx_sdma(&imx51_imx_sdma_data);
diff --git a/arch/arm/plat-mxc/include/mach/irqs.h b/arch/arm/plat-mxc/include/mach/irqs.h
index ba65c92..a3d930d 100644
--- a/arch/arm/plat-mxc/include/mach/irqs.h
+++ b/arch/arm/plat-mxc/include/mach/irqs.h
@@ -23,17 +23,17 @@
 #define MXC_GPIO_IRQ_START	MXC_INTERNAL_IRQS
 
 /* these are ordered by size to support multi-SoC kernels */
-#if defined CONFIG_ARCH_MX53
+#if defined CONFIG_SOC_IMX53
 #define MXC_GPIO_IRQS		(32 * 7)
 #elif defined CONFIG_ARCH_MX2
 #define MXC_GPIO_IRQS		(32 * 6)
-#elif defined CONFIG_ARCH_MX50
+#elif defined CONFIG_SOC_IMX50
 #define MXC_GPIO_IRQS		(32 * 6)
 #elif defined CONFIG_ARCH_MX1
 #define MXC_GPIO_IRQS		(32 * 4)
 #elif defined CONFIG_ARCH_MX25
 #define MXC_GPIO_IRQS		(32 * 4)
-#elif defined CONFIG_ARCH_MX51
+#elif defined CONFIG_SOC_IMX51
 #define MXC_GPIO_IRQS		(32 * 4)
 #elif defined CONFIG_ARCH_MXC91231
 #define MXC_GPIO_IRQS		(32 * 4)
diff --git a/arch/arm/plat-mxc/include/mach/memory.h b/arch/arm/plat-mxc/include/mach/memory.h
index 8386140..f1e9c0a 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -34,11 +34,11 @@
 #  define PHYS_OFFSET		MX3x_PHYS_OFFSET
 # elif defined CONFIG_ARCH_MXC91231
 #  define PHYS_OFFSET		MXC91231_PHYS_OFFSET
-# elif defined CONFIG_ARCH_MX50
+# elif defined CONFIG_SOC_IMX50
 #  define PHYS_OFFSET		MX50_PHYS_OFFSET
-# elif defined CONFIG_ARCH_MX51
+# elif defined CONFIG_SOC_IMX51
 #  define PHYS_OFFSET		MX51_PHYS_OFFSET
-# elif defined CONFIG_ARCH_MX53
+# elif defined CONFIG_SOC_IMX53
 #  define PHYS_OFFSET		MX53_PHYS_OFFSET
 # endif
 #endif
diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
index 04c7a26..3781f2f 100644
--- a/arch/arm/plat-mxc/include/mach/mxc.h
+++ b/arch/arm/plat-mxc/include/mach/mxc.h
@@ -127,7 +127,7 @@ extern unsigned int __mxc_cpu_type;
 # define cpu_is_mx35()		(0)
 #endif
 
-#ifdef CONFIG_ARCH_MX50
+#ifdef CONFIG_SOC_IMX50
 # ifdef mxc_cpu_type
 #  undef mxc_cpu_type
 #  define mxc_cpu_type __mxc_cpu_type
@@ -139,7 +139,7 @@ extern unsigned int __mxc_cpu_type;
 # define cpu_is_mx50()		(0)
 #endif
 
-#ifdef CONFIG_ARCH_MX51
+#ifdef CONFIG_SOC_IMX51
 # ifdef mxc_cpu_type
 #  undef mxc_cpu_type
 #  define mxc_cpu_type __mxc_cpu_type
@@ -151,7 +151,7 @@ extern unsigned int __mxc_cpu_type;
 # define cpu_is_mx51()		(0)
 #endif
 
-#ifdef CONFIG_ARCH_MX53
+#ifdef CONFIG_SOC_IMX53
 # ifdef mxc_cpu_type
 #  undef mxc_cpu_type
 #  define mxc_cpu_type __mxc_cpu_type
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index c895922..daeafc2 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -476,7 +476,7 @@ config MTD_NAND_MPC5121_NFC
 
 config MTD_NAND_MXC
 	tristate "MXC NAND support"
-	depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || ARCH_MX51
+	depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || SOC_IMX51
 	help
 	  This enables the driver for the NAND flash controller on the
 	  MXC processors.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index bb233a9..9f9d3f7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -164,10 +164,10 @@ config SPI_IMX_VER_0_4
 	def_bool y if ARCH_MX31
 
 config SPI_IMX_VER_0_7
-	def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
+	def_bool y if ARCH_MX25 || ARCH_MX35 || SOC_IMX51 || SOC_IMX53
 
 config SPI_IMX_VER_2_3
-	def_bool y if ARCH_MX51 || ARCH_MX53
+	def_bool y if SOC_IMX51 || SOC_IMX53
 
 config SPI_IMX
 	tristate "Freescale i.MX SPI controllers"
-- 
1.7.1

[RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X

[Shawn Guo]

On Wed, Mar 02, 2011 at 11:28:46AM +0800, Richard Zhao wrote:
> Remove legacy support of ARCH_MX5X. Move to SOC_SOC_IMX5X.
> 
+1

As SOC_IMXxx is introduced, ARCH_MXxx seems a little bit messy to me.

-- 
Regards,
Shawn

[RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X

[Uwe Kleine-König]

Hello Richard,

On Wed, Mar 02, 2011 at 11:28:46AM +0800, Richard Zhao wrote:
> Remove legacy support of ARCH_MX5X. Move to SOC_SOC_IMX5X.
> 
> My understanding is ARCH_MX5 selects Kconfig in arch/arm/mach-mx5,
> and every board can be selected/unselected, and SOC_XXX be selected
> by the board config. MACH_XXXX/SOC_XXXX then select those HAVE_XXXX.
My intended goal with these ARCH_MX.., MACH_MX.. and SOC_IMX.. symbols is:

 - ARCH_MX.. should be only a helper to group all machines together that
   can be built in a single image. In the far future it hopefully dies
   because we can compile everything together. These IMHO should not be
   used in Makefiles or source files at all as the grouping can change
   over time. I'm not sure the name ARCH_MX.. is that good. Didn't think
   about a better naming scheme, so if you have suggestions don't
   hesitate to tell them.
 - MACH_MX.. actually are misnomers becauce they clash with the name
   space of the machine db. So they should be substituted by SOC_IMX...
   (maybe a few by ARCH_MX..)  (affected: MACH_MX21 and MACH_MX27)
 - SOC_IMX.. are used to differentiate between SoCs.

So a goal is to review all ARCH_MX.. and MACH_MX.. used in .c and .h
files and try to use the SOC_IMX variables instead.
Here I consider important that SOC_IMX... is really only used with
having multi-SoC-kernels in mind. So you can consider ARCH_MX and
MACH_MX as todo-markers for that (and this is the main difference IMHO).
E.g. the Makefile.boots are such a place that are not multi-soc capable
yet as is the selection of PHYS_OFFSET. I'd like to keep them marked
somehow.

I don't know if it's sensible to coordinate this effort, it mainly
depends on how many people are willing to help. I'll start with ARCH_MX2
and MACH_MX2[17] next.

A bit orthogonal to this issue is to clean up mach-mx3 and mach-mx5 to
allow them to be merged into mach-imx. I didn't look at all on mxc91231,
yet.

Comments and patches are welcome. If you want to help and don't know
where to start, here are a few hints:

 - git grep -E 'M?AR?CH_MX' drivers
 - convert arch/arm/mach-mx[35]/devices.c to dynamically allocation

Richard, having said that, some of your changes look OK, while I'm not
completely happy with the others.

> diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> index f065a0d..518a39e 100644
> --- a/arch/arm/mach-mx5/Kconfig
> +++ b/arch/arm/mach-mx5/Kconfig
> @@ -1,14 +1,4 @@
>  if ARCH_MX5
> -# ARCH_MX51 and ARCH_MX50 are left for compatibility
> -
> -config ARCH_MX50
> -	bool
> -
> -config ARCH_MX51
> -	bool
> -
> -config ARCH_MX53
> -	bool
these are still needed, see below (or you should suggest an alternative marking).

>  config SOC_IMX50
>  	bool
> @@ -16,7 +6,6 @@ config SOC_IMX50
>  	select ARCH_MXC_IOMUX_V3
>  	select ARCH_MXC_AUDMUX_V2
>  	select ARCH_HAS_CPUFREQ
> -	select ARCH_MX50
>  
>  config	SOC_IMX51
>  	bool
> @@ -24,13 +13,11 @@ config	SOC_IMX51
>  	select ARCH_MXC_IOMUX_V3
>  	select ARCH_MXC_AUDMUX_V2
>  	select ARCH_HAS_CPUFREQ
> -	select ARCH_MX51
>  
>  config	SOC_IMX53
>  	bool
>  	select MXC_TZIC
>  	select ARCH_MXC_IOMUX_V3
> -	select ARCH_MX53
>  
>  comment "MX5 platforms:"
>  
> diff --git a/arch/arm/mach-mx5/Makefile.boot b/arch/arm/mach-mx5/Makefile.boot
> index e928be1..cdc70b3 100644
> --- a/arch/arm/mach-mx5/Makefile.boot
> +++ b/arch/arm/mach-mx5/Makefile.boot
> @@ -1,9 +1,9 @@
> -   zreladdr-$(CONFIG_ARCH_MX50)	:= 0x70008000
> -params_phys-$(CONFIG_ARCH_MX50)	:= 0x70000100
> -initrd_phys-$(CONFIG_ARCH_MX50)	:= 0x70800000
> -   zreladdr-$(CONFIG_ARCH_MX51)	:= 0x90008000
> -params_phys-$(CONFIG_ARCH_MX51)	:= 0x90000100
> -initrd_phys-$(CONFIG_ARCH_MX51)	:= 0x90800000
> -   zreladdr-$(CONFIG_ARCH_MX53)	:= 0x70008000
> -params_phys-$(CONFIG_ARCH_MX53)	:= 0x70000100
> -initrd_phys-$(CONFIG_ARCH_MX53)	:= 0x70800000
> +   zreladdr-$(CONFIG_SOC_MX50)	:= 0x70008000
> +params_phys-$(CONFIG_SOC_MX50)	:= 0x70000100
> +initrd_phys-$(CONFIG_SOC_MX50)	:= 0x70800000
> +   zreladdr-$(CONFIG_SOC_MX51)	:= 0x90008000
> +params_phys-$(CONFIG_SOC_MX51)	:= 0x90000100
> +initrd_phys-$(CONFIG_SOC_MX51)	:= 0x90800000
> +   zreladdr-$(CONFIG_SOC_MX53)	:= 0x70008000
> +params_phys-$(CONFIG_SOC_MX53)	:= 0x70000100
> +initrd_phys-$(CONFIG_SOC_MX53)	:= 0x70800000
> diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> index 33530d2..be7df13 100644
> --- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
> +++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> @@ -194,7 +194,7 @@ static int __init imxXX_add_imx_dma(void)
>  	} else
>  #endif
>  
> -#if defined(CONFIG_ARCH_MX51)
> +#if defined(CONFIG_SOC_IMX51)
>  	if (cpu_is_mx51()) {
>  		imx51_imx_sdma_data.pdata.script_addrs = &addr_imx51_to1;
>  		ret = imx_add_imx_sdma(&imx51_imx_sdma_data);
looks OK.

> diff --git a/arch/arm/plat-mxc/include/mach/irqs.h b/arch/arm/plat-mxc/include/mach/irqs.h
> index ba65c92..a3d930d 100644
> --- a/arch/arm/plat-mxc/include/mach/irqs.h
> +++ b/arch/arm/plat-mxc/include/mach/irqs.h
> @@ -23,17 +23,17 @@
>  #define MXC_GPIO_IRQ_START	MXC_INTERNAL_IRQS
>  
>  /* these are ordered by size to support multi-SoC kernels */
> -#if defined CONFIG_ARCH_MX53
> +#if defined CONFIG_SOC_IMX53
>  #define MXC_GPIO_IRQS		(32 * 7)
>  #elif defined CONFIG_ARCH_MX2
>  #define MXC_GPIO_IRQS		(32 * 6)
> -#elif defined CONFIG_ARCH_MX50
> +#elif defined CONFIG_SOC_IMX50
>  #define MXC_GPIO_IRQS		(32 * 6)
>  #elif defined CONFIG_ARCH_MX1
>  #define MXC_GPIO_IRQS		(32 * 4)
>  #elif defined CONFIG_ARCH_MX25
>  #define MXC_GPIO_IRQS		(32 * 4)
> -#elif defined CONFIG_ARCH_MX51
> +#elif defined CONFIG_SOC_IMX51
>  #define MXC_GPIO_IRQS		(32 * 4)
>  #elif defined CONFIG_ARCH_MXC91231
>  #define MXC_GPIO_IRQS		(32 * 4)
OK

> diff --git a/arch/arm/plat-mxc/include/mach/memory.h b/arch/arm/plat-mxc/include/mach/memory.h
> index 8386140..f1e9c0a 100644
> --- a/arch/arm/plat-mxc/include/mach/memory.h
> +++ b/arch/arm/plat-mxc/include/mach/memory.h
> @@ -34,11 +34,11 @@
>  #  define PHYS_OFFSET		MX3x_PHYS_OFFSET
>  # elif defined CONFIG_ARCH_MXC91231
>  #  define PHYS_OFFSET		MXC91231_PHYS_OFFSET
> -# elif defined CONFIG_ARCH_MX50
> +# elif defined CONFIG_SOC_IMX50
>  #  define PHYS_OFFSET		MX50_PHYS_OFFSET
> -# elif defined CONFIG_ARCH_MX51
> +# elif defined CONFIG_SOC_IMX51
>  #  define PHYS_OFFSET		MX51_PHYS_OFFSET
> -# elif defined CONFIG_ARCH_MX53
> +# elif defined CONFIG_SOC_IMX53
>  #  define PHYS_OFFSET		MX53_PHYS_OFFSET
>  # endif
>  #endif
not ok

> diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
> index 04c7a26..3781f2f 100644
> --- a/arch/arm/plat-mxc/include/mach/mxc.h
> +++ b/arch/arm/plat-mxc/include/mach/mxc.h
> @@ -127,7 +127,7 @@ extern unsigned int __mxc_cpu_type;
>  # define cpu_is_mx35()		(0)
>  #endif
>  
> -#ifdef CONFIG_ARCH_MX50
> +#ifdef CONFIG_SOC_IMX50
>  # ifdef mxc_cpu_type
>  #  undef mxc_cpu_type
>  #  define mxc_cpu_type __mxc_cpu_type
> @@ -139,7 +139,7 @@ extern unsigned int __mxc_cpu_type;
>  # define cpu_is_mx50()		(0)
>  #endif
>  
> -#ifdef CONFIG_ARCH_MX51
> +#ifdef CONFIG_SOC_IMX51
>  # ifdef mxc_cpu_type
>  #  undef mxc_cpu_type
>  #  define mxc_cpu_type __mxc_cpu_type
> @@ -151,7 +151,7 @@ extern unsigned int __mxc_cpu_type;
>  # define cpu_is_mx51()		(0)
>  #endif
>  
> -#ifdef CONFIG_ARCH_MX53
> +#ifdef CONFIG_SOC_IMX53
>  # ifdef mxc_cpu_type
>  #  undef mxc_cpu_type
>  #  define mxc_cpu_type __mxc_cpu_type
These are OK, too, I think

> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index c895922..daeafc2 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -476,7 +476,7 @@ config MTD_NAND_MPC5121_NFC
>  
>  config MTD_NAND_MXC
>  	tristate "MXC NAND support"
> -	depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || ARCH_MX51
> +	depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || SOC_IMX51
OK, though I'd prefer having

	depends on HAVE_MTD_NAND_MXC

and let the SOC_IMXYZ symbols select this one.

>  	help
>  	  This enables the driver for the NAND flash controller on the
>  	  MXC processors.
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index bb233a9..9f9d3f7 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -164,10 +164,10 @@ config SPI_IMX_VER_0_4
>  	def_bool y if ARCH_MX31
>  
>  config SPI_IMX_VER_0_7
> -	def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
> +	def_bool y if ARCH_MX25 || ARCH_MX35 || SOC_IMX51 || SOC_IMX53
>  
>  config SPI_IMX_VER_2_3
> -	def_bool y if ARCH_MX51 || ARCH_MX53
> +	def_bool y if SOC_IMX51 || SOC_IMX53
>  
>  config SPI_IMX
>  	tristate "Freescale i.MX SPI controllers"
ok

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X

[Richard Zhao]

Hi Uwe,

Thanks for your detailed explanation!
On Wed, Mar 02, 2011 at 12:25:59PM +0100, Uwe Kleine-K?nig wrote:
> Hello Richard,
> 
> On Wed, Mar 02, 2011 at 11:28:46AM +0800, Richard Zhao wrote:
> > Remove legacy support of ARCH_MX5X. Move to SOC_SOC_IMX5X.
> > 
> > My understanding is ARCH_MX5 selects Kconfig in arch/arm/mach-mx5,
> > and every board can be selected/unselected, and SOC_XXX be selected
> > by the board config. MACH_XXXX/SOC_XXXX then select those HAVE_XXXX.
> My intended goal with these ARCH_MX.., MACH_MX.. and SOC_IMX.. symbols is:
> 
>  - ARCH_MX.. should be only a helper to group all machines together that
>    can be built in a single image. In the far future it hopefully dies
>    because we can compile everything together. These IMHO should not be
>    used in Makefiles or source files at all as the grouping can change
>    over time. I'm not sure the name ARCH_MX.. is that good. Didn't think
>    about a better naming scheme, so if you have suggestions don't
>    hesitate to tell them.
Would it make sense to go straight forward? 
ARCH_MX.. for SoC series. eg. ARCH_MX1/2/3/5. It groups SoCs.
SOC_IMX.. for single SoC. eg. SOC_IMX31/35/50/51/53. It groups Machines.
MACH_.. for single machine. eg. MACH_MX51_BABBAGE.

They can be used in Makefiles to help include source files, but idealy not be
used in source files. For multi-soc in single image, it's more easy to select
build targets. It can also help transit to single image step by step.

>  - MACH_MX.. actually are misnomers becauce they clash with the name
>    space of the machine db. So they should be substituted by SOC_IMX...
>    (maybe a few by ARCH_MX..)  (affected: MACH_MX21 and MACH_MX27)
>  - SOC_IMX.. are used to differentiate between SoCs.
> 
> So a goal is to review all ARCH_MX.. and MACH_MX.. used in .c and .h
> files and try to use the SOC_IMX variables instead.
> Here I consider important that SOC_IMX... is really only used with
> having multi-SoC-kernels in mind. So you can consider ARCH_MX and
> MACH_MX as todo-markers for that (and this is the main difference IMHO).
> E.g. the Makefile.boots are such a place that are not multi-soc capable
> yet as is the selection of PHYS_OFFSET. I'd like to keep them marked
> somehow.
The ToDO markers might label itself as markers, Or it cause many people
confused.
And are you sure we won't need ARCH_MX.. in the final single image solution?
IMHO, single image needs to select what targetis it builds for too. The ARCH_MX..
works as categories and help reduce image size. 
> 
> I don't know if it's sensible to coordinate this effort, it mainly
> depends on how many people are willing to help. I'll start with ARCH_MX2
> and MACH_MX2[17] next.
> 
> A bit orthogonal to this issue is to clean up mach-mx3 and mach-mx5 to
> allow them to be merged into mach-imx. I didn't look at all on mxc91231,
> yet.
> 
> Comments and patches are welcome. If you want to help and don't know
> where to start, here are a few hints:
> 
>  - git grep -E 'M?AR?CH_MX' drivers
>  - convert arch/arm/mach-mx[35]/devices.c to dynamically allocation
> 
> Richard, having said that, some of your changes look OK, while I'm not
> completely happy with the others.
It seems only PHYS_OFFSET are not ok? Maybe the p2v patch can help?
> 
> > diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> > index f065a0d..518a39e 100644
> > --- a/arch/arm/mach-mx5/Kconfig
> > +++ b/arch/arm/mach-mx5/Kconfig
> > @@ -1,14 +1,4 @@
> >  if ARCH_MX5
> > -# ARCH_MX51 and ARCH_MX50 are left for compatibility
> > -
> > -config ARCH_MX50
> > -	bool
> > -
> > -config ARCH_MX51
> > -	bool
> > -
> > -config ARCH_MX53
> > -	bool
> these are still needed, see below (or you should suggest an alternative marking).
> 
> >  config SOC_IMX50
> >  	bool
> > @@ -16,7 +6,6 @@ config SOC_IMX50
> >  	select ARCH_MXC_IOMUX_V3
> >  	select ARCH_MXC_AUDMUX_V2
> >  	select ARCH_HAS_CPUFREQ
> > -	select ARCH_MX50
> >  
> >  config	SOC_IMX51
> >  	bool
> > @@ -24,13 +13,11 @@ config	SOC_IMX51
> >  	select ARCH_MXC_IOMUX_V3
> >  	select ARCH_MXC_AUDMUX_V2
> >  	select ARCH_HAS_CPUFREQ
> > -	select ARCH_MX51
> >  
> >  config	SOC_IMX53
> >  	bool
> >  	select MXC_TZIC
> >  	select ARCH_MXC_IOMUX_V3
> > -	select ARCH_MX53
> >  
> >  comment "MX5 platforms:"
> >  
> > diff --git a/arch/arm/mach-mx5/Makefile.boot b/arch/arm/mach-mx5/Makefile.boot
> > index e928be1..cdc70b3 100644
> > --- a/arch/arm/mach-mx5/Makefile.boot
> > +++ b/arch/arm/mach-mx5/Makefile.boot
> > @@ -1,9 +1,9 @@
> > -   zreladdr-$(CONFIG_ARCH_MX50)	:= 0x70008000
> > -params_phys-$(CONFIG_ARCH_MX50)	:= 0x70000100
> > -initrd_phys-$(CONFIG_ARCH_MX50)	:= 0x70800000
> > -   zreladdr-$(CONFIG_ARCH_MX51)	:= 0x90008000
> > -params_phys-$(CONFIG_ARCH_MX51)	:= 0x90000100
> > -initrd_phys-$(CONFIG_ARCH_MX51)	:= 0x90800000
> > -   zreladdr-$(CONFIG_ARCH_MX53)	:= 0x70008000
> > -params_phys-$(CONFIG_ARCH_MX53)	:= 0x70000100
> > -initrd_phys-$(CONFIG_ARCH_MX53)	:= 0x70800000
> > +   zreladdr-$(CONFIG_SOC_MX50)	:= 0x70008000
> > +params_phys-$(CONFIG_SOC_MX50)	:= 0x70000100
> > +initrd_phys-$(CONFIG_SOC_MX50)	:= 0x70800000
> > +   zreladdr-$(CONFIG_SOC_MX51)	:= 0x90008000
> > +params_phys-$(CONFIG_SOC_MX51)	:= 0x90000100
> > +initrd_phys-$(CONFIG_SOC_MX51)	:= 0x90800000
> > +   zreladdr-$(CONFIG_SOC_MX53)	:= 0x70008000
> > +params_phys-$(CONFIG_SOC_MX53)	:= 0x70000100
> > +initrd_phys-$(CONFIG_SOC_MX53)	:= 0x70800000
> > diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> > index 33530d2..be7df13 100644
> > --- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
> > +++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> > @@ -194,7 +194,7 @@ static int __init imxXX_add_imx_dma(void)
> >  	} else
> >  #endif
> >  
> > -#if defined(CONFIG_ARCH_MX51)
> > +#if defined(CONFIG_SOC_IMX51)
> >  	if (cpu_is_mx51()) {
> >  		imx51_imx_sdma_data.pdata.script_addrs = &addr_imx51_to1;
> >  		ret = imx_add_imx_sdma(&imx51_imx_sdma_data);
> looks OK.
> 
> > diff --git a/arch/arm/plat-mxc/include/mach/irqs.h b/arch/arm/plat-mxc/include/mach/irqs.h
> > index ba65c92..a3d930d 100644
> > --- a/arch/arm/plat-mxc/include/mach/irqs.h
> > +++ b/arch/arm/plat-mxc/include/mach/irqs.h
> > @@ -23,17 +23,17 @@
> >  #define MXC_GPIO_IRQ_START	MXC_INTERNAL_IRQS
> >  
> >  /* these are ordered by size to support multi-SoC kernels */
> > -#if defined CONFIG_ARCH_MX53
> > +#if defined CONFIG_SOC_IMX53
> >  #define MXC_GPIO_IRQS		(32 * 7)
> >  #elif defined CONFIG_ARCH_MX2
> >  #define MXC_GPIO_IRQS		(32 * 6)
> > -#elif defined CONFIG_ARCH_MX50
> > +#elif defined CONFIG_SOC_IMX50
> >  #define MXC_GPIO_IRQS		(32 * 6)
> >  #elif defined CONFIG_ARCH_MX1
> >  #define MXC_GPIO_IRQS		(32 * 4)
> >  #elif defined CONFIG_ARCH_MX25
> >  #define MXC_GPIO_IRQS		(32 * 4)
> > -#elif defined CONFIG_ARCH_MX51
> > +#elif defined CONFIG_SOC_IMX51
> >  #define MXC_GPIO_IRQS		(32 * 4)
> >  #elif defined CONFIG_ARCH_MXC91231
> >  #define MXC_GPIO_IRQS		(32 * 4)
> OK
> 
> > diff --git a/arch/arm/plat-mxc/include/mach/memory.h b/arch/arm/plat-mxc/include/mach/memory.h
> > index 8386140..f1e9c0a 100644
> > --- a/arch/arm/plat-mxc/include/mach/memory.h
> > +++ b/arch/arm/plat-mxc/include/mach/memory.h
> > @@ -34,11 +34,11 @@
> >  #  define PHYS_OFFSET		MX3x_PHYS_OFFSET
> >  # elif defined CONFIG_ARCH_MXC91231
> >  #  define PHYS_OFFSET		MXC91231_PHYS_OFFSET
> > -# elif defined CONFIG_ARCH_MX50
> > +# elif defined CONFIG_SOC_IMX50
> >  #  define PHYS_OFFSET		MX50_PHYS_OFFSET
> > -# elif defined CONFIG_ARCH_MX51
> > +# elif defined CONFIG_SOC_IMX51
> >  #  define PHYS_OFFSET		MX51_PHYS_OFFSET
> > -# elif defined CONFIG_ARCH_MX53
> > +# elif defined CONFIG_SOC_IMX53
> >  #  define PHYS_OFFSET		MX53_PHYS_OFFSET
> >  # endif
> >  #endif
> not ok
> 
> > diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
> > index 04c7a26..3781f2f 100644
> > --- a/arch/arm/plat-mxc/include/mach/mxc.h
> > +++ b/arch/arm/plat-mxc/include/mach/mxc.h
> > @@ -127,7 +127,7 @@ extern unsigned int __mxc_cpu_type;
> >  # define cpu_is_mx35()		(0)
> >  #endif
> >  
> > -#ifdef CONFIG_ARCH_MX50
> > +#ifdef CONFIG_SOC_IMX50
> >  # ifdef mxc_cpu_type
> >  #  undef mxc_cpu_type
> >  #  define mxc_cpu_type __mxc_cpu_type
> > @@ -139,7 +139,7 @@ extern unsigned int __mxc_cpu_type;
> >  # define cpu_is_mx50()		(0)
> >  #endif
> >  
> > -#ifdef CONFIG_ARCH_MX51
> > +#ifdef CONFIG_SOC_IMX51
> >  # ifdef mxc_cpu_type
> >  #  undef mxc_cpu_type
> >  #  define mxc_cpu_type __mxc_cpu_type
> > @@ -151,7 +151,7 @@ extern unsigned int __mxc_cpu_type;
> >  # define cpu_is_mx51()		(0)
> >  #endif
> >  
> > -#ifdef CONFIG_ARCH_MX53
> > +#ifdef CONFIG_SOC_IMX53
> >  # ifdef mxc_cpu_type
> >  #  undef mxc_cpu_type
> >  #  define mxc_cpu_type __mxc_cpu_type
> These are OK, too, I think
> 
> > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > index c895922..daeafc2 100644
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -476,7 +476,7 @@ config MTD_NAND_MPC5121_NFC
> >  
> >  config MTD_NAND_MXC
> >  	tristate "MXC NAND support"
> > -	depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || ARCH_MX51
> > +	depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || SOC_IMX51
> OK, though I'd prefer having
> 
> 	depends on HAVE_MTD_NAND_MXC
> 
> and let the SOC_IMXYZ symbols select this one.
Yes. Thanks.
> 
> >  	help
> >  	  This enables the driver for the NAND flash controller on the
> >  	  MXC processors.
> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > index bb233a9..9f9d3f7 100644
> > --- a/drivers/spi/Kconfig
> > +++ b/drivers/spi/Kconfig
> > @@ -164,10 +164,10 @@ config SPI_IMX_VER_0_4
> >  	def_bool y if ARCH_MX31
> >  
> >  config SPI_IMX_VER_0_7
> > -	def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
> > +	def_bool y if ARCH_MX25 || ARCH_MX35 || SOC_IMX51 || SOC_IMX53
> >  
> >  config SPI_IMX_VER_2_3
> > -	def_bool y if ARCH_MX51 || ARCH_MX53
> > +	def_bool y if SOC_IMX51 || SOC_IMX53
> >  
> >  config SPI_IMX
> >  	tristate "Freescale i.MX SPI controllers"
> ok
> 
Thanks
Richard
> Best regards
> Uwe
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X

[Uwe Kleine-König]

On Thu, Mar 03, 2011 at 12:06:05AM +0800, Richard Zhao wrote:
> Hi Uwe,
> 
> Thanks for your detailed explanation!
> On Wed, Mar 02, 2011 at 12:25:59PM +0100, Uwe Kleine-K?nig wrote:
> > Hello Richard,
> > 
> > On Wed, Mar 02, 2011 at 11:28:46AM +0800, Richard Zhao wrote:
> > > Remove legacy support of ARCH_MX5X. Move to SOC_SOC_IMX5X.
> > > 
> > > My understanding is ARCH_MX5 selects Kconfig in arch/arm/mach-mx5,
> > > and every board can be selected/unselected, and SOC_XXX be selected
> > > by the board config. MACH_XXXX/SOC_XXXX then select those HAVE_XXXX.
> > My intended goal with these ARCH_MX.., MACH_MX.. and SOC_IMX.. symbols is:
> > 
> >  - ARCH_MX.. should be only a helper to group all machines together that
> >    can be built in a single image. In the far future it hopefully dies
> >    because we can compile everything together. These IMHO should not be
> >    used in Makefiles or source files at all as the grouping can change
> >    over time. I'm not sure the name ARCH_MX.. is that good. Didn't think
> >    about a better naming scheme, so if you have suggestions don't
> >    hesitate to tell them.
> Would it make sense to go straight forward? 
> ARCH_MX.. for SoC series. eg. ARCH_MX1/2/3/5. It groups SoCs.
This doesn't work. Where do you want to put i.MX25? Conceptually the
easy groups are { i.MX21, i.MX27 } and { i.MX25, i.MX31, i.MX35 }
because these share PHYS_OFFSETs. And note that i.MX31 has a different
iomuxer than i.MX25 and i.MX35. As soon as we have support for runtime
PHYS_OFFSET the remaining groups are:

	ARMv4 + ARMv5 vs. ARMv6 + ARMv7

(I think) which doesn't match the ARCH_MX1/2/3/5 approach anymore.

> SOC_IMX.. for single SoC. eg. SOC_IMX31/35/50/51/53. It groups Machines.
> MACH_.. for single machine. eg. MACH_MX51_BABBAGE.
> 
> They can be used in Makefiles to help include source files, but idealy not be
> used in source files. For multi-soc in single image, it's more easy to select
> build targets. It can also help transit to single image step by step.
Here I'd prefer things like:

	config SOC_IMX21
		bool
		select IMX_HAVE_IOMUX_V1

	obj-$(IMX_HAVE_IOMUX_V1) += tralala.o

> >  - MACH_MX.. actually are misnomers becauce they clash with the name
> >    space of the machine db. So they should be substituted by SOC_IMX...
> >    (maybe a few by ARCH_MX..)  (affected: MACH_MX21 and MACH_MX27)
> >  - SOC_IMX.. are used to differentiate between SoCs.
> > 
> > So a goal is to review all ARCH_MX.. and MACH_MX.. used in .c and .h
> > files and try to use the SOC_IMX variables instead.
> > Here I consider important that SOC_IMX... is really only used with
> > having multi-SoC-kernels in mind. So you can consider ARCH_MX and
> > MACH_MX as todo-markers for that (and this is the main difference IMHO).
> > E.g. the Makefile.boots are such a place that are not multi-soc capable
> > yet as is the selection of PHYS_OFFSET. I'd like to keep them marked
> > somehow.
> The ToDO markers might label itself as markers, Or it cause many people
> confused.
I don't know what you mean here.

> And are you sure we won't need ARCH_MX.. in the final single image solution?
> IMHO, single image needs to select what targetis it builds for too. The ARCH_MX..
> works as categories and help reduce image size. 
Again, I don't understand you here.

> > I don't know if it's sensible to coordinate this effort, it mainly
> > depends on how many people are willing to help. I'll start with ARCH_MX2
> > and MACH_MX2[17] next.
> > 
> > A bit orthogonal to this issue is to clean up mach-mx3 and mach-mx5 to
> > allow them to be merged into mach-imx. I didn't look at all on mxc91231,
> > yet.
> > 
> > Comments and patches are welcome. If you want to help and don't know
> > where to start, here are a few hints:
> > 
> >  - git grep -E 'M?AR?CH_MX' drivers
> >  - convert arch/arm/mach-mx[35]/devices.c to dynamically allocation
> > 
> > Richard, having said that, some of your changes look OK, while I'm not
> > completely happy with the others.
> It seems only PHYS_OFFSET are not ok?
and Makefile.boot

>                                       Maybe the p2v patch can help?
Indeed.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X

[Richard Zhao]

Hi Uwe,

On Wed, Mar 02, 2011 at 05:33:26PM +0100, Uwe Kleine-K?nig wrote:
> On Thu, Mar 03, 2011 at 12:06:05AM +0800, Richard Zhao wrote:
> > Hi Uwe,
> > 
> > Thanks for your detailed explanation!
> > On Wed, Mar 02, 2011 at 12:25:59PM +0100, Uwe Kleine-K?nig wrote:
> > > Hello Richard,
> > > 
> > > On Wed, Mar 02, 2011 at 11:28:46AM +0800, Richard Zhao wrote:
> > > > Remove legacy support of ARCH_MX5X. Move to SOC_SOC_IMX5X.
> > > > 
> > > > My understanding is ARCH_MX5 selects Kconfig in arch/arm/mach-mx5,
> > > > and every board can be selected/unselected, and SOC_XXX be selected
> > > > by the board config. MACH_XXXX/SOC_XXXX then select those HAVE_XXXX.
> > > My intended goal with these ARCH_MX.., MACH_MX.. and SOC_IMX.. symbols is:
> > > 
> > >  - ARCH_MX.. should be only a helper to group all machines together that
> > >    can be built in a single image. In the far future it hopefully dies
> > >    because we can compile everything together. These IMHO should not be
> > >    used in Makefiles or source files at all as the grouping can change
> > >    over time. I'm not sure the name ARCH_MX.. is that good. Didn't think
> > >    about a better naming scheme, so if you have suggestions don't
> > >    hesitate to tell them.
> > Would it make sense to go straight forward? 
> > ARCH_MX.. for SoC series. eg. ARCH_MX1/2/3/5. It groups SoCs.
> This doesn't work. Where do you want to put i.MX25? Conceptually the
> easy groups are { i.MX21, i.MX27 } and { i.MX25, i.MX31, i.MX35 }
> because these share PHYS_OFFSETs. And note that i.MX31 has a different
> iomuxer than i.MX25 and i.MX35. As soon as we have support for runtime
> PHYS_OFFSET the remaining groups are:
> 
> 	ARMv4 + ARMv5 vs. ARMv6 + ARMv7
> 
> (I think) which doesn't match the ARCH_MX1/2/3/5 approach anymore.
I see, you goup it by same features.
> 
> > SOC_IMX.. for single SoC. eg. SOC_IMX31/35/50/51/53. It groups Machines.
> > MACH_.. for single machine. eg. MACH_MX51_BABBAGE.
> > 
> > They can be used in Makefiles to help include source files, but idealy not be
> > used in source files. For multi-soc in single image, it's more easy to select
> > build targets. It can also help transit to single image step by step.
> Here I'd prefer things like:
> 
> 	config SOC_IMX21
> 		bool
> 		select IMX_HAVE_IOMUX_V1
> 
> 	obj-$(IMX_HAVE_IOMUX_V1) += tralala.o
> 
> > >  - MACH_MX.. actually are misnomers becauce they clash with the name
> > >    space of the machine db. So they should be substituted by SOC_IMX...
> > >    (maybe a few by ARCH_MX..)  (affected: MACH_MX21 and MACH_MX27)
> > >  - SOC_IMX.. are used to differentiate between SoCs.
> > > 
> > > So a goal is to review all ARCH_MX.. and MACH_MX.. used in .c and .h
> > > files and try to use the SOC_IMX variables instead.
> > > Here I consider important that SOC_IMX... is really only used with
> > > having multi-SoC-kernels in mind. So you can consider ARCH_MX and
> > > MACH_MX as todo-markers for that (and this is the main difference IMHO).
> > > E.g. the Makefile.boots are such a place that are not multi-soc capable
> > > yet as is the selection of PHYS_OFFSET. I'd like to keep them marked
> > > somehow.
> > The ToDO markers might label itself as markers, Or it cause many people
> > confused.
> I don't know what you mean here.
I mean need more comments at:
if ARCH_MX5
# ARCH_MX51 and ARCH_MX50 are left for compatibility
> 
> > And are you sure we won't need ARCH_MX.. in the final single image solution?
> > IMHO, single image needs to select what targetis it builds for too. The ARCH_MX..
> > works as categories and help reduce image size. 
> Again, I don't understand you here.
I mean ARCH_MX1/2/3 is easy to group SoCs and boards, and esay to select the set
of SoCs/Boards I want to build the kernel for.
> 
> > > I don't know if it's sensible to coordinate this effort, it mainly
> > > depends on how many people are willing to help. I'll start with ARCH_MX2
> > > and MACH_MX2[17] next.
> > > 
> > > A bit orthogonal to this issue is to clean up mach-mx3 and mach-mx5 to
> > > allow them to be merged into mach-imx. I didn't look at all on mxc91231,
> > > yet.
> > > 
> > > Comments and patches are welcome. If you want to help and don't know
> > > where to start, here are a few hints:
> > > 
> > >  - git grep -E 'M?AR?CH_MX' drivers
> > >  - convert arch/arm/mach-mx[35]/devices.c to dynamically allocation
> > > 
> > > Richard, having said that, some of your changes look OK, while I'm not
> > > completely happy with the others.
> > It seems only PHYS_OFFSET are not ok?
> and Makefile.boot
ok. so, I will send out patch leaving the two places unchanged.

Thanks
Richard
> 
> >                                       Maybe the p2v patch can help?
> Indeed.
> 
> Best regards
> Uwe
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-K?nig            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> 

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Uwe Kleine-König]

The only use of selecting MX2-based before was to get the choice to select
between i.MX21 and i.MX27. So better provide this choice directly.

Note that this has an influence on reduced i.MX21 configs because the
former default "MACH_MX21" for the "CPUs" choice makes MACH_MX21 not
appear in the reduced config and so the default for "Freescale CPU family:"
(i.e. ARCH_MX3) is used now.  mx21_defconfig is adapted not to be affected
by this problem.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/configs/mx21_defconfig |    2 +-
 arch/arm/configs/mx27_defconfig |    1 -
 arch/arm/mach-imx/Kconfig       |   20 --------------------
 arch/arm/plat-mxc/Kconfig       |   19 ++++++++++++++++---
 4 files changed, 17 insertions(+), 25 deletions(-)

diff --git a/arch/arm/configs/mx21_defconfig b/arch/arm/configs/mx21_defconfig
index a5a71c2..761fea6 100644
--- a/arch/arm/configs/mx21_defconfig
+++ b/arch/arm/configs/mx21_defconfig
@@ -12,7 +12,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_MXC=y
-CONFIG_ARCH_MX2=y
+CONFIG_MACH_MX21=y
 CONFIG_MACH_MX21ADS=y
 CONFIG_MXC_PWM=y
 CONFIG_NO_HZ=y
diff --git a/arch/arm/configs/mx27_defconfig b/arch/arm/configs/mx27_defconfig
index 3817c60..098d77d 100644
--- a/arch/arm/configs/mx27_defconfig
+++ b/arch/arm/configs/mx27_defconfig
@@ -17,7 +17,6 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_MXC=y
-CONFIG_ARCH_MX2=y
 CONFIG_MACH_MX27=y
 CONFIG_MACH_MX27ADS=y
 CONFIG_MACH_PCM038=y
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index c172418..c94cbad 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -53,26 +53,6 @@ config MACH_SCB9328
 
 endif
 
-if ARCH_MX2
-
-choice
-	prompt "CPUs:"
-	default MACH_MX21
-
-config MACH_MX21
-	bool "i.MX21 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX21 processor.
-
-config MACH_MX27
-	bool "i.MX27 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX27 processor.
-
-endchoice
-
-endif
-
 if MACH_MX21
 
 comment "MX21 platforms:"
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index 389f217..03a9a9e 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -2,6 +2,10 @@ if ARCH_MXC
 
 source "arch/arm/plat-mxc/devices/Kconfig"
 
+config ARCH_MX2
+	# don't use this in new code
+	bool
+
 menu "Freescale MXC Implementations"
 
 choice
@@ -14,16 +18,25 @@ config ARCH_MX1
 	help
 	  This enables support for systems based on the Freescale i.MX1 family
 
-config ARCH_MX2
-	bool "MX2-based"
+config MACH_MX21
+	bool "MX21-based"
+	select ARCH_MX2
 	help
-	  This enables support for systems based on the Freescale i.MX2 family
+	  This enables support for systems based on the Freescale i.MX21 family
 
 config ARCH_MX25
 	bool "MX25-based"
+	# note that i.MX25 doesn't match the expectations that are currently
+	# called ARCH_MX2
 	help
 	  This enables support for systems based on the Freescale i.MX25 family
 
+config MACH_MX27
+	bool "MX27-based"
+	select ARCH_MX2
+	help
+	  This enables support for Freescale's MX2 based i.MX27 processor.
+
 config ARCH_MX3
 	bool "MX3-based"
 	select CPU_V6
-- 
1.7.2.3

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Richard Zhao]

Hi Uwe,
On Wed, Mar 02, 2011 at 06:23:05PM +0100, Uwe Kleine-K?nig wrote:
> The only use of selecting MX2-based before was to get the choice to select
> between i.MX21 and i.MX27. So better provide this choice directly.
> 
> Note that this has an influence on reduced i.MX21 configs because the
> former default "MACH_MX21" for the "CPUs" choice makes MACH_MX21 not
> appear in the reduced config and so the default for "Freescale CPU family:"
> (i.e. ARCH_MX3) is used now.  mx21_defconfig is adapted not to be affected
> by this problem.
> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
>  arch/arm/configs/mx21_defconfig |    2 +-
>  arch/arm/configs/mx27_defconfig |    1 -
>  arch/arm/mach-imx/Kconfig       |   20 --------------------
>  arch/arm/plat-mxc/Kconfig       |   19 ++++++++++++++++---
>  4 files changed, 17 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/configs/mx21_defconfig b/arch/arm/configs/mx21_defconfig
> index a5a71c2..761fea6 100644
> --- a/arch/arm/configs/mx21_defconfig
> +++ b/arch/arm/configs/mx21_defconfig
> @@ -12,7 +12,7 @@ CONFIG_MODULE_UNLOAD=y
>  # CONFIG_IOSCHED_DEADLINE is not set
>  # CONFIG_IOSCHED_CFQ is not set
>  CONFIG_ARCH_MXC=y
> -CONFIG_ARCH_MX2=y
> +CONFIG_MACH_MX21=y
>  CONFIG_MACH_MX21ADS=y
>  CONFIG_MXC_PWM=y
>  CONFIG_NO_HZ=y
> diff --git a/arch/arm/configs/mx27_defconfig b/arch/arm/configs/mx27_defconfig
> index 3817c60..098d77d 100644
> --- a/arch/arm/configs/mx27_defconfig
> +++ b/arch/arm/configs/mx27_defconfig
> @@ -17,7 +17,6 @@ CONFIG_MODULE_UNLOAD=y
>  # CONFIG_IOSCHED_DEADLINE is not set
>  # CONFIG_IOSCHED_CFQ is not set
>  CONFIG_ARCH_MXC=y
> -CONFIG_ARCH_MX2=y
>  CONFIG_MACH_MX27=y
>  CONFIG_MACH_MX27ADS=y
>  CONFIG_MACH_PCM038=y
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index c172418..c94cbad 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -53,26 +53,6 @@ config MACH_SCB9328
>  
>  endif
>  
> -if ARCH_MX2
> -
> -choice
> -	prompt "CPUs:"
> -	default MACH_MX21
> -
> -config MACH_MX21
> -	bool "i.MX21 support"
> -	help
> -	  This enables support for Freescale's MX2 based i.MX21 processor.
> -
> -config MACH_MX27
> -	bool "i.MX27 support"
> -	help
> -	  This enables support for Freescale's MX2 based i.MX27 processor.
> -
> -endchoice
> -
> -endif
> -
>  if MACH_MX21
>  
>  comment "MX21 platforms:"
> diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
> index 389f217..03a9a9e 100644
> --- a/arch/arm/plat-mxc/Kconfig
> +++ b/arch/arm/plat-mxc/Kconfig
> @@ -2,6 +2,10 @@ if ARCH_MXC
>  
>  source "arch/arm/plat-mxc/devices/Kconfig"
>  
> +config ARCH_MX2
> +	# don't use this in new code
> +	bool
> +
>  menu "Freescale MXC Implementations"
>  
>  choice
> @@ -14,16 +18,25 @@ config ARCH_MX1
>  	help
>  	  This enables support for systems based on the Freescale i.MX1 family
>  
> -config ARCH_MX2
> -	bool "MX2-based"
> +config MACH_MX21
> +	bool "MX21-based"
> +	select ARCH_MX2
>  	help
> -	  This enables support for systems based on the Freescale i.MX2 family
> +	  This enables support for systems based on the Freescale i.MX21 family
Is it ToDo marker like ARCH_51? Why is it MACH_xx while others are ARCH_XX?
It might be little strange that mx2x is a excetion while others are grouped.

Thanks
Richard
>  
>  config ARCH_MX25
>  	bool "MX25-based"
> +	# note that i.MX25 doesn't match the expectations that are currently
> +	# called ARCH_MX2
>  	help
>  	  This enables support for systems based on the Freescale i.MX25 family
>  
> +config MACH_MX27
> +	bool "MX27-based"
> +	select ARCH_MX2
> +	help
> +	  This enables support for Freescale's MX2 based i.MX27 processor.
> +
>  config ARCH_MX3
>  	bool "MX3-based"
>  	select CPU_V6
> -- 
> 1.7.2.3
> 
> 

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Uwe Kleine-König]

Hi Richard,

On Thu, Mar 03, 2011 at 01:26:54PM +0800, Richard Zhao wrote:
> On Wed, Mar 02, 2011 at 06:23:05PM +0100, Uwe Kleine-K?nig wrote:
> > The only use of selecting MX2-based before was to get the choice to select
> > between i.MX21 and i.MX27. So better provide this choice directly.
> > 
> > Note that this has an influence on reduced i.MX21 configs because the
> > former default "MACH_MX21" for the "CPUs" choice makes MACH_MX21 not
> > appear in the reduced config and so the default for "Freescale CPU family:"
> > (i.e. ARCH_MX3) is used now.  mx21_defconfig is adapted not to be affected
> > by this problem.
> > 
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

> > -config ARCH_MX2
> > -	bool "MX2-based"
> > +config MACH_MX21
> > +	bool "MX21-based"
> > +	select ARCH_MX2
> >  	help
> > -	  This enables support for systems based on the Freescale i.MX2 family
> > +	  This enables support for systems based on the Freescale i.MX21 family
> Is it ToDo marker like ARCH_51? Why is it MACH_xx while others are ARCH_XX?
this is done to keep existing code working. MACH_MX21 and MACH_MX27 are
used in drivers/.

> It might be little strange that mx2x is a excetion while others are grouped.
This is good, it might make people aware that there is still work to do.
:-)  After the first steps for a multi-SoC-kernel are done, the grouping
has to change anyhow and doesn't match cpu families anymore. Moreover
MX2 is (IMHO) a marketing name, e.g. because i.MX25 is too different
compared to i.MX21 and i.MX27. And note that i.MX25 had a seperat entry
already before.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Sascha Hauer]

On Wed, Mar 02, 2011 at 06:23:05PM +0100, Uwe Kleine-K?nig wrote:
> The only use of selecting MX2-based before was to get the choice to select
> between i.MX21 and i.MX27. So better provide this choice directly.
> 
> Note that this has an influence on reduced i.MX21 configs because the
> former default "MACH_MX21" for the "CPUs" choice makes MACH_MX21 not
> appear in the reduced config and so the default for "Freescale CPU family:"
> (i.e. ARCH_MX3) is used now.  mx21_defconfig is adapted not to be affected
> by this problem.

Do we really want to do this? Now that we are likely to get phys/virt
runtime patching in the next merge window I'd rather do something like
this:

8<--------------------------------------
[PATCH] ARM i.MX: Allow to compile SoCs contained in arch-imx in a single kernel

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/Kconfig |  112 ++++++++++++++++++++++++++++++--------------
 arch/arm/plat-mxc/Kconfig |   17 +------
 2 files changed, 79 insertions(+), 50 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 5eec099..1c6d8d5 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -1,8 +1,28 @@
+if ARCH_IMX
+
 config IMX_HAVE_DMA_V1
 	bool
 
+# obsolete: The MACH_MX/ARCH_MX should go away once the users
+# are moved to the corresponding SOC_IMX_* in the tree
+config MACH_MX21
+	bool
+
+config MACH_MX27
+	bool
+
+config ARCH_MX25
+	bool
+
+config ARCH_MX2
+	bool
+
+config ARCH_MX1
+	bool
+
 config SOC_IMX1
 	bool
+	select ARCH_MX1
 	select CPU_ARM920T
 	select IMX_HAVE_DMA_V1
 	select IMX_HAVE_IOMUX_V1
@@ -10,6 +30,8 @@ config SOC_IMX1
 
 config SOC_IMX21
 	bool
+	select MACH_MX21
+	select ARCH_MX2
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V1
 	select IMX_HAVE_DMA_V1
@@ -18,6 +40,7 @@ config SOC_IMX21
 
 config SOC_IMX25
 	bool
+	select ARCH_MX25
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V2
 	select ARCH_MXC_IOMUX_V3
@@ -25,13 +48,61 @@ config SOC_IMX25
 
 config SOC_IMX27
 	bool
+	select ARCH_MX2
+	select MACH_MX27
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V1
 	select IMX_HAVE_DMA_V1
 	select IMX_HAVE_IOMUX_V1
 	select MXC_AVIC
 
-if ARCH_MX1
+config IMX_MULTI_ARCHITECTURE
+	bool "i.MX multi architecture support"
+	depends on ARM_PATCH_PHYS_VIRT
+	depends on AUTO_ZRELADDR
+
+if IMX_MULTI_ARCHITECTURE
+config ARCH_IMX_MULTI_MX1
+	select SOC_IMX1
+	bool "i.MX1 support"
+
+config ARCH_IMX_MULTI_MX21
+	select SOC_IMX21
+	bool "i.MX21 support"
+
+config ARCH_IMX_MULTI_MX25
+	select SOC_IMX25
+	bool "i.MX25 support"
+
+config ARCH_IMX_MULTI_MX27
+	select SOC_IMX27
+	bool "i.MX27 support"
+endif
+
+if !IMX_MULTI_ARCHITECTURE
+comment "enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR to get"
+comment "support for multiple i.MX Families"
+choice
+	prompt "Select i.MX CPU"
+config ARCH_IMX_HAS_MX1
+	select SOC_IMX1
+	bool "i.MX1 support"
+
+config ARCH_IMX_HAS_MX21
+	select SOC_IMX21
+	bool "i.MX21 support"
+
+config ARCH_IMX_HAS_MX25
+	select SOC_IMX25
+	bool "i.MX25 support"
+
+config ARCH_IMX_HAS_MX27
+	select SOC_IMX27
+	bool "i.MX27 support"
+endchoice
+endif
+
+if SOC_IMX1
 
 comment "MX1 platforms:"
 config MACH_MXLADS
@@ -53,33 +124,12 @@ config MACH_SCB9328
 
 endif
 
-if ARCH_MX2
-
-choice
-	prompt "CPUs:"
-	default MACH_MX21
-
-config MACH_MX21
-	bool "i.MX21 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX21 processor.
-
-config MACH_MX27
-	bool "i.MX27 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX27 processor.
-
-endchoice
-
-endif
-
-if MACH_MX21
+if SOC_IMX21
 
 comment "MX21 platforms:"
 
 config MACH_MX21ADS
 	bool "MX21ADS platform"
-	select SOC_IMX21
 	select IMX_HAVE_PLATFORM_IMX_FB
 	select IMX_HAVE_PLATFORM_IMX_UART
 	select IMX_HAVE_PLATFORM_MXC_MMC
@@ -90,13 +140,12 @@ config MACH_MX21ADS
 
 endif
 
-if ARCH_MX25
+if SOC_IMX25
 
 comment "MX25 platforms:"
 
 config MACH_MX25_3DS
 	bool "Support MX25PDK (3DS) Platform"
-	select SOC_IMX25
 	select IMX_HAVE_PLATFORM_FSL_USB2_UDC
 	select IMX_HAVE_PLATFORM_IMX2_WDT
 	select IMX_HAVE_PLATFORM_IMXDI_RTC
@@ -110,7 +159,6 @@ config MACH_MX25_3DS
 
 config MACH_EUKREA_CPUIMX25
 	bool "Support Eukrea CPUIMX25 Platform"
-	select SOC_IMX25
 	select IMX_HAVE_PLATFORM_FLEXCAN
 	select IMX_HAVE_PLATFORM_FSL_USB2_UDC
 	select IMX_HAVE_PLATFORM_IMXDI_RTC
@@ -138,13 +186,12 @@ endchoice
 
 endif
 
-if MACH_MX27
+if SOC_IMX27
 
 comment "MX27 platforms:"
 
 config MACH_MX27ADS
 	bool "MX27ADS platform"
-	select SOC_IMX27
 	select IMX_HAVE_PLATFORM_IMX_FB
 	select IMX_HAVE_PLATFORM_IMX_I2C
 	select IMX_HAVE_PLATFORM_IMX_UART
@@ -157,7 +204,6 @@ config MACH_MX27ADS
 
 config MACH_PCM038
 	bool "Phytec phyCORE-i.MX27 CPU module (pcm038)"
-	select SOC_IMX27
 	select IMX_HAVE_PLATFORM_IMX2_WDT
 	select IMX_HAVE_PLATFORM_IMX_I2C
 	select IMX_HAVE_PLATFORM_IMX_UART
@@ -187,7 +233,6 @@ endchoice
 
 config MACH_CPUIMX27
 	bool "Eukrea CPUIMX27 module"
-	select SOC_IMX27
 	select IMX_HAVE_PLATFORM_FSL_USB2_UDC
 	select IMX_HAVE_PLATFORM_IMX2_WDT
 	select IMX_HAVE_PLATFORM_IMX_I2C
@@ -236,7 +281,6 @@ endchoice
 
 config MACH_MX27_3DS
 	bool "MX27PDK platform"
-	select SOC_IMX27
 	select IMX_HAVE_PLATFORM_FSL_USB2_UDC
 	select IMX_HAVE_PLATFORM_IMX2_WDT
 	select IMX_HAVE_PLATFORM_IMX_I2C
@@ -253,7 +297,6 @@ config MACH_MX27_3DS
 
 config MACH_IMX27_VISSTRIM_M10
 	bool "Vista Silicon i.MX27 Visstrim_m10"
-	select SOC_IMX27
 	select IMX_HAVE_PLATFORM_IMX_I2C
 	select IMX_HAVE_PLATFORM_IMX_UART
 	select IMX_HAVE_PLATFORM_MXC_MMC
@@ -265,7 +308,6 @@ config MACH_IMX27_VISSTRIM_M10
 
 config MACH_IMX27LITE
 	bool "LogicPD MX27 LITEKIT platform"
-	select SOC_IMX27
 	select IMX_HAVE_PLATFORM_IMX_UART
 	select IMX_HAVE_PLATFORM_IMX_SSI
 	help
@@ -274,7 +316,6 @@ config MACH_IMX27LITE
 
 config MACH_PCA100
 	bool "Phytec phyCARD-s (pca100)"
-	select SOC_IMX27
 	select IMX_HAVE_PLATFORM_FSL_USB2_UDC
 	select IMX_HAVE_PLATFORM_IMX2_WDT
 	select IMX_HAVE_PLATFORM_IMX_FB
@@ -293,7 +334,6 @@ config MACH_PCA100
 
 config MACH_MXT_TD60
 	bool "Maxtrack i-MXT TD60"
-	select SOC_IMX27
 	select IMX_HAVE_PLATFORM_IMX_FB
 	select IMX_HAVE_PLATFORM_IMX_I2C
 	select IMX_HAVE_PLATFORM_IMX_UART
@@ -305,7 +345,6 @@ config MACH_MXT_TD60
 
 config MACH_IMX27IPCAM
 	bool "IMX27 IPCAM platform"
-	select SOC_IMX27
 	select IMX_HAVE_PLATFORM_IMX2_WDT
 	select IMX_HAVE_PLATFORM_IMX_UART
 	help
@@ -313,3 +352,4 @@ config MACH_IMX27IPCAM
 	  configurations for the board and its peripherals.
 
 endif
+endif
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index 389f217..646fee6 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -8,21 +8,10 @@ choice
 	prompt "Freescale CPU family:"
 	default ARCH_MX3
 
-config ARCH_MX1
-	bool "MX1-based"
-	select SOC_IMX1
+config ARCH_IMX
+	bool "i.MX1, i.MX21, i.MX25, i.MX27 based"
 	help
-	  This enables support for systems based on the Freescale i.MX1 family
-
-config ARCH_MX2
-	bool "MX2-based"
-	help
-	  This enables support for systems based on the Freescale i.MX2 family
-
-config ARCH_MX25
-	bool "MX25-based"
-	help
-	  This enables support for systems based on the Freescale i.MX25 family
+	  This enables support for systems based on the Freescale i.MX1/2 family
 
 config ARCH_MX3
 	bool "MX3-based"
-- 
1.7.1

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Uwe Kleine-König]

Hello Sascha,

On Thu, Mar 03, 2011 at 01:11:53PM +0100, Sascha Hauer wrote:
>  config SOC_IMX27
>  	bool
> +	select ARCH_MX2
> +	select MACH_MX27
I'd let MACH_MX27 select ARCH_MX2, but that's just a minor detail.

>  	select CPU_ARM926T
>  	select ARCH_MXC_AUDMUX_V1
>  	select IMX_HAVE_DMA_V1
>  	select IMX_HAVE_IOMUX_V1
>  	select MXC_AVIC
>  
> -if ARCH_MX1
> +config IMX_MULTI_ARCHITECTURE
> +	bool "i.MX multi architecture support"
> +	depends on ARM_PATCH_PHYS_VIRT
> +	depends on AUTO_ZRELADDR
depends on EXPERIMENTAL?

> +
> +if IMX_MULTI_ARCHITECTURE
> +config ARCH_IMX_MULTI_MX1
> +	select SOC_IMX1
> +	bool "i.MX1 support"
> +
> +config ARCH_IMX_MULTI_MX21
> +	select SOC_IMX21
> +	bool "i.MX21 support"
> +
> +config ARCH_IMX_MULTI_MX25
> +	select SOC_IMX25
> +	bool "i.MX25 support"
> +
> +config ARCH_IMX_MULTI_MX27
> +	select SOC_IMX27
> +	bool "i.MX27 support"
I'm not sure it's a good idea to use SOC_IMX21 et al for both, Kconfig
logic to select machines and to signal there are machines selected with
the correspondig soc.

On reason is that selecting ARCH_IMX_MULTI_MX21 and ARCH_IMX_MULTI_MX27
but no i.MX21 based machine currently makes cpu_is_mx27() more (runtime)
complicated than necessary.

Just judging the UI it looks good.  (I.e. I like the explicit "i.MX
multi architecture support" knob.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Sascha Hauer]

On Thu, Mar 03, 2011 at 05:25:13PM +0100, Uwe Kleine-K?nig wrote:
> Hello Sascha,
> 
> On Thu, Mar 03, 2011 at 01:11:53PM +0100, Sascha Hauer wrote:
> >  config SOC_IMX27
> >  	bool
> > +	select ARCH_MX2
> > +	select MACH_MX27
> I'd let MACH_MX27 select ARCH_MX2, but that's just a minor detail.
> 
> >  	select CPU_ARM926T
> >  	select ARCH_MXC_AUDMUX_V1
> >  	select IMX_HAVE_DMA_V1
> >  	select IMX_HAVE_IOMUX_V1
> >  	select MXC_AVIC
> >  
> > -if ARCH_MX1
> > +config IMX_MULTI_ARCHITECTURE
> > +	bool "i.MX multi architecture support"
> > +	depends on ARM_PATCH_PHYS_VIRT
> > +	depends on AUTO_ZRELADDR
> depends on EXPERIMENTAL?

ARM_PATCH_PHYS_VIRT depends on EXPERIMENTAL already. I think once
ARM_PATCH_PHYS_VIRT is considered stable, we can consider i.MX
multiarchitecture support stable aswell.

> 
> > +
> > +if IMX_MULTI_ARCHITECTURE
> > +config ARCH_IMX_MULTI_MX1
> > +	select SOC_IMX1
> > +	bool "i.MX1 support"
> > +
> > +config ARCH_IMX_MULTI_MX21
> > +	select SOC_IMX21
> > +	bool "i.MX21 support"
> > +
> > +config ARCH_IMX_MULTI_MX25
> > +	select SOC_IMX25
> > +	bool "i.MX25 support"
> > +
> > +config ARCH_IMX_MULTI_MX27
> > +	select SOC_IMX27
> > +	bool "i.MX27 support"
> I'm not sure it's a good idea to use SOC_IMX21 et al for both, Kconfig
> logic to select machines and to signal there are machines selected with
> the correspondig soc.
> 
> On reason is that selecting ARCH_IMX_MULTI_MX21 and ARCH_IMX_MULTI_MX27
> but no i.MX21 based machine currently makes cpu_is_mx27() more (runtime)
> complicated than necessary.

Then there's no reason to select IMX_MULTI_ARCHITECTURE in the first
place. What are the other reasons?

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Uwe Kleine-König]

[I dropped freescale at lists.linaro.org from Cc: because that's a
members-only list.]

Hello Sascha,

On Thu, Mar 03, 2011 at 07:00:26PM +0100, Sascha Hauer wrote:
> On Thu, Mar 03, 2011 at 05:25:13PM +0100, Uwe Kleine-K?nig wrote:
> > On Thu, Mar 03, 2011 at 01:11:53PM +0100, Sascha Hauer wrote:
> > > +config IMX_MULTI_ARCHITECTURE
> > > +	bool "i.MX multi architecture support"
> > > +	depends on ARM_PATCH_PHYS_VIRT
> > > +	depends on AUTO_ZRELADDR
> > depends on EXPERIMENTAL?
> 
> ARM_PATCH_PHYS_VIRT depends on EXPERIMENTAL already. I think once
> ARM_PATCH_PHYS_VIRT is considered stable, we can consider i.MX
> multiarchitecture support stable aswell.
right.

> > > +
> > > +if IMX_MULTI_ARCHITECTURE
> > > +config ARCH_IMX_MULTI_MX1
> > > +	select SOC_IMX1
> > > +	bool "i.MX1 support"
> > > +
> > > +config ARCH_IMX_MULTI_MX21
> > > +	select SOC_IMX21
> > > +	bool "i.MX21 support"
> > > +
> > > +config ARCH_IMX_MULTI_MX25
> > > +	select SOC_IMX25
> > > +	bool "i.MX25 support"
> > > +
> > > +config ARCH_IMX_MULTI_MX27
> > > +	select SOC_IMX27
> > > +	bool "i.MX27 support"
> > I'm not sure it's a good idea to use SOC_IMX21 et al for both, Kconfig
> > logic to select machines and to signal there are machines selected with
> > the correspondig soc.
> > 
> > On reason is that selecting ARCH_IMX_MULTI_MX21 and ARCH_IMX_MULTI_MX27
> > but no i.MX21 based machine currently makes cpu_is_mx27() more (runtime)
> > complicated than necessary.
> 
> Then there's no reason to select IMX_MULTI_ARCHITECTURE in the first
> place. What are the other reasons?
Right, it's not sensible to do this selection, but the fact that it is
possible makes me feel it's ugly. I thought a bit more about that I and
another reason for not using SOC_IMXxy for Kconfig is that it might be
natural to group i.MX50 and i.MX53 together because they share the same
PHYS_OFFSET. So there are three possibilities:

 1) group them using a symbol named SOC_IMX50_IMX53
 2) select both SOC_IMX50 and SOC_IMX53 independant of the machines
    enabled.
 3) don't allow to build both SoCs into a single image without
    IMX_MULTI_ARCHITECTURE

2) is similar to my first suggestion---it might make things more
complicated than necessary at runtime. 3) is a limitation that shouldn't
be needed. So 1) is the best? Then I prefer to have a completly
different naming scheme for the grouping.

Does this make sense?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Sascha Hauer]

On Thu, Mar 03, 2011 at 09:10:09PM +0100, Uwe Kleine-K?nig wrote:
> Right, it's not sensible to do this selection, but the fact that it is
> possible makes me feel it's ugly. I thought a bit more about that I and
> another reason for not using SOC_IMXxy for Kconfig is that it might be
> natural to group i.MX50 and i.MX53 together because they share the same
> PHYS_OFFSET. So there are three possibilities:
> 
>  1) group them using a symbol named SOC_IMX50_IMX53
>  2) select both SOC_IMX50 and SOC_IMX53 independant of the machines
>     enabled.
>  3) don't allow to build both SoCs into a single image without
>     IMX_MULTI_ARCHITECTURE
> 
> 2) is similar to my first suggestion---it might make things more
> complicated than necessary at runtime. 3) is a limitation that shouldn't
> be needed. So 1) is the best? Then I prefer to have a completly
> different naming scheme for the grouping.
> 
> Does this make sense?

Lets give it a try. How does the following look like? Note I also skipped
The explicit IMX_MULTI_ARCHITECTURE switch and depend on
ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR directly instead.

8<---------------------------------------

ARM i.MX: Allow to compile armv4 and armv5 based i.MX SoCs in a single kernel

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/Kconfig |  109 +++++++++++++++++++++++++++++++++++----------
 arch/arm/plat-mxc/Kconfig |   17 +------
 2 files changed, 88 insertions(+), 38 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 5eec099..932084c 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -1,8 +1,28 @@
+if ARCH_IMX
+
 config IMX_HAVE_DMA_V1
 	bool
 
+# obsolete: The MACH_MX/ARCH_MX should go away once the users
+# are moved to the corresponding SOC_IMX_* in the tree
+config MACH_MX21
+	bool
+
+config MACH_MX27
+	bool
+
+config ARCH_MX25
+	bool
+
+config ARCH_MX2
+	bool
+
+config ARCH_MX1
+	bool
+
 config SOC_IMX1
 	bool
+	select ARCH_MX1
 	select CPU_ARM920T
 	select IMX_HAVE_DMA_V1
 	select IMX_HAVE_IOMUX_V1
@@ -10,6 +30,8 @@ config SOC_IMX1
 
 config SOC_IMX21
 	bool
+	select MACH_MX21
+	select ARCH_MX2
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V1
 	select IMX_HAVE_DMA_V1
@@ -18,6 +40,7 @@ config SOC_IMX21
 
 config SOC_IMX25
 	bool
+	select ARCH_MX25
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V2
 	select ARCH_MXC_IOMUX_V3
@@ -25,13 +48,68 @@ config SOC_IMX25
 
 config SOC_IMX27
 	bool
+	select ARCH_MX2
+	select MACH_MX27
 	select CPU_ARM926T
 	select ARCH_MXC_AUDMUX_V1
 	select IMX_HAVE_DMA_V1
 	select IMX_HAVE_IOMUX_V1
 	select MXC_AVIC
 
-if ARCH_MX1
+config ARCH_ALLOW_IMX1
+	bool
+
+config ARCH_ALLOW_IMX21
+	bool
+
+config ARCH_ALLOW_IMX25
+	bool
+
+config ARCH_ALLOW_IMX27
+	bool
+
+if ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR
+config ARCH_IMX_MULTI_IMX1
+	select ARCH_ALLOW_IMX1
+	bool "i.MX1 support"
+
+config ARCH_IMX_MULTI_IMX21
+	select ARCH_ALLOW_IMX21
+	bool "i.MX21 support"
+
+config ARCH_IMX_MULTI_IMX25
+	select ARCH_ALLOW_IMX25
+	bool "i.MX25 support"
+
+config ARCH_IMX_MULTI_OMX27
+	select ARCH_ALLOW_IMX27
+	bool "i.MX27 support"
+endif
+
+if !(ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR)
+comment "enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR to get"
+comment "support for multiple i.MX Families"
+choice
+	prompt "Select i.MX CPU"
+config ARCH_IMX_ONLY_IMX1
+	select ARCH_ALLOW_IMX1
+	bool "i.MX1 support"
+
+config ARCH_IMX_ONLY_IMX21
+	select ARCH_ALLOW_IMX21
+	bool "i.MX21 support"
+
+config ARCH_IMX_ONLY_IMX25
+	select ARCH_ALLOW_IMX25
+	bool "i.MX25 support"
+
+config ARCH_IMX_ONLY_IMX27
+	select ARCH_ALLOW_IMX27
+	bool "i.MX27 support"
+endchoice
+endif
+
+if ARCH_ALLOW_IMX1
 
 comment "MX1 platforms:"
 config MACH_MXLADS
@@ -39,6 +117,7 @@ config MACH_MXLADS
 
 config ARCH_MX1ADS
 	bool "MX1ADS platform"
+	select SOC_IMX1
 	select MACH_MXLADS
 	select IMX_HAVE_PLATFORM_IMX_I2C
 	select IMX_HAVE_PLATFORM_IMX_UART
@@ -48,32 +127,13 @@ config ARCH_MX1ADS
 config MACH_SCB9328
 	bool "Synertronixx scb9328"
 	select IMX_HAVE_PLATFORM_IMX_UART
+	select SOC_IMX1
 	help
 	  Say Y here if you are using a Synertronixx scb9328 board
 
 endif
 
-if ARCH_MX2
-
-choice
-	prompt "CPUs:"
-	default MACH_MX21
-
-config MACH_MX21
-	bool "i.MX21 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX21 processor.
-
-config MACH_MX27
-	bool "i.MX27 support"
-	help
-	  This enables support for Freescale's MX2 based i.MX27 processor.
-
-endchoice
-
-endif
-
-if MACH_MX21
+if ARCH_ALLOW_IMX21
 
 comment "MX21 platforms:"
 
@@ -90,7 +150,7 @@ config MACH_MX21ADS
 
 endif
 
-if ARCH_MX25
+if ARCH_ALLOW_IMX25
 
 comment "MX25 platforms:"
 
@@ -138,7 +198,7 @@ endchoice
 
 endif
 
-if MACH_MX27
+if ARCH_ALLOW_IMX27
 
 comment "MX27 platforms:"
 
@@ -313,3 +373,4 @@ config MACH_IMX27IPCAM
 	  configurations for the board and its peripherals.
 
 endif
+endif
diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
index b0cb425..5625e78 100644
--- a/arch/arm/plat-mxc/Kconfig
+++ b/arch/arm/plat-mxc/Kconfig
@@ -8,21 +8,10 @@ choice
 	prompt "Freescale CPU family:"
 	default ARCH_MX3
 
-config ARCH_MX1
-	bool "MX1-based"
-	select SOC_IMX1
+config ARCH_IMX
+	bool "i.MX1, i.MX21, i.MX25, i.MX27 based"
 	help
-	  This enables support for systems based on the Freescale i.MX1 family
-
-config ARCH_MX2
-	bool "MX2-based"
-	help
-	  This enables support for systems based on the Freescale i.MX2 family
-
-config ARCH_MX25
-	bool "MX25-based"
-	help
-	  This enables support for systems based on the Freescale i.MX25 family
+	  This enables support for systems based on the Freescale i.MX1/2 family
 
 config ARCH_MX3
 	bool "MX3-based"
-- 
1.7.2.3

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Uwe Kleine-König]

On Fri, Mar 04, 2011 at 09:19:16AM +0100, Sascha Hauer wrote:
> On Thu, Mar 03, 2011 at 09:10:09PM +0100, Uwe Kleine-K?nig wrote:
> > Right, it's not sensible to do this selection, but the fact that it is
> > possible makes me feel it's ugly. I thought a bit more about that I and
> > another reason for not using SOC_IMXxy for Kconfig is that it might be
> > natural to group i.MX50 and i.MX53 together because they share the same
> > PHYS_OFFSET. So there are three possibilities:
> > 
> >  1) group them using a symbol named SOC_IMX50_IMX53
> >  2) select both SOC_IMX50 and SOC_IMX53 independant of the machines
> >     enabled.
> >  3) don't allow to build both SoCs into a single image without
> >     IMX_MULTI_ARCHITECTURE
> > 
> > 2) is similar to my first suggestion---it might make things more
> > complicated than necessary at runtime. 3) is a limitation that shouldn't
> > be needed. So 1) is the best? Then I prefer to have a completly
> > different naming scheme for the grouping.
> > 
> > Does this make sense?
> 
> Lets give it a try. How does the following look like? Note I also skipped
> The explicit IMX_MULTI_ARCHITECTURE switch and depend on
> ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR directly instead.
ok

> 8<---------------------------------------
> 
> ARM i.MX: Allow to compile armv4 and armv5 based i.MX SoCs in a single kernel
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  arch/arm/mach-imx/Kconfig |  109 +++++++++++++++++++++++++++++++++++----------
>  arch/arm/plat-mxc/Kconfig |   17 +------
>  2 files changed, 88 insertions(+), 38 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 5eec099..932084c 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -1,8 +1,28 @@
> +if ARCH_IMX
> +
>  config IMX_HAVE_DMA_V1
>  	bool
>  
> +# obsolete: The MACH_MX/ARCH_MX should go away once the users
> +# are moved to the corresponding SOC_IMX_* in the tree
> +config MACH_MX21
> +	bool
> +
> +config MACH_MX27
> +	bool
> +
> +config ARCH_MX25
> +	bool
> +
> +config ARCH_MX2
> +	bool
> +
> +config ARCH_MX1
> +	bool
> +
>  config SOC_IMX1
>  	bool
> +	select ARCH_MX1
>  	select CPU_ARM920T
>  	select IMX_HAVE_DMA_V1
>  	select IMX_HAVE_IOMUX_V1
> @@ -10,6 +30,8 @@ config SOC_IMX1
>  
>  config SOC_IMX21
>  	bool
> +	select MACH_MX21
> +	select ARCH_MX2
>  	select CPU_ARM926T
>  	select ARCH_MXC_AUDMUX_V1
>  	select IMX_HAVE_DMA_V1
> @@ -18,6 +40,7 @@ config SOC_IMX21
>  
>  config SOC_IMX25
>  	bool
> +	select ARCH_MX25
>  	select CPU_ARM926T
>  	select ARCH_MXC_AUDMUX_V2
>  	select ARCH_MXC_IOMUX_V3
> @@ -25,13 +48,68 @@ config SOC_IMX25
>  
>  config SOC_IMX27
>  	bool
> +	select ARCH_MX2
> +	select MACH_MX27
>  	select CPU_ARM926T
>  	select ARCH_MXC_AUDMUX_V1
>  	select IMX_HAVE_DMA_V1
>  	select IMX_HAVE_IOMUX_V1
>  	select MXC_AVIC
>  
> -if ARCH_MX1
> +config ARCH_ALLOW_IMX1
> +	bool
> +
> +config ARCH_ALLOW_IMX21
> +	bool
> +
> +config ARCH_ALLOW_IMX25
> +	bool
> +
> +config ARCH_ALLOW_IMX27
> +	bool
> +
> +if ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR
> +config ARCH_IMX_MULTI_IMX1
> +	select ARCH_ALLOW_IMX1
> +	bool "i.MX1 support"
> +
> +config ARCH_IMX_MULTI_IMX21
> +	select ARCH_ALLOW_IMX21
> +	bool "i.MX21 support"
> +
> +config ARCH_IMX_MULTI_IMX25
> +	select ARCH_ALLOW_IMX25
> +	bool "i.MX25 support"
> +
> +config ARCH_IMX_MULTI_OMX27
> +	select ARCH_ALLOW_IMX27
> +	bool "i.MX27 support"
> +endif
> +
> +if !(ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR)
> +comment "enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR to get"
> +comment "support for multiple i.MX Families"
> +choice
> +	prompt "Select i.MX CPU"
> +config ARCH_IMX_ONLY_IMX1
> +	select ARCH_ALLOW_IMX1
> +	bool "i.MX1 support"
> +
> +config ARCH_IMX_ONLY_IMX21
> +	select ARCH_ALLOW_IMX21
> +	bool "i.MX21 support"
> +
> +config ARCH_IMX_ONLY_IMX25
> +	select ARCH_ALLOW_IMX25
> +	bool "i.MX25 support"
> +
> +config ARCH_IMX_ONLY_IMX27
> +	select ARCH_ALLOW_IMX27
> +	bool "i.MX27 support"
> +endchoice
> +endif
> +
> +if ARCH_ALLOW_IMX1
>  
>  comment "MX1 platforms:"
>  config MACH_MXLADS
> @@ -39,6 +117,7 @@ config MACH_MXLADS
>  
>  config ARCH_MX1ADS
>  	bool "MX1ADS platform"
> +	select SOC_IMX1
>  	select MACH_MXLADS
>  	select IMX_HAVE_PLATFORM_IMX_I2C
>  	select IMX_HAVE_PLATFORM_IMX_UART
> @@ -48,32 +127,13 @@ config ARCH_MX1ADS
>  config MACH_SCB9328
>  	bool "Synertronixx scb9328"
>  	select IMX_HAVE_PLATFORM_IMX_UART
> +	select SOC_IMX1
>  	help
>  	  Say Y here if you are using a Synertronixx scb9328 board
>  
>  endif
>  
> -if ARCH_MX2
> -
> -choice
> -	prompt "CPUs:"
> -	default MACH_MX21
> -
> -config MACH_MX21
> -	bool "i.MX21 support"
> -	help
> -	  This enables support for Freescale's MX2 based i.MX21 processor.
> -
> -config MACH_MX27
> -	bool "i.MX27 support"
> -	help
> -	  This enables support for Freescale's MX2 based i.MX27 processor.
> -
> -endchoice
> -
> -endif
> -
> -if MACH_MX21
> +if ARCH_ALLOW_IMX21
>  
>  comment "MX21 platforms:"
>  
> @@ -90,7 +150,7 @@ config MACH_MX21ADS
>  
>  endif
>  
> -if ARCH_MX25
> +if ARCH_ALLOW_IMX25
>  
>  comment "MX25 platforms:"
>  
> @@ -138,7 +198,7 @@ endchoice
>  
>  endif
>  
> -if MACH_MX27
> +if ARCH_ALLOW_IMX27
>  
>  comment "MX27 platforms:"
>  
> @@ -313,3 +373,4 @@ config MACH_IMX27IPCAM
>  	  configurations for the board and its peripherals.
>  
>  endif
> +endif
> diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
> index b0cb425..5625e78 100644
> --- a/arch/arm/plat-mxc/Kconfig
> +++ b/arch/arm/plat-mxc/Kconfig
> @@ -8,21 +8,10 @@ choice
>  	prompt "Freescale CPU family:"
>  	default ARCH_MX3
>  
> -config ARCH_MX1
> -	bool "MX1-based"
> -	select SOC_IMX1
> +config ARCH_IMX
> +	bool "i.MX1, i.MX21, i.MX25, i.MX27 based"
>  	help
> -	  This enables support for systems based on the Freescale i.MX1 family
> -
> -config ARCH_MX2
> -	bool "MX2-based"
> -	help
> -	  This enables support for systems based on the Freescale i.MX2 family
> -
> -config ARCH_MX25
> -	bool "MX25-based"
> -	help
> -	  This enables support for systems based on the Freescale i.MX25 family
> +	  This enables support for systems based on the Freescale i.MX1/2 family
>  
>  config ARCH_MX3
>  	bool "MX3-based"
Looks fine.  I will test it when I'm done with my 'move mx3 to mach-imx'
patch.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Uwe Kleine-König]

Hello,

On Fri, Mar 04, 2011 at 09:19:16AM +0100, Sascha Hauer wrote:
> On Thu, Mar 03, 2011 at 09:10:09PM +0100, Uwe Kleine-K?nig wrote:
> > Right, it's not sensible to do this selection, but the fact that it is
> > possible makes me feel it's ugly. I thought a bit more about that I and
> > another reason for not using SOC_IMXxy for Kconfig is that it might be
> > natural to group i.MX50 and i.MX53 together because they share the same
> > PHYS_OFFSET. So there are three possibilities:
> > 
> >  1) group them using a symbol named SOC_IMX50_IMX53
> >  2) select both SOC_IMX50 and SOC_IMX53 independant of the machines
> >     enabled.
> >  3) don't allow to build both SoCs into a single image without
> >     IMX_MULTI_ARCHITECTURE
> > 
> > 2) is similar to my first suggestion---it might make things more
> > complicated than necessary at runtime. 3) is a limitation that shouldn't
> > be needed. So 1) is the best? Then I prefer to have a completly
> > different naming scheme for the grouping.
> > 
> > Does this make sense?
> 
> Lets give it a try. How does the following look like? Note I also skipped
> The explicit IMX_MULTI_ARCHITECTURE switch and depend on
> ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR directly instead.
> 
> 8<---------------------------------------
> 
> ARM i.MX: Allow to compile armv4 and armv5 based i.MX SoCs in a single kernel
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  arch/arm/mach-imx/Kconfig |  109 +++++++++++++++++++++++++++++++++++----------
>  arch/arm/plat-mxc/Kconfig |   17 +------
>  2 files changed, 88 insertions(+), 38 deletions(-)

I tested a bit and I noticed this patch breaks defconfigs for mx1, mx21
and mx27. To fix that you might want to squash the following in:

diff --git a/arch/arm/configs/mx1_defconfig b/arch/arm/configs/mx1_defconfig
index b39b5ce..10134da 100644
--- a/arch/arm/configs/mx1_defconfig
+++ b/arch/arm/configs/mx1_defconfig
@@ -12,7 +12,7 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_ARCH_MXC=y
-CONFIG_ARCH_MX1=y
+CONFIG_ARCH_IMX=y
 CONFIG_ARCH_MX1ADS=y
 CONFIG_MACH_SCB9328=y
 CONFIG_MXC_IRQ_PRIOR=y
diff --git a/arch/arm/configs/mx21_defconfig b/arch/arm/configs/mx21_defconfig
index 411f88d..1b31b83 100644
--- a/arch/arm/configs/mx21_defconfig
+++ b/arch/arm/configs/mx21_defconfig
@@ -13,7 +13,8 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_MXC=y
-CONFIG_ARCH_MX2=y
+CONFIG_ARCH_IMX=y
+CONFIG_ARCH_IMX_ONLY_IMX21=y
 CONFIG_MACH_MX21ADS=y
 CONFIG_MXC_PWM=y
 CONFIG_NO_HZ=y
diff --git a/arch/arm/configs/mx27_defconfig b/arch/arm/configs/mx27_defconfig
index 9ad4c656..a95b074 100644
--- a/arch/arm/configs/mx27_defconfig
+++ b/arch/arm/configs/mx27_defconfig
@@ -17,8 +17,8 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_MXC=y
-CONFIG_ARCH_MX2=y
-CONFIG_MACH_MX27=y
+CONFIG_ARCH_IMX=y
+CONFIG_ARCH_IMX_ONLY_IMX27=y
 CONFIG_MACH_MX27ADS=y
 CONFIG_MACH_PCM038=y
 CONFIG_MACH_CPUIMX27=y

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice

[Uwe Kleine-König]

[added linux-kbuild to Cc:]

Hello,

yet another reply to your mail, the last one for today, I promise.

> +config ARCH_IMX_MULTI_OMX27
> +	select ARCH_ALLOW_IMX27
> +	bool "i.MX27 support"
s/OMX/IMX/

Other than that is works.  One ugly thing about that patch is that when
starting with

 ?       *** enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR to get *** ?
 ?       *** support for multiple i.MX Families ***                  ?
 ?       Select i.MX CPU (i.MX27 support)  --->                      ?
 ?     *** MX27 platforms: ***                                       ?
 ? [*] MX27ADS platform                                              ?
 ? [*] Phytec phyCORE-i.MX27 CPU module (pcm038)                     ?

and then enabling ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR this yields

 ? [ ]   i.MX1 support (NEW)                                         ?
 ? [ ]   i.MX21 support (NEW)                                        ?
 ? [ ]   i.MX25 support (NEW)                                        ?
 ? [ ]   i.MX27 support (NEW)                                        ?
 ? [ ]   i.MX31 and i.MX35 support (NEW)                             ?

.

At least the machines enabled before are reselected when enabling "i.MX27
support". Still it would be nice if "i.MX27 support" would be
autoselected in this case. Any ideas?
[For those that didn't see Sascha's patch, the construct in
arch/arm/mach-imx/Kconfig is:

	config ARCH_ALLOW_IMX1
		bool

	config ARCH_ALLOW_IMX21
		bool
	...

	if ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR
	config ARCH_IMX_MULTI_IMX1
		select ARCH_ALLOW_IMX1
		bool "i.MX1 support"

	config ARCH_IMX_MULTI_IMX21
		select ARCH_ALLOW_IMX21
		bool "i.MX21 support"
	...
	endif

	if !(ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR)
	choice
		prompt "Select i.MX CPU"
	config ARCH_IMX_ONLY_IMX1
		select ARCH_ALLOW_IMX1
		bool "i.MX1 support"

	config ARCH_IMX_ONLY_IMX21
		select ARCH_ALLOW_IMX21
		bool "i.MX21 support"
	...
	endchoice
	endif
]

I merged Sascha's patch into my "move mach-mx3/* to mach-imx" series;
the tree is provided at

	git://git.pengutronix.de/git/ukl/linux-2.6.git multi-soc-kernel

. As this tree doesn't contain ARM_PATCH_PHYS_VIRT yet, I tested the UI
with the patch below.

Best regards
Uwe

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index cfc398a..f5e0638 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -106,6 +106,9 @@ config ARCH_ALLOW_IMX31
 config ARCH_ALLOW_IMX35
 	bool
 
+config ARM_PATCH_PHYS_VIRT
+	bool "testme"
+
 if ARM_PATCH_PHYS_VIRT && AUTO_ZRELADDR
 config ARCH_IMX_MULTI_IMX1
 	select ARCH_ALLOW_IMX1

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |