On Wed, 20 Feb 2008, Jesse Barnes wrote: > > Really, in the simple s3 case we still need early/late stuff? Absolutely. Two big reasons: - debuggability I know we don't do this correctly right now, but I want to be able to at least feel like we can some day actually do printk's etc through 99% of the suspend/resume cycle. It's a *huge* thing for debugging problems that happen in the wild, and one of the biggest issues is that we currently usualyl just get a "the machine died" message when suspend or resume doesn't work. Yes, doing printk's to the Intel management flash stuff can help a lot here, and I want that too, but I'd really like to shut down consoles individually rather than having the "big hammer" approach that shuts them up entirely over the whole suspend/resume sequence (or not at all, if you use "no_console_suspend"). And I'd *really* like to do things like VGA-console shutdown in the late phase (and resume early). - it's actually likely *much* simpler for some devices. Simple devices (and that includes things like PCI bridges etc, but also potentially USB host controllers etc) are things that can often be trivially suspended - all the complexity is really not in the controller itself, but beyond, in the bus that it actually drives. And the late-suspend/early-resume means that you don't have to worry about things like interrupts happening while you're suspended. Yes, putting the device into D3 will disable interrupts from that device too (unless there are bugs), *BUT* you may be sharing an interrupt line, and interrupts may be posted and delayed, so an earlier interrupt may well be pending etc. suspending late and resuming early just avoids those issues entirely. Sometimes these things interact. For example, firewire is certainly not trivial to suspend as a "subsystem" thing (ie all the devices behind the firewire bridge need to do magic things, like spinning down etc that obviously can not happen in the final "late" phase), but the firewire controller itself is likely trivial to suspend/resume and can easily be handled in the late/early routines. And guess what? It's also exactly what you want to happen in case you end up using the firewire RDMA as a debug aid. IOW, you want that firewire controller (and the PCI bridges) working really early, so that if a problem does happen when you resume some more complex device (say, one of the graphics chips that need X to really come alive), you can use the firewire rdma to read out the kernel log buffer from memory. > Well, it seems like we'll have to fix drivers in either case, and isn't a > kexec approach fundamentally more sound and simple, design-wise? Rafael > pointed out some problems with properly setting wakeup states, but I think > that could be overcome... I don't personally mind kexec at all, but on the other hand, I don't care about suspend-to-disk in the first place. I do know that some people really don't want it, and I suspect that they have valid reasons. Ranging from memory use to simply just performance. Linus - 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
