public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Nathan Bryant <nbryant@optonline.net>
Cc: 'James Bottomley' <James.Bottomley@steeleye.com>,
	Linux SCSI Reflector <linux-scsi@vger.kernel.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	jgarzik@pobox.com
Subject: Re: [PATCH] SCSI midlayer power management
Date: Wed, 11 Aug 2004 10:09:36 +0200	[thread overview]
Message-ID: <20040811080935.GA26098@elf.ucw.cz> (raw)
In-Reply-To: <4119611D.60401@optonline.net>

Hi!

> This proposed patch implements enough power-management support within
> the SCSI midlayer to get ACPI S3 working on my system. Changes as follows:
> 
> * Add generic_scsi_{suspend,resume} methods to scsi.c
> * Add suspend and resume callbacks to the scsi_driver structure, and
> implement those callbacks in sd.c
> * In sd.c, we call sd_shutdown on suspend, in order to synchronize the
> write-back cache.
> * In sd.c, we call sd_rescan from sd_resume in order to ensure that
> drives have spun up and avoid passing not ready errors back to the block
> layer.
> * In generic_scsi_suspend, we call scsi_device_quiesce before calling
> the scsi_driver suspend callback. We resume from quiesce state in
> reverse order in generic_scsi_resume.
> 
> ACPI S1 and S4/swsusp are untested, but I think there should be no
> regressions with S1. To do S1 properly, we probably need to tell the
> drive to spin down, and I don't know what the SCSI command is for
> that... For S4, the call to scsi_device_quiesce might pose a problem for
> the subsequent state dump to disk. But I'm not sure swsusp ever worked
> for SCSI.

swsusp will then resume disk and write the image, that should not be a
problem. Is it guaranteed that after generic_scsi_suspend() no DMA is
going on?

Anyway, you should try swsusp, preferably on some IDE notebook first
and prefereably -mm one, to get feel how it works. It should be
possible/easy to make it work with SCSI...

> This might help SATA drives, too, but I seem to remember that the SATA
> layer doesn't properly emulate the SYNCHRONIZE_CACHE command.
> 
> Comments, anybody? Can this be applied upstream? I think it's a step in
> the right direction.

Looks good to me.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

  reply	other threads:[~2004-08-11  8:13 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-10 23:58 [PATCH] SCSI midlayer power management Nathan Bryant
2004-08-11  8:09 ` Pavel Machek [this message]
2004-08-11 13:13   ` Nathan Bryant
2004-08-11 13:37     ` James Bottomley
2004-08-11 15:21       ` Alan Cox
2004-08-11 16:28         ` James Bottomley
2004-08-11 16:43           ` Nathan Bryant
2004-08-11 23:36       ` Benjamin Herrenschmidt
2004-08-12  7:45         ` Pavel Machek
2004-08-12 10:38           ` Benjamin Herrenschmidt
2004-08-12 12:48         ` James Bottomley
2004-08-12 13:14           ` Pavel Machek
2004-08-12 16:29             ` James Bottomley
2004-08-12 19:11               ` Pavel Machek
2004-08-12 19:34                 ` James Bottomley
2004-08-12 20:26                   ` Pavel Machek
2004-08-12 20:31                     ` James Bottomley
2004-08-12 20:37                       ` Pavel Machek
2004-08-12 20:42                         ` James Bottomley
2004-08-12 20:48                           ` Pavel Machek
2004-08-12 20:52                           ` Nathan Bryant
2004-08-12 20:40                       ` Nathan Bryant
2004-08-12 23:05                       ` Benjamin Herrenschmidt
2004-08-12 22:36                   ` Nigel Cunningham
2004-08-12 22:43                     ` Nigel Cunningham
2004-08-12 23:04                   ` Benjamin Herrenschmidt
2004-08-12 13:41           ` Nathan Bryant
2004-08-12 16:45             ` Patrick Mansfield
2004-08-12 23:02           ` Benjamin Herrenschmidt
2004-08-11 20:19     ` Pavel Machek
2004-08-11 20:50       ` Nathan Bryant
2004-08-11 22:16     ` Nigel Cunningham
2004-08-11 22:48       ` Nathan Bryant
2004-08-12  7:43         ` Pavel Machek
2004-08-12  9:39         ` Nigel Cunningham
2004-08-12 13:43           ` Nathan Bryant
  -- strict thread matches above, loose matches on Subject: below --
2004-08-16 13:29 James.Smart
2004-08-10 23:56 Nathan Bryant
2004-08-11  9:53 ` Alan Cox
2004-08-11 12:55   ` Nathan Bryant
2004-08-11 13:39   ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040811080935.GA26098@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=James.Bottomley@steeleye.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nbryant@optonline.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox