Tony Lindgren <tony@xxxxxxxxxxx> writes: > * DebBarma, Tarun Kanti <tarun.kanti@xxxxxx> [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 -- 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