From: Alexander Atanasov <alex@ssi.bg>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC/PATCH] IDE Power Management try 1
Date: Fri, 25 Apr 2003 12:35:50 +0300 [thread overview]
Message-ID: <3EA90176.2080304@ssi.bg> (raw)
In-Reply-To: 1051189194.13267.23.camel@gaston
Hello,
Benjamin Herrenschmidt wrote:
> The point is to pipe the power management requests through the request
> queue for proper locking. Since those requests involve several
> operations that have to be tied together with the queue beeing locked
> for further 'user' requests, they are implemented as a state machine
> with specific callbacks in the subdrivers
>
[cut]
>
> One thing that should probably be cleaned up is the difference between
> the suspend and the resume request. I didn't want to implement 2
> different request bits to avoid using too much of that bit-space, and
> because most of the core handling is the same. So right now, I carry in
> the special structure attached to the request, 2 fields. An int
> indicating if we are doing a suspend or a resume op, and an int that is
> the actual state machine step.
> ===== include/linux/blkdev.h 1.100 vs edited =====
> --- 1.100/include/linux/blkdev.h Sun Apr 20 18:20:10 2003
> +++ edited/include/linux/blkdev.h Thu Apr 24 14:30:50 2003
> @@ -116,6 +116,7 @@
> __REQ_DRIVE_CMD,
> __REQ_DRIVE_TASK,
> __REQ_DRIVE_TASKFILE,
> + __REQ_POWER_MANAGEMENT,
> __REQ_NR_BITS, /* stops here */
> };
What about this - add __REQ_DRIVE_INTERNAL, and carry args in
rq->cmd[16] [0] = PM, [1] = SUSPEND/RESUME, [2]= STATE ? IDE can use it
for power managment, error handling (do not do it from interrupt
context, but queue it), may be more. This way it would really makes
things a bit better with the complicated IDE locking. SCSI and probably
other block devices can benefit from this internal requests too, so the
bit is not wasted.
--
have fun,
alex
next prev parent reply other threads:[~2003-04-25 9:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-24 12:59 [RFC/PATCH] IDE Power Management try 1 Benjamin Herrenschmidt
2003-04-25 9:35 ` Alexander Atanasov [this message]
2003-04-25 10:33 ` Jens Axboe
2003-04-25 11:50 ` Benjamin Herrenschmidt
2003-04-25 12:04 ` Bartlomiej Zolnierkiewicz
2003-04-25 11:32 ` Benjamin Herrenschmidt
2003-04-25 11:49 ` Jens Axboe
2003-04-25 11:52 ` Benjamin Herrenschmidt
2003-04-25 11:57 ` Benjamin Herrenschmidt
2003-04-25 12:13 ` Bartlomiej Zolnierkiewicz
2003-04-25 12:47 ` Benjamin Herrenschmidt
2003-04-25 12:16 ` Bartlomiej Zolnierkiewicz
2003-04-25 12:47 ` Benjamin Herrenschmidt
2003-04-25 13:58 ` Jens Axboe
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=3EA90176.2080304@ssi.bg \
--to=alex@ssi.bg \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).