* Kevin Hilman <khilman@xxxxxx> [110317 14:58]: > Tony Lindgren <tony@xxxxxxxxxxx> writes: > > > > In the long run, think "local timer" for runtime, and then "wakeup timer" > > that gets only programmed when we enter idle. The "local timer" will > > continue operating normally after we wake-up and the "wakeup timer" > > will be just one shot event. Of course in the omap[23] case the > > "local timer" is really a faster dmtimer, but in the omap4+ case there's > > are real local timers. > > >> If this can be done such that the system timer is eventually a regular > >> device driver, then that should be fine. > > > > In this setup there should not be need to mess with the system timer > > after boot as we don't need to switch clock sources. > > I think we're confusing terminology. By system timer, I think you mean > the clockevent, right? Yes. > The situation you described above requires switching clockevents for > sure. No it won't, because we can use a separate physical timer for runtime and wake-up events. > In addition, we already have a usecase for switching the clocksource as > well. We currently setup a single clocksource using the timer_32k (not > a dmtimer.) However, we already have use-cases where we would like to > switch to a higher resolution clocksource (e.g. trace infrastructure for > PM instrumentation.) Again that can be done with a separate physical timer, no need to switch and reprogram the clocksource. > The whole point of switching these to real drivers is so they can use > runtime PM. Then, as soon as they are unused, runtime PM will kick in > and ensure the hardware is properly idle. Yes that makes sense for the device driver used timers and for the wake-up timer. Tony -- 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
