Messages in this thread | | | Date | Sat, 9 Mar 2002 22:03:19 +0100 | From | Pavel Machek <> | Subject | Re: Suspend support for IDE |
| |
Hi!
> > + while (HWGROUP(drive)->handler) > > + schedule(); > > You need to yield. Remember the process might be hard real time and blocking > your real work from occuring. while(foo) schedule() is always a bug
The process calling this is kernel thread doing powermangment; we have it under full control. yield() is probably more intuitive, through.
> > +static int idedisk_resume(struct device *dev, u32 level) > > +{ > > + ide_drive_t *drive = dev->driver_data; > > + if (!drive->blocked) > > + panic("ide: Resume but not suspended?\n"); > > + drive->blocked = 0; > > +} > > Also remember you must perform the sequences to wake up the drive and > restore the controller logic (and of course in the right order). Newer > disks won't just wake up when fed a random command (eg ibm > microdrives)
Wake from S3 or S4 should look like power-up from disks perspective. I should need no commands to do that.
Restoring right UDMA mode... Well, I'll need to do that, probably. (What I have there is just enough to prevent disk corruption. I'm still likely to see some bus resets, but no longer data loose, I believe.)
> The suspend order similarly is important - finish the current > command,
The while loop above should make sure no command is happening just now, right?
> then flush the disk cache, then when it completes you can tell the > drive
Disks that need cache flush are broken, anyway -- they lied us on command completion -- right?
> to power down.
Why should I tell the drive to power down? It is going to loose its power, anyway (I believe in both S3 and S4).
> On some systems you want to drop it back to PIO0 non DMA > before the powerdown or S4BIOS restore from disk will fail.
S4BIOS is not on my list just now; agreed it would be better.
-- (about SSSCA) "I don't say this lightly. However, I really think that the U.S. no longer is classifiable as a democracy, but rather as a plutocracy." --hpa - 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/
| |