Messages in this thread |  | | | From | Oliver Neukum <> | | Subject | Re: Solving suspend-level confusion | | Date | Sat, 31 Jul 2004 19:01:16 +0200 |
| |
> > Disks in general are an example (IDE beeing the one that is currently > > implemented, but we'll probably have to do the same for SATA and SCSI > > at one point), you want to spin them off (with proper cache flush > > etc...) when suspending to RAM, while you don't when suspending to > > disk, as you really don't want them to be spun up again right away to > > write the suspend image. > > So suspend-to-RAM more or less matches PCI D3hot, and > suspend-to-DISK matches PCI D3cold. If those power states > were passed to the device suspend(), the disk driver could act > appropriately. In my observation, D3cold was never passed > down, it was always D3hot.
Maybe a better approach would be to describe the required features to the drivers rather than encoding them in a single integer. Rather like passing a request that states "lowest power level with device state retained, must not do DMA, enable remote wake up"
[..] > Though the PM core doesn't cooperate at all there. Neither the > suspend nor the resume codepaths cope well with disconnect > (and hence device removal), the PM core self-deadlocks since > suspend/resume outcalls are done while holding the semaphore > that device_pm_remove() needs, ugh.
Shouldn't we deal with this like a failed resume?
Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |