Messages in this thread | | | Date | Thu, 29 Sep 2005 01:21:28 -0400 | From | Jeff Garzik <> | Subject | SATA suspend/resume (was Re: [PATCH] updated version of Jens' SATA suspend-to-ram patch) |
| |
Joshua Kwan wrote: > Hello, > > I had some time yesterday and decided to help Jens out by rediffing the > now-infamous SATA suspend-to-ram patch [1] against current git and > test-building it. > > For posterity, > > This patch adds the ata_scsi_device_resume and ata_scsi_device_suspend > functions (along with helpers) to put to sleep and wake up Serial ATA > controllers when entering sleep states, and hooks the functions into > each SATA controller driver so that suspend-to-RAM is possible. > > Note that this patch is a holdover patch until it is possible to > generalize this concept for all SCSI devices, which requires more data > on which devices need to be put to sleep and which don't. > > Signed-off-by: Joshua Kwan <joshk@triplehelix.org>
Ah hah! I found the other SCSI suspend patch:
http://lwn.net/Articles/97453/
Anybody (Joshua?) up for reconciling and testing the two?
The main change from Jens/Joshua's patch is that we use SCSI's sd_shutdown() to call sync cache, eliminating the need for ata_flush_cache(), since the SCSI layer would now perform that.
For bonus points,
1) sd should call START STOP UNIT on suspend, which eliminates the need for ata_standby_drive(), and completely encompasses the suspend process in the SCSI layer.
2) sd should call START STOP UNIT on resume -- and as a SUPER BONUS, the combination of these two changes ensures that there are no queue synchronization issues, the likes of which would require hacks like Jens' while-loop patch.
None of these are huge changes requiring a lot of thinking/planning...
Finally, ideally, we should be issuing a hardware or software reset on suspend.
Jeff
- 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/
| |