From: Oliver Neukum <oliver@neukum.org>
To: David Brownell <david-b@pacbell.net>,
Alan Stern <stern@rowland.harvard.edu>,
linux-usb-devel@lists.sourceforge.net,
Pavel Machek <pavel@ucw.cz>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] error to be returned while suspended
Date: Sat, 7 Oct 2006 12:49:47 +0200 [thread overview]
Message-ID: <200610071249.48194.oliver@neukum.org> (raw)
In-Reply-To: <200610061410.10059.david-b@pacbell.net>
Am Freitag, 6. Oktober 2006 23:10 schrieb David Brownell:
> On Friday 06 October 2006 12:04 am, Oliver Neukum wrote:
> > Am Freitag, 6. Oktober 2006 04:47 schrieb David Brownell:
> > > On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
> > >
> > > > - the issues of manual & automatic suspend and remote wakeup are orthogonal
> > > > - there should be a common API for all devices
> > >
> > > AFAIK there is no demonstrated need for an API to suspend
> > > individual devices. ...
> >
> > I doubt that a lot.
>
> You haven't demonstrated such a need either; so why doubt it?
OK, let me state the basics.
To get real power savings, we:
- blank the display
- spin down the hard drive
- put the CPU into an ACPI sleep state
To do the latter well, we need to make sure there's no DMA. It is
important that less or little DMA will not help. We need no DMA.
So we need to handle the commonest scenarios fully.
I dare say that the commonest scenario involving USB is a laptop with
an input device attached. Input devices are for practical purposes always
opened. A simple resume upon open and suspend upon close is useless.
Now you could et X (and gpm, etc...) to close the device after some
timeout. However, if you do so, you arrive at the counterintuitive
situation that you have to enable remote wakeup for a closed device
and the added complication that you need to generate and propagate
wakeup events. Allowing X to explicitely suspend on opened device is
simpler and more flexible. Furthermore, such a model can be extended
to keyboards.
[..]
> Likewise with autosuspending of network devices, which I'd
> actually like to see happen. Starting in 2.6.19-rc, the USB
> drivers could be updated to do that, as I understand ... at
> least for hardware that has sane remote wakeup capabilities.
> No point in having host controllers doing nothing except
> polling a USB network adapter, unless there's actually some
> traffic directed to that host!
That's true, but insufficient.
Regards
Oliver
next prev parent reply other threads:[~2006-10-07 10:49 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-03 11:23 error to be returned while suspended Oliver Neukum
2006-10-03 12:51 ` linux-os (Dick Johnson)
2006-10-03 13:02 ` Oliver Neukum
2006-10-03 14:17 ` linux-os (Dick Johnson)
2006-10-04 11:19 ` Pavel Machek
2006-10-04 16:34 ` Oliver Neukum
2006-10-04 22:44 ` Pavel Machek
2006-10-05 7:07 ` Oliver Neukum
2006-10-05 8:57 ` Pavel Machek
2006-10-05 16:21 ` [linux-usb-devel] " Alan Stern
2006-10-05 16:35 ` Oliver Neukum
2006-10-05 18:24 ` Alan Stern
2006-10-05 18:43 ` Oliver Neukum
2006-10-05 20:48 ` Alan Stern
2006-10-05 21:25 ` Oliver Neukum
2006-10-05 21:45 ` Alan Stern
2006-10-06 7:21 ` Oliver Neukum
2006-10-06 17:48 ` Alan Stern
2006-10-06 11:25 ` Pavel Machek
2006-10-06 2:47 ` David Brownell
2006-10-06 7:04 ` Oliver Neukum
2006-10-06 11:27 ` Pavel Machek
2006-10-06 14:09 ` Oliver Neukum
2006-10-06 21:10 ` David Brownell
2006-10-07 10:49 ` Oliver Neukum [this message]
2006-10-07 11:08 ` Pavel Machek
2006-10-07 17:16 ` Oliver Neukum
2006-10-08 0:03 ` David Brownell
2006-10-08 2:03 ` Alan Stern
2006-10-08 7:07 ` Oliver Neukum
2006-10-08 14:27 ` Alan Stern
2006-10-08 19:36 ` Pavel Machek
2006-10-08 19:57 ` Oliver Neukum
2006-10-08 21:06 ` Pavel Machek
2006-10-08 6:40 ` Oliver Neukum
2006-10-09 15:56 ` David Brownell
2006-10-08 6:51 ` Oliver Neukum
2006-10-08 7:14 ` Oliver Neukum
2006-10-08 13:24 ` Oliver Neukum
2006-10-08 14:32 ` Alan Stern
2006-10-08 19:41 ` /sys/.../power/state " Pavel Machek
2006-10-08 19:19 ` Pavel Machek
[not found] ` <200610080838.03488.oliver@neukum.org>
[not found] ` <200610080020.49158.david-b@pacbell.net>
2006-10-08 8:39 ` Oliver Neukum
2006-10-08 14:16 ` Dmitry Torokhov
2006-10-06 11:23 ` Pavel Machek
2006-10-06 11:21 ` Pavel Machek
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=200610071249.48194.oliver@neukum.org \
--to=oliver@neukum.org \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=pavel@ucw.cz \
--cc=stern@rowland.harvard.edu \
/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