[PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

[Jon Hunter]

Hi Vaibhav,

On 04/09/2012 01:19 AM, Hiremath, Vaibhav wrote:

[...]

> Let me summarize it here again,
>
> Currently, the timer code is using config option CONFIG_OMAP_32K_TIMER,
> to choose between 32ksync counter and gptimer; it is compile time option.
> If user wants to use gptimer for HR ticks, he must build the kernel without
> CONFIG_OMAP_32K_TIMER option.
>
> AM335x family of devices doesn't have 32ksync_counter available, only option
> here is to use gptimer for kernel clocksource and clockevents.
>
> So in order to support, multi-omap build including devices like AM335x, we
> must get rid of this option CONFIG_OMAP_32K_TIMER, atleast from clocksource
> registration perspective.
>
> So that means, we need to have some mechanism to handle or detect available
> clocksource runtime. Options would be,
>
>   - Use HWMOD to detect availability of 32ksync_counter, else fallback
>     to gptimer. [This was my original patch]
>
>     But this restricts the use of gptimer completely on omap architecture,
>     where we have 32ksync counter module.

True, but we would always want to use the 32k timer if CONFIG_PM is 
specified. So what I am saying is that if a device has a 32ksync timer 
and CONFIG_PM is defined, we always want to use the 32ksync timer and a 
gptimer should never be used.

So we should/must restrict the use of a gptimer is CONFIG_PM is enabled 
for devices that have the 32ksync timer.

>   - So the next solution is to still keep compile time option, so that user
>     will get to use gptimer atleast just changing the kernel config option.
>
>     But, still, this is going to be kernel rebuild.
>
>   - Next option came up was, register both the timers and override using
>     kernel parameter.
>
>     This will work only if, both the timers run at same rate/frequency; since
>     we have one more layer here setup_sched_clock(), which actually can be
>     called only once.
>
>   - Next option suggested by Santosh, is to use kernel parameter as in parse
>     it early, to make decision on if user wants to override default
>     clocksource (32ksync)
>
>     This is something will work for us and solves all above issues.

What happens if PM is enabled? Can you still override the default? I 
don't think this should be allowed for devices with a 32ksync timer.

Jon