[lkml]   [2004]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Solving suspend-level confusion

    > > Disks in general are an example (IDE beeing the one that is currently
    > > implemented, but we'll probably have to do the same for SATA and SCSI
    > > at one point), you want to spin them off (with proper cache flush
    > > etc...) when suspending to RAM, while you don't when suspending to
    > > disk, as you really don't want them to be spun up again right away to
    > > write the suspend image.
    > So suspend-to-RAM more or less matches PCI D3hot, and
    > suspend-to-DISK matches PCI D3cold. If those power states
    > were passed to the device suspend(), the disk driver could act
    > appropriately. In my observation, D3cold was never passed
    > down, it was always D3hot.

    Maybe a better approach would be to describe the required features to
    the drivers rather than encoding them in a single integer. Rather
    like passing a request that states "lowest power level with device state
    retained, must not do DMA, enable remote wake up"

    > Though the PM core doesn't cooperate at all there. Neither the
    > suspend nor the resume codepaths cope well with disconnect
    > (and hence device removal), the PM core self-deadlocks since
    > suspend/resume outcalls are done while holding the semaphore
    > that device_pm_remove() needs, ugh.

    Shouldn't we deal with this like a failed resume?

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.026 / U:9.828 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site