> Wake from S3 or S4 should look like power-up from disks perspective. I
> should need no commands to do that.
Assuming the BIOS didn't do the work you need to bring the disks up as
if you were the BIOS. That means doing the controller configuration, waking
the drive as per ATA6. What does ACPI guarantee here ? If ACPI brough the
drive back into its "happy bios state" then I agree you are right. If its
like an APM resume from suspend to ram then its not always so clear cut.
Also there is the some fun about buggy drives and power up happenings. On no
account can you issue any command that might touch the platter unless you
know the drive is at full running speed when spinning up certain old drives
because the firmware in some cases forgets to check the drive is at speed
and you physically destroy the disk over time. Thankfully thats old old
drives (540Mb quantum if I remember rightly)
> > then flush the disk cache, then when it completes you can tell the
> > drive
>
> Disks that need cache flush are broken, anyway -- they lied us on
> command completion -- right?
Wrong. Please read the spec. If you are going to be the IDE maintainer you are
wasting your time until you read and understand the specifications. If you
don't do the cache flush you will lose data on some drives. An IDE drive
is permitted to keep a write back cache. Forced writes to the media are in an
upcoming IDE command set draft (although in general you can half fake that
with a read and verify).
> Why should I tell the drive to power down? It is going to loose its
> power, anyway (I believe in both S3 and S4).
So it can shut itself down nicely and do any housework it wants to do
(like flushing the cache if the cache flush command isnt supported.. its
optional in older ATA standards)
> > On some systems you want to drop it back to PIO0 non DMA
> > before the powerdown or S4BIOS restore from disk will fail.
>
> S4BIOS is not on my list just now; agreed it would be better.
Alan
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 15 2002 - 22:00:13 EST