On Fri, 1 Feb 2013, Aaron Lu wrote: > Hi Derek, > > On 12/21/2012 12:35 PM, Derek Basehore wrote: > > We no longer wait for the disk to spin up in sd_resume. It now enters the > > request to spinup the disk into the elevator and returns. > > > > A function is scheduled under the scsi_sd_probe_domain to wait for the command > > to spinup the disk to complete. This function then checks for errors and cleans > > up after the sd resume function. > > > > This allows system resume to complete much faster on systems with an HDD since > > spinning up the disk is a significant portion of resume time. > > An alternative way of possibly solving this problem from PM's point of > view might be: > 1 Set both ata port and scsi device's runtime status to RPM_SUSPENDED > in their system suspend callback; > 2 On resume, do nothing in their system resume callback; > 3 With request based runtime PM introduced here: > http://thread.gmane.org/gmane.linux.power-management.general/30405 > When a request comes for the HDD after system resume, both the ata > port and the scsi device will be runtime resumed, which involves > re-initialize the ata link(in ata port's runtime resume callback) and > spin up the HDD(in sd's runtime resume callback). > > To make HDD un-affetcted by runtime PM during normal use, a large enough > autosuspend_delay can be set for it. > > Just my 2 cents, I've not verified or tried in any way yet :-) It's a good idea. The problem is that it won't work if CONFIG_PM_SLEEP is enabled but CONFIG_PM_RUNTIME isn't. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
