On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote: > On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav <hvaibhav@xxxxxx> 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@xxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
