public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Suspend support for IDE
Date: Sat, 09 Mar 2002 23:08:31 +0100	[thread overview]
Message-ID: <3C8A87DF.7020407@evision-ventures.com> (raw)
In-Reply-To: <20020308180204.GA7035@elf.ucw.cz> <E16jPEs-00073F-00@the-village.bc.nu> <20020309210319.GA691@elf.ucw.cz>

Pavel Machek wrote:

> 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.)

Yeep. But doing this will only be possible in few weeks, when
the corresponding setup code is really modularized and note
the current "ifdef whatever" buch of collected fixes.
However for certain your patch is a starting point and
we are in odd series anyway...

>>The suspend order similarly is important - finish the current
>>command,
>>
> 
> The while loop above should make sure no command is happening just
> now, right?

Beware of the long houl interrupts found by ide_add_timer

>>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?

;-)... And the games they wan't to play on the data registers are
silly as well... if you ask me... well personally they are running
directly into a "backword compatibility to our own mistakes" trap.
The only comparable thing to this was the QIC interfaces abusing the
floppy disk stepper line for *serial* command transfer.


  parent reply	other threads:[~2002-03-09 22:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-08 18:02 Suspend support for IDE Pavel Machek
2002-03-08 18:37 ` Alan Cox
2002-03-08 18:33   ` benh
2002-03-09 21:03   ` Pavel Machek
2002-03-09 22:05     ` Alan Cox
2002-03-10  0:52       ` Barry K. Nathan
2002-03-11  0:10         ` Reid Hekman
2002-03-11  5:47           ` Andre Hedrick
2002-03-10  8:23       ` Rogier Wolff
2002-03-10 22:16         ` Derek J Witt
2002-03-10 22:37           ` Alan Cox
2002-03-11 12:15       ` Pavel Machek
2002-03-09 22:08     ` Martin Dalecki [this message]
2002-03-09 13:02 ` Martin Dalecki
     [not found] <Pine.LNX.4.33.0203101801150.30628-100000@coffee.psychology.mcmaster.ca>
2002-03-11  0:44 ` Derek J Witt
2002-03-11  1:01   ` Mark Hahn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C8A87DF.7020407@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox