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.pitre@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.pitre@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