[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] SCSI midlayer power management
Pavel Machek wrote:

>>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
>>* 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?
No. Remember that DMA works differently under SCSI than it does under
IDE. SCSI DMA is a host controller feature, whereas under IDE it is
enabled/disabled at the drive level and the drives have special
knowledge of DMA. Since generic_scsi_suspend() is the device level
suspend routine, it is called before the host controller's suspend
routine, (due to depth first traversal of device tree), which is
responsible for disabling the PCI slot. Only after the host controller
is suspended will there be no DMA, but if your real question is "can I
generically control a SCSI disk with PIO for software suspend" then the
answer is NO. For purposes of not suspending the drivers, I haven't
looked into how swsusp would see which host adapter owns which drive,
but some of the required information seems to be present in sysfs.

Now, I don't know how disabling DMA is supposed to behave under SATA.
There may be something extra we have to do that isn't really standard
SCSI... SATA is a weird beast and if somebody is using libata it seems
it might not be possible to use PIO, since enhanced mode might have to
be enabled at the BIOS. But I don't know this stuff, ask jgarzik.

>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...
Does it depend on IDE PIO for some reason? Perhaps related to writing
out a consistent memory image? I'm not sure if I'm motivated to do
anything about that ;)

>>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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.084 / U:23.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site