On Thu, Apr 25, 2013 at 3:45 PM, Marc Jones <[email protected]> wrote: > The timer scheduler for hardware init scares me a bit... but I'd like > to see an implementation.
It's similar to the boot state callbacks. There is a free running timer. One can say run this in 10milliseconds. In 10 milliseconds (or after) the callback will be called. The timer callbacks would be evaluated between boot state transitions. Stand by on the implementation. Fwiw, the free running timer is the hard part because we aren't talking about an interrupt but a polling method. Therefore we need to somehow ensure the longest period between polls is not sufficiently long (1/2 the global timer period) to not detect a roll over. > > On Thu, Apr 25, 2013 at 11:59 AM, Aaron Durbin <[email protected]> wrote: >> On Thu, Apr 25, 2013 at 12:52 PM, ron minnich <[email protected]> wrote: >>> we really need the timer scheduler on newer platforms. >>> >>> Some of the platforms are so old they may not be testable. >>> >>> My plan is to provide timer_us for all platforms I can test, and then >>> have only the new platforms use timer queue interface. I think we can >>> manage this with proper configuration of makefiles. >> >> >> OK. Let me look into it more then. I can probably have something next >> week some time once I tease out the weird implementations of the >> current udelay() functions. The only thing we'll have to get a handle >> on is roll over in whatever hardware is providing a the free running >> timer. >> >> -Aaron >> >> -- >> coreboot mailing list: [email protected] >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > http://se-eng.com -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
