Re: [PATCH v12 4/9] OMAP2+: dmtimer: convert to platform devices

[Tony Lindgren <tony@atomide.com>]

* Kevin Hilman <khilman@ti.com> [110317 14:58]:
> Tony Lindgren <tony@atomide.com> 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