* Tony Lindgren <tony@xxxxxxxxxxx> [091009 10:55]: > * Aguirre Rodriguez, Sergio Alberto <saaguirre@xxxxxx> [091009 06:55]: > > Nishanth, > > > > From: Menon, Nishanth > > Sent: Thursday, October 08, 2009 6:47 PM > > > > <snip> > > > > > diff --git a/arch/arm/plat-omap/include/mach/cpu.h > > > b/arch/arm/plat-omap/include/mach/cpu.h > > > index 431fec4..af1080f 100644 > > > --- a/arch/arm/plat-omap/include/mach/cpu.h > > > +++ b/arch/arm/plat-omap/include/mach/cpu.h > > > @@ -383,6 +383,12 @@ IS_OMAP_TYPE(3430, 0x3430) > > > #define OMAP3430_REV_ES2_1 0x34302034 > > > #define OMAP3430_REV_ES3_0 0x34303034 > > > #define OMAP3430_REV_ES3_1 0x34304034 > > > +/* NOTE: Add 36xx series below > > > + * If additional 34xx series are added, OMAP3430_REV_ESXXXX can be > > > + * added above the 3630 defines and series renumbered to ensure > > > + * rev() > checks to work > > > + */ > > > +#define OMAP3630_REV_ES1_0 0x34305034 > > > > Just for the sake of curiosity... > > > > Why not defining 3630 like this? > > > > #define OMAP3630_REV_ES1_0 0x36301034 > > > > Sorry if i'm asking something dumb. > > Because it's still considered 34xx class chip with > some extra features. It compiles with the same settings, > and uses the same kernel code. So from kernel point of > view we can treat it as 34xx. Never mind, the class bits for cpu_is_omap34xx() are the still there. I was confused. > Regards, > > Tony > > -- > 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 -- 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
