* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sat, 31 Mar 2007, Thomas Gleixner wrote: > > > > Right, but clock - sources/events need to be extremly late suspended and > > early resumed. How can we ensure this ? [...] > So the only thing that needs to be done is to make sure that we add > the timer devices early during bootup - something we have to do > *anyway*. If a device is added early in bootup, that automatically > means that it will be suspended late, and resumed early - because we > maintain that order all the way through.. IIRC hpet is particularly hard to initialize early on in the bootup sequence. So the way the clockevents code works is that it will always try to make the best out of all available devices, and dynamically adapts things as devices 'arrive' or 'depart' - no matter how late that happens. (That way there's no dependency on how late a device gets registered - it will only delay the switch to high-res mode for example.) A given time device might 'depart' because for example the watchdog mechanism finds that its quality is not good enough, or because someone initiated cpufreq which breaks the TSC clocksource. i dont think there's any particular problem here because suspend/resume wont be done during bootup - but we might need a way to move a device to earlier spots in the device tree, even if they got registered later on - instead of forcing the time devices to be registered very early? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
