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

[Kevin Hilman <khilman@ti.com>]

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

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.

If this can be done such that the system timer is eventually a regular
device driver, then that should be fine. 

Kevin

> I'll post some patches after the merge window for the system timer
> related code.
>
> Regards,
>
> Tony