From: Richard Zhao <hidden> Date: 2011-03-02 03:28:46
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 <redacted>
@@ -1,14 +1,4 @@ifARCH_MX5-# ARCH_MX51 and ARCH_MX50 are left for compatibility--configARCH_MX50-bool--configARCH_MX51-bool--configARCH_MX53-boolconfigSOC_IMX50bool
@@ -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)
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.
@@ -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)
From: Richard Zhao <hidden> Date: 2011-03-02 16:06:05
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:
quoted
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?
@@ -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)
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:
quoted
Hello Richard,
On Wed, Mar 02, 2011 at 11:28:46AM +0800, Richard Zhao wrote:
quoted
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
quoted
- 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.
quoted
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/ |
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 <redacted>
---
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(-)
@@ -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
@@ -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
@@ -2,6 +2,10 @@ if ARCH_MXCsource"arch/arm/plat-mxc/devices/Kconfig"+configARCH_MX2+# don't use this in new code+bool+menu"Freescale MXC Implementations"choice
@@ -14,16 +18,25 @@ config ARCH_MX1helpThisenablessupportforsystemsbasedontheFreescalei.MX1family-configARCH_MX2-bool"MX2-based"+configMACH_MX21+bool"MX21-based"+selectARCH_MX2help-ThisenablessupportforsystemsbasedontheFreescalei.MX2family+ThisenablessupportforsystemsbasedontheFreescalei.MX21familyconfigARCH_MX25bool"MX25-based"+# note that i.MX25 doesn't match the expectations that are currently+# called ARCH_MX2helpThisenablessupportforsystemsbasedontheFreescalei.MX25family+configMACH_MX27+bool"MX27-based"+selectARCH_MX2+help+ThisenablessupportforFreescale'sMX2basedi.MX27processor.+configARCH_MX3bool"MX3-based"selectCPU_V6
From: Richard Zhao <hidden> Date: 2011-03-03 05:26:54
Hi Uwe,
On Wed, Mar 02, 2011 at 06:23:05PM +0100, Uwe Kleine-K?nig wrote:
quoted hunk
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 <redacted>
---
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(-)
@@ -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
@@ -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
@@ -2,6 +2,10 @@ if ARCH_MXCsource"arch/arm/plat-mxc/devices/Kconfig"+configARCH_MX2+# don't use this in new code+bool+menu"Freescale MXC Implementations"choice
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
From: Richard Zhao <hidden> Date: 2011-03-03 06:17:06
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:
quoted
Hi Uwe,
Thanks for your detailed explanation!
On Wed, Mar 02, 2011 at 12:25:59PM +0100, Uwe Kleine-K?nig wrote:
quoted
Hello Richard,
On Wed, Mar 02, 2011 at 11:28:46AM +0800, Richard Zhao wrote:
quoted
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.
quoted
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
quoted
quoted
- 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
quoted
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.
quoted
quoted
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
quoted
Maybe the p2v patch can help?
Indeed.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
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:
quoted
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 <redacted>
quoted
-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/ |
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(-)
@@ -1,8 +1,28 @@+ifARCH_IMX+configIMX_HAVE_DMA_V1bool+# obsolete: The MACH_MX/ARCH_MX should go away once the users+# are moved to the corresponding SOC_IMX_* in the tree+configMACH_MX21+bool++configMACH_MX27+bool++configARCH_MX25+bool++configARCH_MX2+bool++configARCH_MX1+bool+configSOC_IMX1bool+selectARCH_MX1selectCPU_ARM920TselectIMX_HAVE_DMA_V1selectIMX_HAVE_IOMUX_V1
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/ |
I'd let MACH_MX27 select ARCH_MX2, but that's just a minor detail.
quoted
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.
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 |
[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.
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/ |
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(-)
@@ -1,8 +1,28 @@+ifARCH_IMX+configIMX_HAVE_DMA_V1bool+# obsolete: The MACH_MX/ARCH_MX should go away once the users+# are moved to the corresponding SOC_IMX_* in the tree+configMACH_MX21+bool++configMACH_MX27+bool++configARCH_MX25+bool++configARCH_MX2+bool++configARCH_MX1+bool+configSOC_IMX1bool+selectARCH_MX1selectCPU_ARM920TselectIMX_HAVE_DMA_V1selectIMX_HAVE_IOMUX_V1
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:
quoted
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
quoted hunk
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(-)
@@ -1,8 +1,28 @@+ifARCH_IMX+configIMX_HAVE_DMA_V1bool+# obsolete: The MACH_MX/ARCH_MX should go away once the users+# are moved to the corresponding SOC_IMX_* in the tree+configMACH_MX21+bool++configMACH_MX27+bool++configARCH_MX25+bool++configARCH_MX2+bool++configARCH_MX1+bool+configSOC_IMX1bool+selectARCH_MX1selectCPU_ARM920TselectIMX_HAVE_DMA_V1selectIMX_HAVE_IOMUX_V1
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/ |
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:
quoted
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:
@@ -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
@@ -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
@@ -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/ |
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