On Thu, Apr 26, 2012 at 21:28:15, Hunter, Jon wrote: > Hi Vaibhav, Russ, > > On 04/26/2012 08:46 AM, Hiremath, Vaibhav wrote: > > On Thu, Apr 26, 2012 at 13:15:18, Russ Dill wrote: > >> On Wed, Apr 25, 2012 at 11:23 PM, Hiremath, Vaibhav <hvaibhav@xxxxxx> wrote: > >>> On Thu, Apr 26, 2012 at 11:26:09, Russ Dill wrote: > >>>> On Wed, Apr 25, 2012 at 10:42 PM, Hiremath, Vaibhav <hvaibhav@xxxxxx> wrote: > >>>>> On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote: > >>>>>> On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath <hvaibhav@xxxxxx> wrote: > >>>>>>> Current OMAP code supports couple of clocksource options based > >>>>>>> on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer > >>>>>>> and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz). > >>>>>>> So there can be 3 options - > >>>>>>> > >>>>>>> 1. 32KHz sync-timer > >>>>>>> 2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer > >>>>>>> 3. 32KHz based gptimer. > >>>>>>> > > <Snip> > >>> > >>> You mean to say, on Beagleboard it boots up fine. And same fails on EVM? > >> > >> > >> yes > >> > > > > I am able to reproduce this issue, and it seems the issue is really weird > > and I am completely clueless here. > > > > With below patch/change it always works, 100% success. The moment I add 0x10 > > offset to the ioremaped virtual base address, gone...95% of the time it > > fails. > > I have observed that, the execution always stays at wfi (default_idle) > > thread. Really strange behavior...and I am clueless now. > > > > - The 32k sync timer address space is part of iotable. > > - The ioremap() internally masks the addr to page aligned addr and gets pfn, > > At the end, offset is being added. So I don't really understand how is it > > different than adding offset before and after ioremap(). > > > > > > Also, this issue is nothing to do with my patch, it also happens with the > > original code. > > Just add 0x10 offset after ioremap(), and booooooom.... (95% of the time) > > > > > > ----------Patch which works (on top of this patch-series)---------- > > > > diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c > > index 3e3cdab..b0ef8ce 100644 > > --- a/arch/arm/plat-omap/counter_32k.c > > +++ b/arch/arm/plat-omap/counter_32k.c > > @@ -90,6 +90,7 @@ int __init omap_init_clocksource_32k(u32 pbase, unsigned long size) > > * For this to work we must have a static mapping in io.c > > * for this area > > */ > > + pbase = pbase + OMAP2_32KSYNCNT_CR_OFF; > > base = ioremap(pbase, size); > > What is size set to in the failing case on the am37xx device? Any chance > we are not mapping enough space? > I do not think it is related to mapping size. I have already explored this path. Thanks, Vaibhav -- 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
