On Fri, 4 May 2007, Rafael J. Wysocki wrote: > > Plus, it may have some parts related to the communications with operating > > system (*)... I guess we need to save those, and parts related to hw > > state... where your suggestion makes sense. > > If they are accessible to us, then we can, but what if they aren't (eg. the > state information is stored in the embedded controller, can only be read with > the help of some AML invocations and cannot be changed from the OS level)? > > > (*) and yes, there probably are such parts. If we set backlight to > > 20%, we'll be confused if it is 100% after resume... we probably could > > handle those one-by-one... > > *If* we reinitialize devices *and* ACPI from scratch after restoring the image, > we'll discard the old value (20%) and read the new value (100%) from the BIOS. > The problems occur, IMO, because we try to be smart and use the BIOS > after the resume as though we'd resumed from a real suspend (eg. s2ram). > > Which is natural, if we use the same set of .resume() callbacks for both cases. Agreed, these all sound like problems in the ACPI driver's implementation of suspend and resume. Problems that are caused (at least in part) by the fact that the PM core doesn't tell the driver whether it's doing suspend-to-RAM vs. hibernation. Once that is straighened out, everything else should become much simpler. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
