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

[Hiremath, Vaibhav]

On Tue, Apr 10, 2012 at 01:48:22, Hunter, Jon wrote:
> 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.
> 

If user is overriding it explicitly, that itself means he knows what he
is doing here. I too much to ask for...and unnecessary thing or expectation
from SW.

Thanks,
Vaibhav