> -----Original Message-----
> From: Paul Walmsley [mailto:[email protected]]
> Sent: Thursday, September 10, 2009 2:59 PM
> To: Premi, Sanjeev
> Cc: [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html