Sanjeev, > -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Premi, Sanjeev > Sent: Thursday, July 22, 2010 3:20 PM > To: Menon, Nishanth; Gadiyar, Anand > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: RE: [PATCH] omap: Add macros to evaluate cpu revision > > > -----Original Message----- > > From: Menon, Nishanth > > Sent: Thursday, July 22, 2010 3:08 PM > > To: Gadiyar, Anand > > Cc: Premi, Sanjeev; linux-omap@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH] omap: Add macros to evaluate cpu revision > > > > On 07/22/2010 01:53 AM, Gadiyar, Anand wrote: > > >>> @@ -460,4 +461,35 @@ OMAP3_HAS_FEATURE(isp, ISP) > > >>> OMAP3_HAS_FEATURE(192mhz_clk, 192MHZ_CLK) > > >>> OMAP3_HAS_FEATURE(io_wakeup, IO_WAKEUP) > > >>> > > >>> +/* > > >>> + * Map revision bits to silicon specific revisions > > >>> + */ > > >>> +#define ES_1_0 OMAP_REVBITS_00 > > >> probably need ES_1_1, 1_2 (considering 3630) > > > > > > > > > This should be okay, since the 3630 is out with > > > these revisions, but... > > > > > >>> +#define ES_2_0 OMAP_REVBITS_10 > > >>> +#define ES_2_1 OMAP_REVBITS_20 > > >> makes sense to go to 2_2 > > >>> +#define ES_3_0 OMAP_REVBITS_30 > > >>> +#define ES_3_1 OMAP_REVBITS_40 > > >>> +#define ES_3_1_2 OMAP_REVBITS_50 > > >> 3_2? > > > > > > This may not make sense to add now as there are no > > > 2.2 or 3.2 revisions of any OMAP3/4 silicon? > > > > > Agreed for 3 and 4, but considering this is > > arch/arm/plat-omap/include/plat/cpu.h, does it make sense in > > looking all > > OMAPs? > > In this case, the best option would be to prefix OMAP34X_/ OMAP36X_ > OMAP44X_ etc and define the ES revisions for each context. > Can please put the usecase need here. Do you want to use this for ERRATA handling or OPP handling etc etc ? Regards, Santosh -- 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
