> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Premi, Sanjeev
> Sent: Thursday, September 03, 2009 4:14 PM
> To: [email protected]
> Subject: [RFC] Common mechanism to identify Si revision
>
> Hi,
>
> Currently there are multiple mechanisms for identifying the
> si revisions.
>
> Most places the comparison is against omap_rev() as a whole
> number. Example:
>
> arch/arm/mach-omap2/board-3430sdp.c:695: if (omap_rev() >
> OMAP3430_REV_ES1_0)
> arch/arm/mach-omap2/board-3430sdp.c:728: if (omap_rev() >
> OMAP3430_REV_ES1_0)
>
> Then, there are custom macros. Example (cpu.h):
>
> #define CHIP_GE_OMAP3430ES3_1 (CHIP_IS_OMAP3430ES3_1)
> #define CHIP_GE_OMAP3430ES3 (CHIP_IS_OMAP3430ES3_0 | \
> CHIP_GE_OMAP3430ES3_1)
> #define CHIP_GE_OMAP3430ES2 (CHIP_IS_OMAP3430ES2 | \
> CHIP_GE_OMAP3430ES3)
>
> The problem with comparing against a whole number is that
> comparison is invalid
> for another processor series. E.g. OMAP3430 and OMAP3517.
>
> Here, I am proposing a common mechanism to identify the si
> revision; that focuses
> on the revision bits alone. (See code below)
>
> The usage would then be (example):
>
> if (omap_rev() > OMAP3430_REV_ES1_0)
>
> To
>
> if (cpu_is_omap34xx() && OMAP_REV_GT(OMAP_ES_1_0)
>
>
> Though I have not looked at the OMAP1 directory, I am
> assuming similar case there.
> Since there aren't any new devices in the OMAP1 category,
> this may not appear as
> a need. But consistency could help.
>
> Few items that I feel need to be looked at:
> - Possible differences in the MASK defined for Si revision.
> Irrespective of (possible) difference in the HW, the bits
> in 'omap_revision' can
> be same.
>
> - How to phase in the change - one shot OR in steps.
>
> I am not sending this as patch, for now; just to get the
> discussion started.
>
> Best regards,
> Sanjeev
>
[sp] sorry, missed the return statement in the inline functions below:
... perils of writing code in mail :)
~sanjeev
>
> (cpu.h)
>
> /*
> * Identify silicon revision.
> */
> #define OMAP_REV_MASK 0x0000ff00
>
> #define OMAP_ES_1_0 0x00
> #define OMAP_ES_2_0 0x10
> #define OMAP_ES_2_1 0x20
> #define OMAP_ES_3_0 0x30
> #define OMAP_ES_3_1 0x40
>
> #define OMAP_REV_IS(revid)
> \
> static inline u8 omap_rev_is_ ##revid (void)
> \
> {
> \
> (((omap_rev() & OMAP_REV_MASK) >> 8) == revid) ? 1 : 0
> ; \
> }
>
> #define OMAP_REV_LT(revid)
> \
> static inline u8 omap_rev_lt_ ##revid (void)
> \
> {
> \
> (((omap_rev() & OMAP_REV_MASK) >> 8) < revid) ? 1 : 0 ; \
> }
>
> #define OMAP_REV_LE(revid)
> \
> static inline u8 omap_rev_le_ ##revid (void)
> \
> {
> \
> (((omap_rev() & OMAP_REV_MASK) >> 8) <= revid) ? 1 : 0
> ; \
> }
>
> #define OMAP_REV_GE(revid)
> \
> static inline u8 omap_rev_ge_ ##revid (void)
> \
> {
> \
> (((omap_rev() & OMAP_REV_MASK) >> 8) >= revid) ? 1 : 0
> ; \
> }
>
> #define OMAP_REV_GT(revid)
> \
> static inline u8 omap_rev_gt_ ##revid (void)
> \
> {
> \
> (((omap_rev() & OMAP_REV_MASK) >> 8) > revid) ? 1 : 0 ; \
> }
>
> OMAP_REV_IS(OMAP_ES_1_0)
> OMAP_REV_LT(OMAP_ES_1_0)
> OMAP_REV_LE(OMAP_ES_1_0)
> OMAP_REV_GT(OMAP_ES_1_0)
> OMAP_REV_GE(OMAP_ES_1_0)
>
> OMAP_REV_IS(OMAP_ES_2_0)
> OMAP_REV_LT(OMAP_ES_2_0)
> OMAP_REV_LE(OMAP_ES_2_0)
> OMAP_REV_GT(OMAP_ES_2_0)
> OMAP_REV_GE(OMAP_ES_2_0)
>
> OMAP_REV_IS(OMAP_ES_2_1)
> OMAP_REV_LT(OMAP_ES_2_1)
> OMAP_REV_LE(OMAP_ES_2_1)
> OMAP_REV_GT(OMAP_ES_2_1)
> OMAP_REV_GE(OMAP_ES_2_1)
>
> OMAP_REV_IS(OMAP_ES_3_0)
> OMAP_REV_LT(OMAP_ES_3_0)
> OMAP_REV_LE(OMAP_ES_3_0)
> OMAP_REV_GT(OMAP_ES_3_0)
> OMAP_REV_GE(OMAP_ES_3_0)
>
> OMAP_REV_IS(OMAP_ES_3_1)
> OMAP_REV_LT(OMAP_ES_3_1)
> OMAP_REV_LE(OMAP_ES_3_1)
> OMAP_REV_GT(OMAP_ES_3_1)
> OMAP_REV_GE(OMAP_ES_3_1)
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-omap" in
> the body of a message to [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html