11 Apr, 2014

1 commit

  • async_schedule() sd resume work to allow disks and other devices to
    resume in parallel.

    This moves the entirety of scsi_device resume to an async context to
    ensure that scsi_device_resume() remains ordered with respect to the
    completion of the start/stop command. For the duration of the resume,
    new command submissions (that do not originate from the scsi-core) will
    be deferred (BLKPREP_DEFER).

    It adds a new ASYNC_DOMAIN_EXCLUSIVE(scsi_sd_pm_domain) as a container
    of these operations. Like scsi_sd_probe_domain it is flushed at
    sd_remove() time to ensure async ops do not continue past the
    end-of-life of the sdev. The implementation explicitly refrains from
    reusing scsi_sd_probe_domain directly for this purpose as it is flushed
    at the end of dpm_resume(), potentially defeating some of the benefit.
    Given sdevs are quiesced it is permissible for these resume operations
    to bleed past the async_synchronize_full() calls made by the driver
    core.

    We defer the resolution of which pm callback to call until
    scsi_dev_type_{suspend|resume} time and guarantee that the callback
    parameter is never NULL. With this in place the type of resume
    operation is encoded in the async function identifier.

    There is a concern that async resume could trigger PSU overload. In the
    enterprise, storage enclosures enforce staggered spin-up regardless of
    what the kernel does making async scanning safe by default. Outside of
    that context a user can disable asynchronous scanning via a kernel
    command line or CONFIG_SCSI_SCAN_ASYNC. Honor that setting when
    deciding whether to do resume asynchronously.

    Inspired by Todd's analysis and initial proposal [2]:
    https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach

    Cc: Len Brown
    Cc: Phillip Susi
    [alan: bug fix and clean up suggestion]
    Acked-by: Alan Stern
    Suggested-by: Todd Brandt
    [djbw: kick all resume work to the async queue]
    Signed-off-by: Dan Williams

    Dan Williams
     

17 Dec, 2013

1 commit

  • Migrate sr to make use of block layer runtime PM. Accordingly, the
    SCSI bus layer runtime PM callback is simplified as all SCSI drivers
    implementing runtime PM now use the block layer's request-based
    mechanism.

    Note that due to the device will be polled by kernel at a constant
    interval, if the autosuspend delay is set longer than the polling
    interval then the device will never suspend.

    Signed-off-by: Aaron Lu
    Acked-by: Alan Stern
    Signed-off-by: James Bottomley

    Aaron Lu
     

25 Oct, 2013

1 commit

  • It makes no sense to flush the cache of a device without medium.
    Errors during suspend must be handled according to their causes.
    Errors due to missing media or unplugged devices must be ignored.
    Errors due to devices being offlined must also be ignored.
    The error returns must be modified so that the generic layer
    understands them.

    [jejb: fix up whitespace and other formatting problems]
    Signed-off-by: Oliver Neukum
    Acked-by: Alan Stern
    Signed-off-by: James Bottomley

    Oliver Neukum
     

04 Jun, 2013

1 commit

  • The "runtime idle" helper routine, rpm_idle(), currently ignores
    return values from .runtime_idle() callbacks executed by it.
    However, it turns out that many subsystems use
    pm_generic_runtime_idle() which checks the return value of the
    driver's callback and executes pm_runtime_suspend() for the device
    unless that value is not 0. If that logic is moved to rpm_idle()
    instead, pm_generic_runtime_idle() can be dropped and its users
    will not need any .runtime_idle() callbacks any more.

    Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
    routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
    ata_port_runtime_idle(), respectively, as well as a few drivers'
    ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
    been returned by the .runtime_idle() callback executed by it.

    To reduce overall code bloat, make the changes described above.

    Tested-by: Mika Westerberg
    Tested-by: Kevin Hilman
    Signed-off-by: Rafael J. Wysocki
    Acked-by: Kevin Hilman
    Reviewed-by: Ulf Hansson
    Acked-by: Alan Stern

    Rafael J. Wysocki
     

07 May, 2013

1 commit

  • Uses block layer runtime pm helper functions in
    scsi_runtime_suspend/resume for devices that take advantage of it.

    Remove scsi_autopm_* from sd open/release path and check_events path.

    Signed-off-by: Lin Ming
    Signed-off-by: Aaron Lu
    Acked-by: Alan Stern
    Signed-off-by: James Bottomley

    Lin Ming
     

30 Nov, 2012

3 commits

  • Use of pm_message_t is deprecated and device driver is not supposed
    to use that. This patch migrates the SCSI bus level pm callbacks
    to call device's pm callbacks defined in its driver's dev_pm_ops.

    This is achieved by finding out which device pm callback should be used
    in bus callback function, and then pass that callback function pointer
    as a param to the scsi_bus_{suspend,resume}_common routine, which will
    further pass that callback to scsi_dev_type_{suspend,resume} after
    proper handling.

    The special case for freeze in scsi_bus_suspend_common is not necessary
    since there is no high level SCSI driver has implemented freeze, so no
    need to runtime resume the device if it is in runtime suspended state
    for system freeze, just return like the system suspend/hibernate case.

    Since only sd has implemented drv->suspend/drv->resume, and I'll update
    sd driver to use the new callbacks in the following patch, there is no
    need to fallback to call drv->suspend/drv->resume if dev_pm_ops is NULL.

    Signed-off-by: Aaron Lu
    Acked-by: Alan Stern
    Acked-by: Rafael J. Wysocki
    Signed-off-by: James Bottomley

    Aaron Lu
     
  • This reverts commit 28fd00d42cca178638f51c08efa986a777c24a4b.

    With commit 88d26136a256576e444db312179e17af6dd0ea87 (PM: Prevent
    runtime suspend during system resume), this patch is no longer needed.

    Signed-off-by: Aaron Lu
    Acked-by: Alan Stern
    Acked-by: Rafael J. Wysocki
    Signed-off-by: James Bottomley

    Aaron Lu
     
  • This reverts commit 33a2285d96b5e7b9500612ec623bf4313397bb53.

    With commit 88d26136a256576e444db312179e17af6dd0ea87 (PM: Prevent
    runtime suspend during system resume), this patch is no longer needed.

    Signed-off-by: Aaron Lu
    Acked-by: Alan Stern
    Acked-by: Rafael J. Wysocki
    Signed-off-by: James Bottomley

    Aaron Lu
     

20 Jul, 2012

1 commit


22 May, 2012

1 commit

  • For scsi devices which use scsi bus runtime callback, runtime suspend
    will call scsi_dev_type_suspend, and if the drv->suspend failed, the
    device will still be in active state. But since scsi_device_quiesce is
    called, the device will not be able to respond any more commands.
    So add a check here to see if err occured, if so, bring the device back
    to normal state with scsi_device_resume.

    Signed-off-by: Aaron Lu
    Acked-by: Alan Stern
    Signed-off-by: James Bottomley

    Aaron Lu
     

17 May, 2012

1 commit

  • sd injects and synchronizes probe work on the global kernel-wide domain.
    This runs into conflict with PM that wants to perform resume actions in
    async context:

    [ 494.237079] INFO: task kworker/u:3:554 blocked for more than 120 seconds.
    [ 494.294396] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 494.360809] kworker/u:3 D 0000000000000000 0 554 2 0x00000000
    [ 494.420739] ffff88012e4d3af0 0000000000000046 ffff88013200c160 ffff88012e4d3fd8
    [ 494.484392] ffff88012e4d3fd8 0000000000012500 ffff8801394ea0b0 ffff88013200c160
    [ 494.548038] ffff88012e4d3ae0 00000000000001e3 ffffffff81a249e0 ffff8801321c5398
    [ 494.611685] Call Trace:
    [ 494.632649] [] schedule+0x5a/0x5c
    [ 494.674687] [] async_synchronize_cookie_domain+0xb6/0x112
    [ 494.734177] [] ? __init_waitqueue_head+0x50/0x50
    [ 494.787134] [] ? scsi_remove_target+0x48/0x48
    [ 494.837900] [] async_synchronize_cookie+0x15/0x17
    [ 494.891567] [] async_synchronize_full+0x54/0x70 ] ? async_synchronize_full_domain+0x1a/0x1a
    [ 495.002547] [] sd_remove+0x2c/0xa2 [sd_mod]
    [ 495.051861] [] __device_release_driver+0x86/0xcf
    [ 495.104807] [] device_release_driver+0x25/0x32 ] schedule+0x5a/0x5c
    [ 853.949670] [] __mutex_lock_common+0x220/0x351
    [ 854.001225] [] ? device_resume+0x58/0x1c4
    [ 854.049082] [] ? device_resume+0x58/0x1c4
    [ 854.097011] [] mutex_lock_nested+0x2f/0x36 ] device_resume+0x58/0x1c4
    [ 854.192066] [] async_resume+0x1e/0x45
    [ 854.237019] [] async_run_entry_fn+0xc6/0x173
    [alan: uplevel scsi_sd_probe_domain, clarify scsi_device_resume]
    Signed-off-by: Dan Williams
    [jejb: remove unneeded config guards in include file]
    Signed-off-by: James Bottomley

    Dan Williams
     

18 Feb, 2012

1 commit

  • This patch (as1520) fixes a bug in the SCSI layer's power management
    implementation.

    LUN scanning can be carried out asynchronously in do_scan_async(), and
    sd uses an asynchronous thread for the time-consuming parts of disk
    probing in sd_probe_async(). Currently nothing coordinates these
    async threads with system sleep transitions; they can and do attempt
    to continue scanning/probing SCSI devices even after the host adapter
    has been suspended. As one might expect, the outcome is not ideal.

    This is what the "prepare" stage of system suspend was created for.
    After the prepare callback has been called for a host, target, or
    device, drivers are not allowed to register any children underneath
    them. Currently the SCSI prepare callback is not implemented; this
    patch rectifies that omission.

    For SCSI hosts, the prepare routine calls scsi_complete_async_scans()
    to wait until async scanning is finished. It might be slightly more
    efficient to wait only until the host in question has been scanned,
    but there's currently no way to do that. Besides, during a sleep
    transition we will ultimately have to wait until all the host scanning
    has finished anyway.

    For SCSI devices, the prepare routine calls async_synchronize_full()
    to wait until sd probing is finished. The routine does nothing for
    SCSI targets, because asynchronous target scanning is done only as
    part of host scanning.

    Signed-off-by: Alan Stern
    CC:
    Signed-off-by: James Bottomley

    Alan Stern
     

09 Jan, 2012

2 commits

  • [Patch description from Alan Stern]

    If a child device was runtime-suspended when a system suspend began,
    then there will be nothing to prevent its parent from
    runtime-suspending as soon as it is woken up during the system resume.
    Then when the time comes to resume the child, the resume will fail
    because the parent is already back at low power.

    On the other hand, there are some devices which should remain at low
    power across an entire suspend-resume cycle. The details depend on the
    device and the platform.

    This suggests that the PM core is not the right place to solve the
    problem. One possible solution is for the subsystem or device driver
    to call pm_runtime_get_sync(dev->parent) at the start of the
    system-resume procedure and pm_runtime_put_sync(dev->parent) at the
    end.

    Acked-by: Alan Stern
    Signed-off-by: Lin Ming
    Signed-off-by: Jeff Garzik

    Lin Ming
     
  • The only high-level SCSI driver that currently implements runtime PM is
    sd, and sd treats runtime suspend exactly the same as the SUSPEND and
    HIBERNATE stages of system sleep, but not the same as the FREEZE stage.

    Therefore, when entering the SUSPEND or HIBERNATE stages of system
    sleep, we can skip the callback to the driver if the device is already
    in runtime suspend. When entering the FREEZE stage, however, we should
    first issue a runtime resume. The overhead of doing this is
    negligible, because a suspended drive would be spun up during the THAW
    stage of hibernation anyway.

    Signed-off-by: Lin Ming
    Signed-off-by: Alan Stern
    Signed-off-by: Jeff Garzik

    Lin Ming
     

01 Nov, 2011

1 commit


02 Jul, 2011

1 commit

  • Some callers of pm_runtime_get_sync() and other runtime PM helper
    functions, scsi_autopm_get_host() and scsi_autopm_get_device() in
    particular, need to distinguish error codes returned when runtime PM
    is disabled (i.e. power.disable_depth is nonzero for the given
    device) from error codes returned in other situations. For this
    reason, make the runtime PM helper functions return -EACCES when
    power.disable_depth is nonzero and ensure that this error code
    won't be returned by them in any other circumstances. Modify
    scsi_autopm_get_host() and scsi_autopm_get_device() to check the
    error code returned by pm_runtime_get_sync() and ignore -EACCES.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

28 Jul, 2010

2 commits

  • This patch (as1398b) adds runtime PM support to the SCSI layer. Only
    the machanism is provided; use of it is up to the various high-level
    drivers, and the patch doesn't change any of them. Except for sg --
    the patch expicitly prevents a device from being runtime-suspended
    while its sg device file is open.

    The implementation is simplistic. In general, hosts and targets are
    automatically suspended when all their children are asleep, but for
    them the runtime-suspend code doesn't actually do anything. (A host's
    runtime PM status is propagated up the device tree, though, so a
    runtime-PM-aware lower-level driver could power down the host adapter
    hardware at the appropriate times.) There are comments indicating
    where a transport class might be notified or some other hooks added.

    LUNs are runtime-suspended by calling the drivers' existing suspend
    handlers (and likewise for runtime-resume). Somewhat arbitrarily, the
    implementation delays for 100 ms before suspending an eligible LUN.
    This is because there typically are occasions during bootup when the
    same device file is opened and closed several times in quick
    succession.

    The way this all works is that the SCSI core increments a device's
    PM-usage count when it is registered. If a high-level driver does
    nothing then the device will not be eligible for runtime-suspend
    because of the elevated usage count. If a high-level driver wants to
    use runtime PM then it can call scsi_autopm_put_device() in its probe
    routine to decrement the usage count and scsi_autopm_get_device() in
    its remove routine to restore the original count.

    Hosts, targets, and LUNs are not suspended while they are being probed
    or removed, or while the error handler is running. In fact, a fairly
    large part of the patch consists of code to make sure that things
    aren't suspended at such times.

    [jejb: fix up compile issues in PM config variations]
    Signed-off-by: Alan Stern
    Signed-off-by: James Bottomley

    Alan Stern
     
  • This patch (as1397b) converts the SCSI midlayer to use the new PM
    callbacks (struct dev_pm_ops). A new source file, scsi_pm.c, is
    created to hold the new callback routines, and the existing
    suspend/resume code is moved there.

    Signed-off-by: Alan Stern
    Signed-off-by: James Bottomley

    Alan Stern