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

[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:

quoted

On Thu, Mar 03, 2011 at 01:11:53PM +0100, Sascha Hauer wrote:

quoted

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

quoted

quoted

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