Re: swsusp: don't eat ide disks

>Just send a request down the request list, and make sure that
>
> - the command is marked as being non-mergeable or re-orderable by 
>   software (as all special commands are)
>
> - the command is not re-orderable / mergeable by hardware (and since the
>   command in question would be something like "flush" or "spindown",
>   hardware really would be quite broken if it re-ordered it ;)
>
>and then just wait for its completion.

Ok, good, this is exactly what I was talking about in a
previous mail, escept you have the real code ;)

Though I do insist of this beeing bus ordering driven, that
is this command is to be sent down the queue by the ide-disk driver
itself, when asked for suspend by it's parent, whataver it is
(typically the PCI based controller driver).

That would exactly provide the implementation for the save_state
callback. Though there is still a small issue in using synchronize
cache vs. standby.

Our model currently specify we have save_state (which blocks IOs),
then later on, suspend, which does the actual power off. While this
is actually a good things (especially with swsusp, that should allow
us to not poweroff devices on the path to the disk, a future
optimisation avoiding a full wakeup of all devices), in this specific
case, it also means we can't use the queue at the suspend() state
to send the STANDBY command. If we send the STANDBY command (to
spin off the platters) at save_state() time instead, we get the
chance of have to wait again for re-spinning up on suspend to
disk.

Maybe the fix is as simple as doing sync. cache in save_state, standby
in suspend(), but the later beeing done without using the queue (which
is what I do in my current pmac implementation in 2.4, direct ATA reg.
blasting, ugh !). Or maybe we can find a way to carry a "hint" during
the suspend process so that save_state "knows" the device is marked
as the target for a later suspend to disk process, and "avoids"
doing a standby in that case.

What do you think ?

Ben.