Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: Reworking suspend-resume sequence (was: Re: PCI PM: Restore standard config registers of all devices early) | Date | Wed, 4 Feb 2009 00:25:27 +0100 |
| |
On Wednesday 04 February 2009, Benjamin Herrenschmidt wrote: > > > (Newer) ACPI says that devices should be put into low power states (presumably > > with the help of appropriate ACPI AML routines) before the _PTS method is > > called. In turn, we're supposed to disable nonboot CPUs after calling _PTS. > > There is analogous requirement for the _WAK method during resume. > > > > Currently, the suspend code ordering follows these rules, but if we move > > the putting of devices into low power states into the suspend_late part, they > > will have to be done after _PTS and that is likely to break things (we've > > already had this problem once and I have really bad memories related to it). > > Wait wait wait ... the -whole- point of the exercise, wether using > local_irq_save or disable_irq, -is- to put the ACPI bit -after- setting > the device in low power state and before the restore on wakeup... > > So basically, that isn't changing. > > The -one- thing that indeed conflicts here is that we disable nonboot > CPUs earlier. Right ? > > Now, I doubt that would be a big issue, ie, we are supposedly capable of > dynamically disabling/enabling CPUs anyway, but if it is, then indeed I > see how the using of higher level PIC irq disabling would allow to move > the whole suspend_late() over to before disabling non-boot CPUs. > > That does introduce a significant change in semantics for drivers in the > sense that now, suspend_late will be called with timers running, things > scheduling, requests coming in, etc... One of the big reasons for doing > suspend_late with IRQs off was precisely that drivers wouldn't have to > synchronize with all these things. They now do.
I realize the problem, but IMO only a few drivers will be affected, since only a few of them implement suspend_late/resume_early.
> Thus I tend to think that keeping the disabling of nonboot CPUs earlier > than the suspending of devices is the least of two evils. _BUT_ As I > said, I'm no ACPI expert and not -that- familiar with x86 land, it might > indeed be a can of worms.
It is. :-)
Thanks, Rafael
| |