lkml.org 
[lkml]   [2002]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: swsusp: don't eat ide disks
    Date
    >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.


    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:2.314 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site