Messages in this thread | | | Date | Thu, 12 Aug 2004 09:45:20 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH] SCSI midlayer power management |
| |
Hi!
> > Actually, the answer is to most intents and purposes "yes". You are > > technically correct: there's no way to disable DMA in SCSI. However, > > once a device is quiesced, it has no outstanding commands, so there will > > be no outstanding DMA to that device. When all devices on a host have > > been quiesced, then there will be no DMA at all going on *except* if the > > user initiates any via another interface (like sending a device probe or > > doing a unit scan). The guarantee should be strong enough for swsusp to > > proceed, but we can look at quiescing a host properly (however, we'd > > need to move to a better host state model than we currently possess). > > 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. > > 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... > > Pavel: That's one of the reason I wanted an argument to resume() too so > drivers can make a difference between the immediate wakeup that happens > for writing the image to disk, vs. the real wakeup on resume. In the first > case, SCSI can avoid the bus reset, and any kind of re-configuring, in the > second case, the full stuff might be necessary.
Hmm, and it can not be handled by "just remember why you were suspended", because it is one suspend, two resumes...
Yes, I agree that argument will be usefull. Just who does all the driver updating? ;-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |