Tony Lindgren <tony@xxxxxxxxxxx> writes: > * Kevin Hilman <khilman@xxxxxx> [110311 16:00]: >> 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.) > > I think the related inline functions can be shared. > The way it is currently coded results in duplicate code. One of them uses the clock API directly, the other uses runtime PM. >> 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. I think we're confusing terminology. By system timer, I think you mean the clockevent, right? The situation you described above requires switching clockevents for sure. 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.) 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. Kevin -- 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
