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