From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nathan Bryant <nbryant@optonline.net>
Cc: linux-scsi@vger.kernel.org, Pavel Machek <pavel@ucw.cz>
Subject: Re: device_suspend() levels [was Re: [patch] ACPI work on aic7xxx]
Date: Sun, 25 Jul 2004 18:10:41 -0400 [thread overview]
Message-ID: <1090793440.1987.2.camel@gaston> (raw)
In-Reply-To: <4102FC9D.1060100@optonline.net>
On Sat, 2004-07-24 at 20:19, Nathan Bryant wrote:
> Benjamin Herrenschmidt wrote:
>
> > That's different, because the disks are actually registered as
> > "struct device" childs of the bus, and thus get proper suspend/resume
> > callbacks.
>
> Ok, Seems like we rely on the BIOS a lot, here.
How so ? not at all !
> > Oh sure, the disks are in the loop, the problem happens with multipath
> > and such which "breaks" the bus hiearchy somewhat. The queue management
> > is part of the "functional" hierarchy (read: block layer) on top of
> > SCSI disks, thus the disks will be the one getting the suspend callback,
> > but they have to "notify" their functional parent (block layer, md, ...)
> > to properly get the queues stopped.
>
> All right, I can see where that's probably the easiest solution.
>
> > IDE sort-of does that internally, by generating a special request that
> > goes down the queue (in order to be properly ordered with whatever
> > is pending in the queue, including pending tagged commands if any),
> > and the "toplevel" IDE handling will stop processing the queue once
> > that request got past, but it's a hackery that at this point is quite
> > specific to drivers/ide/
>
> The queued special command trick does mostly the same thing as the
> scsi_device_quiesce(), right? As far as I can tell, the only difference
> is that we attempt to drain the queue (and sometimes leave error
> handlers running) and they just pause it at some mostly sane stopping point.
I don't know, I have to look more closely at the SCSI code.
> Now correct me if I'm wrong, but it seems that with what we understand
> now, we are in a position that we could decide to make SCSI layer do the
> following on suspend, in this order:
>
> scsi_device_quiesce();
> { LLD pause and flush work; aic7xxx will run the completion queue at
> this point }
> blk_stop_queue();
> { LLD reset registers and shutdown, etc }
>
> And once the MD problem is solved we will also need to do another call
> before blk_stop_queue().
>
> Am I missing anything?
We need to issue the stuff from the low level driver (like aix7xxx) or
the disk, that is sd, but we should make sure sg etc... also properly
call the stuff, actually, look at IDE, I defined the special power
request to act as a state machine once down the queue so the ide layer
acts differently for disks, cdroms, etc... by sending appropriate
commands like standby for disks.
Ben.
next prev parent reply other threads:[~2004-07-25 22:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-20 15:22 [patch] ACPI work on aic7xxx Nathan Bryant
2004-07-20 15:59 ` Pavel Machek
2004-07-20 16:48 ` Nathan Bryant
2004-07-20 17:46 ` device_suspend() levels [was Re: [patch] ACPI work on aic7xxx] Pavel Machek
2004-07-20 18:10 ` Nathan Bryant
2004-07-20 18:25 ` Benjamin Herrenschmidt
2004-07-20 18:34 ` Nathan Bryant
2004-07-20 19:10 ` Benjamin Herrenschmidt
2004-07-20 19:23 ` Pavel Machek
[not found] ` <40FD82B1.8030704@optonline.net>
[not found] ` <1090356079.1993.12.camel@gaston>
[not found] ` <40FD85A3.2060502@optonline.net>
[not found] ` <1090357324.1993.15.camel@gaston>
[not found] ` <410280E9.5040001@optonline.net>
[not found] ` <1090684826.1963.6.camel@gaston>
[not found] ` <41029215.1030406@optonline.net>
[not found] ` <1090694118.1971.13.camel@gaston>
2004-07-25 0:19 ` Nathan Bryant
2004-07-25 22:10 ` Benjamin Herrenschmidt [this message]
2004-07-26 7:32 ` Andre Hedrick
2004-07-28 1:18 ` Benjamin Herrenschmidt
2004-07-26 14:02 ` Nathan Bryant
2004-07-28 1:16 ` Benjamin Herrenschmidt
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=1090793440.1987.2.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nbryant@optonline.net \
--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