RE: [PATCH-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux