> -----Original Message----- > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > Sent: Thursday, September 10, 2009 2:59 PM > To: Premi, Sanjeev > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [RFC] Common mechanism to identify Si revision > > Hello Sanjeev, > > On Thu, 3 Sep 2009, Premi, Sanjeev wrote: > > > 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) > > For use in structures like clock34xx.h and > powerdomains34xx.h, would you > propose that we use two different fields then - one for OMAP > type, the > other for revision restrictions? Or a different scheme? > > - Paul > Paul, First answer: We could use two fields e.g. omap_type and omap_rev. For example: .omap_type = CHIP_IS_OMAP3430, .omap_rev = OMAP_ES_2_1, Instead of : .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430), .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES1 | CHIP_IS_OMAP3430ES2 | CHIP_IS_OMAP3430ES3_0), .omap_chip = OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1), Second answer: >From the snippets above, it appears that we need to: 1) identify which chip is in use 2) which si rev (if any) does the clock/powerdomain definition applies to. Actually, we are checking for: a) Does definition depend upon a si rev b) if so, which rev? - usually LE and GE should be sufficient. Which chip in use? - can either be a run-time check OR mapped to an boot-time setting of "valid" field for the si being used. e.g. (translating the snippet above): .valid = (cpu_is_omap34xx()) .valid = (cpu_is_omap34xx() && (OMAP_REV_EQ(OMAP_ES_1_0) || OMAP_REV_EQ(OMAP_ES_2_1) || OMAP_REV_EQ(OMAP_ES_3_0))) .valid = (cpu_is_omap34xx() && (OMAP_REV_GE(OMAP_ES_3_1)) Now decision at runtime can be made based on the just this flag. I haven't really done any prototyping on this, so there may be holes in explanation above; but I hope general idea is coming clear. Best regards, Sanjeev -- 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
