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

[Shilimkar, Santosh]

On Fri, Mar 30, 2012 at 2:58 PM, Hiremath, Vaibhav <hvaibhav at ti.com> wrote:
> On Fri, Mar 30, 2012 at 14:50:02, Shilimkar, Santosh wrote:
>> On Fri, Mar 30, 2012 at 2:42 PM, Hiremath, Vaibhav <hvaibhav at ti.com> wrote:
>> > On Fri, Mar 30, 2012 at 14:08:20, Shilimkar, Santosh wrote:
>> >> On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote:
>> >> > On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote:
>>
>> [....]
>>
>> >> >
>> >> > With this patch, will you be able to choose gptimer as a clocksource
>> >> > using bootparameter (or sysfs) for given kernel uImage?
>> >> >
>> >> Why do you want that ? Look at changelog. The gptimer based clocksource
>> >> is useless for OMAP and for AM devices synctimer is not available.
>> >>
>> >>
>> >> > The answer is simply NO...as the registration of gptimer is based on
>> >> > failure from omap_init_clocksource_32k(). And this is nothing different
>> >> > than my original patch, my patch exactly does same thing.
>> >> >
>> >> I ight have missed your original patch. If that patch is similar then
>> >> no problems.
>> >>
>> >> > The requirement after 'ming Lie' response on my patch was, there will be
>> >> > usecases where we might need to use gptimer for clocksource and with
>> >> > the patch it is not possible, since you will only register
>> >> > 32k_counter here.
>> >> >
>> >> I think Ming Lie might have expected that gptimer clocksource might
>> >> be better which is not the case.
>> >>
>> >> > So in order to allow user to choose between 32K and gptimer, you must
>> >> > register both and make 32k as a default thing.
>> >> >
>> >> As described in the commit log, its not needed at all. Let's not add
>> >> a feature which is just useless because the gptimer based clock
>> >> source has no advantage against the syntimer.
>> >>
>> >
>> > I completely agree with you, and that is my understanding too.
>> >
>> Thanks !!
>>
>> > After Ming Lie's comment, the point that I came to my mind was,
>> > certainly there will be resolution difference between these two clocksources,
>> > if  gptimer2 is sourced from sys_ck (26Mhz).
>> >
>> GPTIMER2 with sysclock is not an option. GPTIMER is not in wakeup domain
>> and when sysclock is cut, it stops.
>>
>> > I am quite not sure, whether will there be any practical usecase where you
>> > change the kernel clocksource for high resolution dynamically through sysfs
>> > or something. May be not....but still it is possible.
>> >
>> Even if there is a usecase, there no option with full PM.
>>
>
> What if before suspending the system, you switch back to 32k_counter
> everytime, and in resume you again switch to gp_timer?
>
This has been discussed at length. Dynamic switching between
clock-sources affects the NTP time corrections. Go through [1]
when you have time, since its a long thread.

If and when that feature works, we can update the clocksource
code.

Regards
Santosh

[1]  https://lkml.org/lkml/2011/6/2/167