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.
> >> >
> >> > The optional gptimer based clocksource was added so that it can
> >> > give the high precision than sync-timer, so expected usage was 2
> >> > and not 3.
> >> > Unfortunately option 2, clocksource doesn't meet the requirement of
> >> > free-running clock as per clocksource need. It stops in low power states
> >> > when sys_clock is cut. That makes gptimer based clocksource option
> >> > useless for OMAP2/3/4 devices with sys_clock as a clock input.
> >> > Option 3 will still work but it is no better than 32K sync-timer
> >> > based clocksource.
> >> >
> >> > So ideally we can kill the gptimer based clocksource option but there
> >> > are some OMAP based derivative SoCs like AM33XX which doesn't have
> >> > 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
> >> > clocksource.
> >> > Considering above, make sync-timer and gptimer clocksource runtime
> >> > selectable so that both OMAP and AMXXXX continue to use the same code.
> >> >
> >> > Also, in order to precisely configure/setup sched_clock for given
> >> > clocksource, decision has to be made early enough in boot sequence.
> >> >
> >> > So, the solution is,
> >> >
> >> > Use kernel parameter ("clocksource=") to override
> >> > default 32k_sync-timer, in addition to this, we also use hwmod database
> >> > lookup mechanism, through which at run-time we can identify availability
> >> > of 32k-sync timer on the device, else fall back to gptimer.
> >> >
> >> > Signed-off-by: Vaibhav Hiremath <hvaibhav@xxxxxx>
> >> > Signed-off-by: Felipe Balbi <balbi@xxxxxx>
> >> > Cc: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
> >> > Cc: Kevin Hilman <khilman@xxxxxx>
> >> > Cc: Benoit Cousson <b-cousson@xxxxxx>
> >> > Cc: Tony Lindgren <tony@xxxxxxxxxxx>
> >> > Cc: Paul Walmsley <paul@xxxxxxxxx>
> >> > Cc: Tarun Kanti DebBarma <tarun.kanti@xxxxxx>
> >> > Cc: Ming Lei <tom.leiming@xxxxxxxxx>
> >>
> >> This fails to boot on my Mistral am37x-evm with omap2plus_defconfig
> >>
> >
> > Thanks Russ, for validating it.
> >
> > But I do not see any relation between your boot process stuck and this patch.
> > What is the observation without these patches?
>
> With no patches applied it boots, with 1/3 applied it boots, with 2/3
> applied it boots, with 3/3 applied it gets hung. I also tested on my
> beagleboard b4, that booted fine.
>
You mean to say, on Beagleboard it boots up fine. And same fails on EVM?
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
