On Wed, 2012-08-08 at 01:44 +0800, Shane Huang wrote: > Device Sleep is a feature as described in AHCI 1.3.1 Technical Proposal. > This feature enables an HBA and SATA storage device to enter the DevSleep > interface state, enabling lower power SATA-based systems. > > Signed-off-by: Shane Huang <shane.huang@xxxxxxx> Am I missing the part where we actually send the command to the drive to *enable* the DevSleep feature? And shouldn't we also read the MDAT/DETO timings from the drive if it provides them (which it optionally can)? Also, don't we need to revalidate the drive after a sleep/wake cycle? How do we do that in the automatic/aggressive sleep case? After my initial reading of the specs, I came to the conclusion that the *sleep* is automatic, but the wakeup still requires careful handling (and we need to ensure that we don't submit commands while it's asleep, etc.)? Since the DevSleep line could just be a GPIO pin, I suspect we are going to want to support platforms where it's not automatic, and we assert/deassert it under direct software control. My test platform does it with an ACPI call, in fact. Have you looked at that mode of operation at all? -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
