From: Oliver Neukum <oliver@neukum.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Huang Ying <ying.huang@intel.com>,
ming.m.lin@intel.com, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-pm@vger.kernel.org,
"Rafael J. Wysocki" <rjw@sisk.pl>,
James Bottomley <JBottomley@parallels.com>
Subject: Re: [RFC 0/5] scsi, sd, pm, request based runtime PM for scsi disk
Date: Mon, 13 Feb 2012 10:28:45 +0100 [thread overview]
Message-ID: <201202131028.45806.oliver@neukum.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1202122013300.24811-100000@netrider.rowland.org>
Am Montag, 13. Februar 2012, 02:42:24 schrieb Alan Stern:
> On Sun, 12 Feb 2012, Oliver Neukum wrote:
>
> > Yes, we can use the same heuristics as everywhere.
> > command queued -> autopm_get
> > command finished -> autopm_put
> >
> > but for the USB host adapter, not the sr device
>
> I still don't fully understand. Are you suggesting that we use the
> normal autosuspend timeout mechanism for the disk drive (for example,
> spin down the disk if it hasn't been used for five minutes), and then
Yes. The key here is to realize that from a view point of functionality
they are not suspended. But they will be ready to be suspended.
> autosuspend a USB mass-storage device whenever its children are
> suspended and no commands are in progress? (In fact, there can't be
> any commands in progress if all the children are suspended.)
Really? It is currently true because the device must be opened to issue
commands.
In fact now that you put it this way, it seems to me that this is the
preconception we must shed.
> The SCSI drivers don't know much about the request queue -- the block
> layer manages it. That's another reason for handling this at the block
> layer.
That was refering to SCSI requests.
> Is there some special reason you're talking about sr (the SCSI CD/DVD
> driver) instead of sd (the SCSI disk driver)?
My stupidity.
Regards
Oliver
next prev parent reply other threads:[~2012-02-13 9:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-06 7:32 Huang Ying
2012-02-06 7:32 ` [RFC 1/5] pm, runtime, Add resume notifier Huang Ying
2012-02-06 7:32 ` [RFC 2/5] scsi, pm, rename scsi_autopm_get/put_xxx to scsi_autopm_get/put_xxx_sync Huang Ying
2012-02-06 7:32 ` [RFC 3/5] scsi, pm, add pm_runtime_get/put in scsi request function Huang Ying
2012-02-06 7:32 ` [RFC 4/5] scsi, pm, use autosuspend for scsi runtime PM Huang Ying
2012-02-06 7:32 ` [RFC 5/5] scsi, sd, pm, request based runtime PM support Huang Ying
2012-02-06 15:13 ` [RFC 0/5] scsi, sd, pm, request based runtime PM for scsi disk Alan Stern
2012-02-07 4:59 ` Huang Ying
2012-02-11 19:37 ` Oliver Neukum
2012-02-12 18:05 ` Alan Stern
2012-02-12 20:00 ` Oliver Neukum
2012-02-13 1:42 ` Alan Stern
2012-02-13 9:28 ` Oliver Neukum [this message]
2012-02-13 15:20 ` Alan Stern
2012-02-18 20:44 ` Alan Stern
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=201202131028.45806.oliver@neukum.org \
--to=oliver@neukum.org \
--cc=JBottomley@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
--cc=ying.huang@intel.com \
/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
all inboxes | Powered by JetHome®