From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [PATCH] SCSI midlayer power management Date: 12 Aug 2004 08:48:06 -0400 Sender: linux-scsi-owner@vger.kernel.org Message-ID: <1092314892.1755.5.camel@mulgrave> References: <4119611D.60401@optonline.net> <20040811080935.GA26098@elf.ucw.cz> <411A1B72.1010302@optonline.net> <1092231462.2087.3.camel@mulgrave> <1092267400.2136.24.camel@gaston> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from stat16.steeleye.com ([209.192.50.48]:27600 "EHLO hancock.sc.steeleye.com") by vger.kernel.org with ESMTP id S268551AbUHLMsY (ORCPT ); Thu, 12 Aug 2004 08:48:24 -0400 In-Reply-To: <1092267400.2136.24.camel@gaston> List-Id: linux-scsi@vger.kernel.org To: Benjamin Herrenschmidt Cc: Nathan Bryant , Pavel Machek , Linux SCSI Reflector , Linux Kernel list , Jeff Garzik 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