[RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X
Uwe Kleine-König
u.kleine-koenig at pengutronix.de
Wed Mar 2 11:33:26 EST 2011
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/ |
More information about the linux-arm-kernel
mailing list