On Tue, Jul 10, 2012 at 14:11:08, Tony Lindgren wrote:
> * Hiremath, Vaibhav <hvaibhav@xxxxxx> [120627 13:37]:
> > --- a/arch/arm/plat-omap/include/plat/cpu.h
> > +++ b/arch/arm/plat-omap/include/plat/cpu.h
> > @@ -42,7 +42,14 @@
> > #define OMAP2_DEVICE_TYPE_GP 3
> > #define OMAP2_DEVICE_TYPE_BAD 4
> >
> > +#ifdef CONFIG_ARCH_OMAP2PLUS
> > int omap_type(void);
> > +#else
> > +inline static int omap_type(void)
> > +{
> > + /* Always return GP, since it is not being used anyway for omap1 */
> > + return OMAP2_DEVICE_TYPE_GP;
> > +}
> > +#endif
> >
> > /*
> > * omap_rev bits:
>
> Just to follow-up on this, looks like we need to postpone this
> for v3.7. While at it, we need to make sure all soc_is_omapxxxx()
> are false by default.
>
Just FYI, I had submitted V2 of this patch.
> What you're suggesting above would also depend on some MULTI_ARCH
> option set if multiple ARM architectures are selected. Above patch
> would only optimize things when ARCH_OMAP2PLUS alone is selected.
>
Isn't this only applicable for ARCH_OMAP2PLUS and OMAP1?? And above patch
take cares of both, as OMAP1 and 2 will not be build together, since
compiler flags itself will be different.
Can you elaborate on how things will break if multiple ARM architectures are
selected?
I am not sure whether I am following you completely.
Thanks,
Vaibhav
--
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
