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

Santosh Shilimkar santosh.shilimkar at ti.com
Mon Mar 19 08:15:32 EDT 2012


On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
> On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav <hvaibhav at ti.com> wrote:
>>
>> I think you made very good point here. With the above patch, we are almost missing the capability of registering dmtimer as a clocksource for OMAP.
>> It will always use 32k-counter, and never fall back to dmtimer.
>>
>> Then the only options we have here is,
>>
>> 1) Register both the timers, 32k-counter and dmtimer for clocksource; let
>>   Kernel pick up best rating clocksource out of these two.
>>
>>   In case of OMAP1/2/3/4, kernel will use dmtimer, since it has better
>>   Rating. User can choose the 32k-counter clocksource via bootargs.
>>
>>   Impact: without bootargs for clocksource selection, kernel will choose
>>     dmtimer, impacting loss of time during suspend/resume.
>>
This is the right option. The problem is gptimer clocksource
doesn't work across power transitions and hence it is broken.

Even for the perf, with PM enabled, dmtimer can't be used or it needs
to be used with 32KHz clock which makes it no better than sync timer.

So here keeping 32K sync timer is default clocksource makes sense since
it is the only working and viable option.

So what can be done is register both 32K and gptimer together but make
gptimer clocksource registration depends on PM enabled.

This should solve all the needs I guess.

>>
>> 2) Let the current code be as is, means, the clocksource registration will
>>   Happened based on "#ifdef CONFIG_OMAP_32K_TIMER" and this option
>>   selection will be Controlled by Kconfig rules.
> 
We should get rid off CONFIG_OMAP_32K_TIMER.

Regards
Santosh




More information about the linux-arm-kernel mailing list