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

[Russ Dill <russ.dill@xxxxxxxxx>]

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.
--
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