public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Nathan Bryant <nbryant@optonline.net>,
	Pavel Machek <pavel@ucw.cz>,
	Linux SCSI Reflector <linux-scsi@vger.kernel.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [PATCH] SCSI midlayer power management
Date: 12 Aug 2004 08:48:06 -0400	[thread overview]
Message-ID: <1092314892.1755.5.camel@mulgrave> (raw)
In-Reply-To: <1092267400.2136.24.camel@gaston>

On Wed, 2004-08-11 at 19:36, Benjamin Herrenschmidt wrote:
> Some hosts will continuously DMA to memory iirc.. I remember having a
> problem with 53c8xx on some macs when transitionning from MacOS to Linux
> because of that.

I think you're thinking of the scripts engine?  on pre 53c875 chips,
yes, this is true.  The on-board processor is executing instructions
from host memory.  However, this is read only in quiescent (waiting for
host connect or target reconnect) mode, so shouldn't be a problem for
suspend.  On the 875 and later, we host the scripts in on-chip memory so
they shouldn't be troubling main memory when idling.

> We need to properly quisce the host, but that's a per host driver thing
> and shouldn't be too difficult.
> 
> Regarding suspend-to-disk, it's fairly easy for the sd driver not to
> spin down the disk for S4 (only for S3). However, we will still probably
> do at least a bus reset when waking up...

Why?  We don't do a bus reset on boot, why should we need to do one on
resume?  For FC, the equivalent, a LIP Reset can be rather nasty on a
SAN and should be avoided.

The slight problem is probably going to be knowing that we may need to
spin up devices (for internal ones) before resuming operation.

James



  parent reply	other threads:[~2004-08-12 12:51 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
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 [this message]
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=1092314892.1755.5.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=benh@kernel.crashing.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nbryant@optonline.net \
    --cc=pavel@ucw.cz \
    /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