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

[Hiremath, Vaibhav]

On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
> On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav <hvaibhav at ti.com> wrote:
> > On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
> >> 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.
> >>
> >
> > I am not sure this will work on all platforms, for example, AM33XX, where
> > We do not have 32ksync timer available, but we need PM support. Also, I
> > personally think, we should not again use compile time option here.
> >
> Why not ?
> If 32ksync timer is not available, don't register it. Then in AM case
> you just have one clock-source. 

In case of AM33xx, what about kernel without PM support?
As clocksource registration would be dependent on PM option, it won't work.

> I am against the idea of making
> gptimer as the default and asking user to choose sync32k from
> command-line.
> 

I understand your concern here.


> Btw, if you need PM, how are you going to use GPTIMER
> as a clocksource. Note sys-clock is generally stopped in
> low power states. So that leaves you option with using
> gptimer with 32K clock and in that case, GPTIMER
> is not a better clock-source compare to 32K sync timer
> and so shouldn't be the rating.
> 

AM33xx has GPTIMER1 in wakeup domain, so that we are already using as a
Clocksource, without any issues.

Thanks,
Vaibhav

> Regards
> Santosh
>