Hi David,
> 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)?
Thanks for your feedback. You are right, I received the same suggestion
from copied Aaron, my v2 is already in progress with fixes to both
setting feature and MDAT/DETO.
> 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.)?
The patch only implements the _aggressive_ SATA device sleep(to be
stated in my v2). I don't see the special handling at wakeup stage,
please tell me if you see some specific problems, if we submit commands
while it's asleep, the DevSlp will exit automatically.
> 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?
This patch doesn't care about the software control with PxCMD.ICC,
it only implements the _aggressive_ one.
Regards,
Shane
��.n��������+%������w��{.n�����{��'^�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
