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

[Tony Lindgren <tony@atomide.com>]

* Kevin Hilman <khilman@ti.com> [110311 16:00]:
> Tony Lindgren <tony@atomide.com> writes:
> 
> > * DebBarma, Tarun Kanti <tarun.kanti@ti.com> [110310 20:18]:
> >> > From: Hilman, Kevin
> >> > 
> >> > I guess Tony has the final say here, but personally, I don't really like
> >> > the special treatment of a system timer, unless it is an init-time only
> >> > special treatment.  Since we now have dynamically configurable
> >> > clocksources, the concept of a system timer doesn't really exist (except
> >> > for in early boot.)  At any time during runtime, we could dynamically
> >> > switch the clocksource to a different timer device.  At this point, one
> >> > would expect runtime PM for the previous timer to kick in and idle the
> >> > timer.  That cannot happen with this approach.
> >>
> >> I am open to suggestions.
> >
> > There's no need to dynamically change the clocksource. We can to set up
> > things so we have a system timer running with minimal code and faster
> > clock rate. Then we can use a separate timer with the 32KiHZ source
> > just to provide wake-up events for idle modes. And this second wake-up
> > timer can be just a regular device driver.
> >
> > The system timer code needs to be fast. And I don't want to add any
> > dependencies to anything except clock framework. Like I've said, the
> > rest of the timers can be just a regular device driver.
> 
> There are a couple problems with this approach.  The special case
> handling of a "system" timer leads to duplicate code (this series is a
> good example.)

I think the related inline functions can be shared.
 
> The other problem is PM.
> 
> If we switch away from the original system timer (for whatever reason),
> since it is not a regular device, it will not have runtime PM We'll then
> need special case PM code for the system timer, which I think is wasted
> effort.

This should not cause problems either, there should not be any need to
switch the timers in the setup what I'm thinking.

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.

Regards,

Tony