On Wed, 1 Sep 2010, Amit Kucheria wrote:
> On 10 Sep 01, Loïc Minier wrote:
> > On Wed, Sep 01, 2010, Amit Kucheria wrote:
> > > That patch likely won't go upstream.
> >
> > Why not?
>
> Because it adds a sub-arch, revision-specific override into generic
> architecture code (vfpmodule.c)
>
> To do this elegantly with a hope to get it to mainline, we'd need a way to
> disable the hwcap through some board-specific fixup code that can check the
> revision of the board at runtime.
Right. I eventually dismissed that idea on the basis that the silicon
revision in question was pre production stuff. But if there are actual
devices out there using it then we need something for it that is
mainline acceptable.
> Unfortunately, it seems after talking to Nicolas that mdesc->fixup() is
> called too early.
>
> Nicolas suggested linking the i.MX5 code _after_ the VFP module :)
Something like this patch:
----- >8
From: Nicolas Pitre <nicolas.pi...@linaro.org>
Date: Wed, 1 Sep 2010 09:37:05 -0400
Subject: [PATCH] ARM: link board specific files after core files
This allows for board specific issues to override decisions made in generic
code that might not be suitable due to some errata or the like.
Signed-off-by: Nicolas Pitre <nicolas.pi...@linaro.org>
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index df4ab3c..3e8e3d7 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -243,13 +243,14 @@ ifeq ($(FASTFPE),$(wildcard $(FASTFPE)))
FASTFPE_OBJ :=$(FASTFPE)/
endif
-# If we have a machine-specific directory, then include it in the build.
-core-y += arch/arm/kernel/ arch/arm/mm/
arch/arm/common/
-core-y += $(machdirs) $(platdirs)
core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/
core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ)
core-$(CONFIG_VFP) += arch/arm/vfp/
+# If we have a machine-specific directory, then include it in the build.
+core-y += arch/arm/kernel/ arch/arm/mm/
arch/arm/common/
+core-y += $(machdirs) $(platdirs)
+
drivers-$(CONFIG_OPROFILE) += arch/arm/oprofile/
libs-y := arch/arm/lib/ $(libs-y)
8< -----
Then, just add your fixup in a separate patch. Beware: the above patch
is untested.
> Another solution is that we could perhaps add code in the board init function
> to check the cpu revision and if NEON was enabled, then stop booting.
That is a bit blunt for the user though, and that forces a different
kernel config depending on the silicon revision which is also bad.
Nicolas
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
