| Message ID | 1341566515-22665-3-git-send-email-santosh.shilimkar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > From: R Sricharan <r.sricharan@ti.com> > > OMAP socs has a legacy and a highlander version of the > 32k sync counter IP. The register offsets vary between the > highlander and the legacy scheme. So use the 'SCHEME' > bits(30-31) of the revision register to distinguish between Just for my understanding, can we get further information on SCHEME bit-fields? What kind of information we have it here. I may need this info to pass on to design team here. Thanks, Vaibhav > the two versions and choose the CR register offset accordingly. > > Signed-off-by: R Sricharan <r.sricharan@ti.com> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > arch/arm/plat-omap/counter_32k.c | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c > index 2132c4f..dbf1e03 100644 > --- a/arch/arm/plat-omap/counter_32k.c > +++ b/arch/arm/plat-omap/counter_32k.c > @@ -29,7 +29,10 @@ > #include <plat/clock.h> > > /* OMAP2_32KSYNCNT_CR_OFF: offset of 32ksync counter register */ > -#define OMAP2_32KSYNCNT_CR_OFF 0x10 > +#define OMAP2_32KSYNCNT_REV_OFF 0x0 > +#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30) > +#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10 > +#define OMAP2_32KSYNCNT_CR_OFF_HIGH 0x30 > > /* > * 32KHz clocksource ... always available, on pretty most chips except > @@ -84,9 +87,16 @@ int __init omap_init_clocksource_32k(void __iomem *vbase) > int ret; > > /* > - * 32k sync Counter register offset is at 0x10 > + * 32k sync Counter IP register offsets vary between the > + * highlander version and the legacy ones. > + * The 'SCHEME' bits(30-31) of the revision register is used > + * to identify the version. > */ > - sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF; > + if (__raw_readl(vbase + OMAP2_32KSYNCNT_REV_OFF) & > + OMAP2_32KSYNCNT_REV_SCHEME) > + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH; > + else > + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW; > > /* > * 120000 rough estimate from the calculations in >
On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: >> From: R Sricharan <r.sricharan@ti.com> >> >> OMAP socs has a legacy and a highlander version of the >> 32k sync counter IP. The register offsets vary between the >> highlander and the legacy scheme. So use the 'SCHEME' >> bits(30-31) of the revision register to distinguish between > > > Just for my understanding, can we get further information on SCHEME > bit-fields? What kind of information we have it here. > > I may need this info to pass on to design team here. > Sure. You can refer to the OMAP4 TRM for the bit builds. SCHEME bit field tell you difference between a highlander and legacy IP as the patch says. Regards santosh
Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > From: R Sricharan <r.sricharan@ti.com> > > OMAP socs has a legacy and a highlander version of the > 32k sync counter IP. The register offsets vary between the > highlander and the legacy scheme. So use the 'SCHEME' > bits(30-31) of the revision register to distinguish between > the two versions and choose the CR register offset accordingly. Do these scheme bits exist on *all* OMAPs? including OMAP1? This driver is used on OMAP1 as well as OMAP2+. The cover letter says this was only build tested on OMAP1 so I suggest this actually be tested on OMAP1 before merging. Kevin > Signed-off-by: R Sricharan <r.sricharan@ti.com> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > --- > arch/arm/plat-omap/counter_32k.c | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c > index 2132c4f..dbf1e03 100644 > --- a/arch/arm/plat-omap/counter_32k.c > +++ b/arch/arm/plat-omap/counter_32k.c > @@ -29,7 +29,10 @@ > #include <plat/clock.h> > > /* OMAP2_32KSYNCNT_CR_OFF: offset of 32ksync counter register */ > -#define OMAP2_32KSYNCNT_CR_OFF 0x10 > +#define OMAP2_32KSYNCNT_REV_OFF 0x0 > +#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30) > +#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10 > +#define OMAP2_32KSYNCNT_CR_OFF_HIGH 0x30 > > /* > * 32KHz clocksource ... always available, on pretty most chips except > @@ -84,9 +87,16 @@ int __init omap_init_clocksource_32k(void __iomem *vbase) > int ret; > > /* > - * 32k sync Counter register offset is at 0x10 > + * 32k sync Counter IP register offsets vary between the > + * highlander version and the legacy ones. > + * The 'SCHEME' bits(30-31) of the revision register is used > + * to identify the version. > */ > - sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF; > + if (__raw_readl(vbase + OMAP2_32KSYNCNT_REV_OFF) & > + OMAP2_32KSYNCNT_REV_SCHEME) > + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH; > + else > + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW; > > /* > * 120000 rough estimate from the calculations in
Hi Kevin, On 07/09/2012 11:47 AM, Kevin Hilman wrote: > Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > >> From: R Sricharan <r.sricharan@ti.com> >> >> OMAP socs has a legacy and a highlander version of the >> 32k sync counter IP. The register offsets vary between the >> highlander and the legacy scheme. So use the 'SCHEME' >> bits(30-31) of the revision register to distinguish between >> the two versions and choose the CR register offset accordingly. > > Do these scheme bits exist on *all* OMAPs? including OMAP1? > > This driver is used on OMAP1 as well as OMAP2+. > > The cover letter says this was only build tested on OMAP1 so I suggest > this actually be tested on OMAP1 before merging. I have tested this on an omap5912 osk. I booted and verified that the offset is good. Santosh, add my tested-by for OMAP1 ... Tested-by: Jon Hunter <jon-hunter@ti.com> Cheers Jon
On 07/09/2012 11:47 AM, Kevin Hilman wrote: > Santosh Shilimkar <santosh.shilimkar@ti.com> writes: > >> From: R Sricharan <r.sricharan@ti.com> >> >> OMAP socs has a legacy and a highlander version of the >> 32k sync counter IP. The register offsets vary between the >> highlander and the legacy scheme. So use the 'SCHEME' >> bits(30-31) of the revision register to distinguish between >> the two versions and choose the CR register offset accordingly. > > Do these scheme bits exist on *all* OMAPs? including OMAP1? By the way, I believe that for early devices only the lower 8-bits were used and the upper bits return 0. For OMAP5912 I read 0x00000010 from the REV register and so this change should be safe for OMAP1 devices. Cheers Jon
On Tue, Jul 10, 2012 at 4:51 AM, Jon Hunter <jon-hunter@ti.com> wrote: > Hi Kevin, > > On 07/09/2012 11:47 AM, Kevin Hilman wrote: >> Santosh Shilimkar <santosh.shilimkar@ti.com> writes: >> >>> From: R Sricharan <r.sricharan@ti.com> >>> >>> OMAP socs has a legacy and a highlander version of the >>> 32k sync counter IP. The register offsets vary between the >>> highlander and the legacy scheme. So use the 'SCHEME' >>> bits(30-31) of the revision register to distinguish between >>> the two versions and choose the CR register offset accordingly. >> >> Do these scheme bits exist on *all* OMAPs? including OMAP1? >> >> This driver is used on OMAP1 as well as OMAP2+. >> >> The cover letter says this was only build tested on OMAP1 so I suggest >> this actually be tested on OMAP1 before merging. > > I have tested this on an omap5912 osk. I booted and verified that the > offset is good. > > Santosh, add my tested-by for OMAP1 ... > > Tested-by: Jon Hunter <jon-hunter@ti.com> > Thanks a lot Jon. I don't have OMAP1 hardware and hence couldn't do boot testing. I have already sent out PULL request to Tony. if he has not already pulled I should be able to update the OMAP1 tested by tag. Regards Santosh
On Mon, Jul 09, 2012 at 16:12:15, Shilimkar, Santosh wrote: > On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > > > > > > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > >> From: R Sricharan <r.sricharan@ti.com> > >> > >> OMAP socs has a legacy and a highlander version of the > >> 32k sync counter IP. The register offsets vary between the > >> highlander and the legacy scheme. So use the 'SCHEME' > >> bits(30-31) of the revision register to distinguish between > > > > > > Just for my understanding, can we get further information on SCHEME > > bit-fields? What kind of information we have it here. > > > > I may need this info to pass on to design team here. > > > Sure. You can refer to the OMAP4 TRM for the bit builds. > SCHEME bit field tell you difference between a highlander > and legacy IP as the patch says. > Santosh, Can you point to the section of OMAP4 TRM? I referred to both Public TRM and internal TRM, but both only did mention "TI internal Data". And as per code, we are not checking any value in 31-30 bit-fields, code just assumes that, non-zero value would be highlander IP. Thanks, Vaibhav
On Tue, Jul 10, 2012 at 12:11 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > On Mon, Jul 09, 2012 at 16:12:15, Shilimkar, Santosh wrote: >> On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: >> > >> > >> > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: >> >> From: R Sricharan <r.sricharan@ti.com> >> >> >> >> OMAP socs has a legacy and a highlander version of the >> >> 32k sync counter IP. The register offsets vary between the >> >> highlander and the legacy scheme. So use the 'SCHEME' >> >> bits(30-31) of the revision register to distinguish between >> > >> > >> > Just for my understanding, can we get further information on SCHEME >> > bit-fields? What kind of information we have it here. >> > >> > I may need this info to pass on to design team here. >> > >> Sure. You can refer to the OMAP4 TRM for the bit builds. >> SCHEME bit field tell you difference between a highlander >> and legacy IP as the patch says. >> > > Santosh, > > Can you point to the section of OMAP4 TRM? > > I referred to both Public TRM and internal TRM, but both only did mention > "TI internal Data". > Last time I refereed the internal TRM version. Public TRM doesn't carry that information for some reason. > And as per code, we are not checking any value in 31-30 bit-fields, code > just assumes that, non-zero value would be highlander IP. > There are only two types of IP's today and hence it will be either 0x0 or 0x1. So that check if just fine. The highlander IP may have more versions but for known OMAPs and upcoming OMAP, this is the only one supported version. Some more information on the SCHEME bit field. ----------------- 31:30 SCHEME Used to distinguish between old scheme and current. RO Read Only 0x0 - LEGACY 0x1 - Highlander 0.8 scheme -------------------------------- Regards Santosh Read 0x1 HL08 Highlander 0.8 scheme
On Tue, Jul 10, 2012 at 12:42:46, Shilimkar, Santosh wrote: > On Tue, Jul 10, 2012 at 12:11 PM, Hiremath, Vaibhav <hvaibhav@ti.com> wrote: > > On Mon, Jul 09, 2012 at 16:12:15, Shilimkar, Santosh wrote: > >> On Mon, Jul 9, 2012 at 2:20 PM, Vaibhav Hiremath <hvaibhav@ti.com> wrote: > >> > > >> > > >> > On 7/6/2012 2:51 PM, Santosh Shilimkar wrote: > >> >> From: R Sricharan <r.sricharan@ti.com> > >> >> > >> >> OMAP socs has a legacy and a highlander version of the > >> >> 32k sync counter IP. The register offsets vary between the > >> >> highlander and the legacy scheme. So use the 'SCHEME' > >> >> bits(30-31) of the revision register to distinguish between > >> > > >> > > >> > Just for my understanding, can we get further information on SCHEME > >> > bit-fields? What kind of information we have it here. > >> > > >> > I may need this info to pass on to design team here. > >> > > >> Sure. You can refer to the OMAP4 TRM for the bit builds. > >> SCHEME bit field tell you difference between a highlander > >> and legacy IP as the patch says. > >> > > > > Santosh, > > > > Can you point to the section of OMAP4 TRM? > > > > I referred to both Public TRM and internal TRM, but both only did mention > > "TI internal Data". > > > Last time I refereed the internal TRM version. Public TRM doesn't > carry that information > for some reason. > > > And as per code, we are not checking any value in 31-30 bit-fields, code > > just assumes that, non-zero value would be highlander IP. > > > There are only two types of IP's today and hence it will be either > 0x0 or 0x1. So that check if just fine. The highlander IP may have > more versions but for known OMAPs and upcoming OMAP, this is > the only one supported version. > > Some more information on the SCHEME bit field. > ----------------- > 31:30 > SCHEME > Used to distinguish between old scheme and current. > > RO Read Only > > 0x0 - LEGACY > > 0x1 - Highlander 0.8 scheme > -------------------------------- Thanks Santosh, This is what I was looking for, may be it is worth to put this information in either commit description of in code-comment. Thanks, Vaibhav
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c index 2132c4f..dbf1e03 100644 --- a/arch/arm/plat-omap/counter_32k.c +++ b/arch/arm/plat-omap/counter_32k.c @@ -29,7 +29,10 @@ #include <plat/clock.h> /* OMAP2_32KSYNCNT_CR_OFF: offset of 32ksync counter register */ -#define OMAP2_32KSYNCNT_CR_OFF 0x10 +#define OMAP2_32KSYNCNT_REV_OFF 0x0 +#define OMAP2_32KSYNCNT_REV_SCHEME (0x3 << 30) +#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10 +#define OMAP2_32KSYNCNT_CR_OFF_HIGH 0x30 /* * 32KHz clocksource ... always available, on pretty most chips except @@ -84,9 +87,16 @@ int __init omap_init_clocksource_32k(void __iomem *vbase) int ret; /* - * 32k sync Counter register offset is at 0x10 + * 32k sync Counter IP register offsets vary between the + * highlander version and the legacy ones. + * The 'SCHEME' bits(30-31) of the revision register is used + * to identify the version. */ - sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF; + if (__raw_readl(vbase + OMAP2_32KSYNCNT_REV_OFF) & + OMAP2_32KSYNCNT_REV_SCHEME) + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH; + else + sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW; /* * 120000 rough estimate from the calculations in