On Thu, May 02, 2013 at 10:46:21AM +0100, Russell King - ARM Linux wrote: > On Thu, May 02, 2013 at 09:34:30AM +0100, Russell King - ARM Linux wrote: > > On Tue, Apr 30, 2013 at 02:18:42PM -0400, Nicolas Pitre wrote: > > > On Tue, 30 Apr 2013, Dave Martin wrote: > > > > > > > On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote: > > > > > On Tue, 30 Apr 2013, Dave Martin wrote: > > > > > > > > > > > On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote: > > > > > > > On Tuesday 30 April 2013, Russell King - ARM Linux wrote: > > > > > > > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a > > > > > > > > great load of new warnings and errors. arch/arm/common/mcpm_head.S, > > > > > > > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest > > > > > > > > source of errors. > > > > > > > > > > > > [...] > > > > > > > > > > > > > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8' > > > > > > > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8' > > > > > > > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb' > > > > > > > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb' > > > > > > > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb' > > > > > > > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb' > > > > > > > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb' > > > > > > > > > > > > > > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config. > > > > > > > We can either fix it up by adding > > > > > > > > > > > > > > .arch armv7-a > > > > > > > > > > > > > > in the assembly files, or by doing the same in the Makefile: > > > > > > > > > > > > > > AFLAGS_vlock.S += -march=armv7-a > > > > > > > AFLAGS_mcpm_head.S += -march=armv7-a > > > > > > > > > > > > > > > > > > Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like > > > > > > no v6 boards were configured in when testing that... > > > > > > > > > > > > > > > > > > Assuming people are OK with the Makefile route, here's a patch for that, > > > > > > build-tested with a v6+v7 ARCH_MULTIPLATFORM config. > > > > > > > > > > Isn't the .arch armv7-a route a bit cleaner? That would have been my > > > > > choice, although I don't feel strongly about it. > > > > > > > > I don't feel strongly either. We already have the CFLAGS_DISABLE stuff, > > > > so it didn't feel that unnatural to add this in the Makefile; but .arch > > > > would work equally well. > > > > > > > > If somebody wants to change it, it's not a problem for me, but I didn't > > > > want to create extra disruption by proposing a different patch... > > > > > > Fair enough. > > > > > > Acked-by: Nicolas Pitre <nico@xxxxxxxxxx> > > > > I see Dave Martin has sent a patch for this without your ack. Was that > > a mistake? My bad -- Nico asked me to send you the patch, but I neglected to add his ack. > ... and the patch in the patch system doesn't apply anyway because its > against some other tree. I've no idea what it's against, it's not as > the version on the patch advertises (v3.9-rc7) and not even the build > tree has the three additional FIQ lines at the end (so it's not in > arm-soc): > > obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o > obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o > obj-$(CONFIG_MCPM) += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock... > +AFLAGS_mcpm_head.o := -march=armv7-a > +AFLAGS_vlock.o := -march=armv7-a > CFLAGS_REMOVE_mcpm_entry.o = -pg > obj-$(CONFIG_FIQ_GLUE) += fiq_glue.o fiq_glue_setup.o > obj-$(CONFIG_FIQ_DEBUGGER) += fiq_debugger.o > > So, this is unapplyable. ...and this was a plain screwup up my part. v3.9* could not possibly contain the relevant patches, but somehow I convinced myself I had test- applied the patch on 3.9-rc7, instead of a local tree based on that. I've sent you a patch based on devel-stable which should apply. Apologies for the churn. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
