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/
This archive was generated by hypermail 2b29 : Fri Mar 15 2002 - 22:00:13 EST