On Tuesday, 17 July 2007 22:34, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[email protected]> writes:
>
> [snip]
>
> >> Rafael, for those of us who aren't thoroughly familiar with all the ins
> >> and outs of the ACPI spec, could you please summarize a list of the
> >> ACPI calls needed in the second and third cases above? Indicate which
> >> ones need to be done from within the original kernel and which should
> >> be done from within a kexec'd hibernation kernel.
>
> > Sure.
>
> > In the third case (ie. transition to S4) we are supposed to do the following:
>
> > (1) Upon entering the sleep state, which IMO can be done _after_ the image
> > has been saved:
>
> I assume you mean "in order to enter the sleep state", rather than "upon
> entering the sleep state".
Yes, that seems to be more accurate.
> I still don't understand what you mean by
> "which IMO can be done _after_ the image has been saved"; as far as I
> understand, the last step of this process, "make the platform enter S4",
> is almost like a shutdown as far as the kernel is concerned (except for
> the tiny detail of having to call those special ACPI methods on resume);
> consequently, it would seem that nothing can be done after that step.
Well, the ACPI spec suggests to save the image somewhere after the devices
have been but into low power states, which is kind of unreasonable. :-)
> > * figure out which devices can wake up
> > * put devices into low power states (wake-up devices are placed in the Dx
> > states compatible with the wake capability, the others are powered off)
> > * execute the _PTS global control method
> > * switch off the nonlocal CPUs (eg. nonboot CPUs on x86)
> > * execute the _GTS global control method
> > * set the GPE enable registers corresponding to the wake-up devices)
> > * make the platform enter S4 (there's a well defined procedure for that)
> > I think that this should be done by the image-saving kernel.
>
> I agree.
>
> > (2) Upon start-up (by which I mean what happens after the user has pressed
> > the power button or something like that):
> > * check if the image is present (and valid) _without_ enabling ACPI (we don't
> > do that now, but I see no reason for not doing it in the new framework)
> > * if the image is present (and valid), load it
> > * turn on ACPI (unless already turned on by the BIOS, that is)
> > * execute the _BFS global control method
> > * execute the _WAK global control method
> > * continue
> > Here, the first two things should be done by the image-loading kernel, but
> > the remaining operations have to be carried out by the restored
> > kernel.
>
> It doesn't seem like a problem for that to be the case, but out of
> curiosity why do those methods need to be executed by the "restored"
> kernel, rather than the "image loading" kernel. Do they require some
> information from ACPI-related kernel data structures that were populated
> by the normal ACPI initialization?
Well, there are some complications. For example, _BFS and _WAK should be
executed with interrupts on (I'm told that the AML interpreter might not work
with interrupts disabled) and the nonboot CPUs should be offline while they
are being executed. Perhaps we should also avoid playing with APICs and
things like that after executing _WAK, so it's better to execute them from the
restored kernel.
> [snip]
>
> > ... we can't return to the hibernated kernel unless we are going to cancel the
> > hibernation.
>
> I agree.
>
> > That's why I think that for the suspend-to-both the image-saving kernel will
> > need to support the same set of devices as the hibernated kernel.
>
> If all of the devices that the image writing kernel doesn't know about
> have already been shut down/powered off by the hibernated kernel, then
> does the "image writing" kernel still need to know about them in order
> to suspend to RAM properly (i.e. without leaving some devices on wasting
> power)?
For some devices it may be illegal to leave them powered on while entering
S3.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
