On Thursday, 21 June 2007 16:48, David Brownell wrote: > On Thursday 21 June 2007, Rafael J. Wysocki wrote: > > The issue at hand is that some device drivers may need to know what the > > target sleep state of the system will be when their .suspend() routines are > > being executed. Currently, there's no means of passing that information to the > > drivers and my question is how to do this. > > Actually what they need to know is some *attribute* of that state. Generally, yes. > They really don't care what the state is. The $SUBJECT patch isn't > driver code ... it's for platform hooks that expose attributes to > the drivers. Specifically, it's ACPI code, talking to drivers that > must run on non-ACPI systems. Any driver that thinks it needs to > understand anything about ACPI states is sadly broken. But finally it has to place the device into a specific state and that state needs to be determined somehow. And, if ACPI is involved, it needs to be told at one point if the final system state is supposed to be S1 or S2 or S3 (I guess we can discard S2 safely) just to tell the driver which power states of the device are suitable. That's why I thought we might introduce an additional global pm_op that could be used to provide ACPI with that information without engaging drivers in passing it. > Remember also that the Linux "states" (in /sys/power/state) are an > inadequate representation of what most hardware can do. Do we really want to introduce more system sleep states right at this point? > Common hardware can support a lot more low power sleep modes than the two > states Linux currently defines ... a limitation inherited from first APM, and > them more recently ACPI, which doesn't fit embedded systems well at all. I agree with that, but right now we have an ACPI-related problem at hand. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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
