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. >> >> 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 -- 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
