Re: Suspend support for IDE

[Pavel Machek <pavel@ucw.cz>]

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