From: David Brownell <david-b@pacbell.net>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: klists and struct device semaphores
Date: Thu, 31 Mar 2005 10:18:01 -0800 [thread overview]
Message-ID: <200503311018.02135.david-b@pacbell.net> (raw)
In-Reply-To: <Pine.LNX.4.50.0503310947180.7249-100000@monsoon.he.net>
On Thursday 31 March 2005 9:59 am, Patrick Mochel wrote:
> On Thu, 31 Mar 2005, Alan Stern wrote:
> > On Wed, 30 Mar 2005, Patrick Mochel wrote:
>
> > > In fact, we probably want to add a counter to every device for all "open
> > > connections" so the device doesn't try to automatically sleep while a
> > > device node is open. Once it reaches 0, we can have it enter a
> > > pre-configured state, which should save us a bit of power for very little
> > > pain.
> >
> > By "open connections", do you mean something more than unsuspended
> > children?
>
> Yes, I mean anything that requires the device be awake and functional.
So for example a device that's suspended and enabled for wakeup could be
"open" ... which fights against your "doesn't try to sleep" policy.
Maybe you mean "don't power-off" rather than "don't sleep"? Or are
you maybe assuming PC-style PCI, where nothing (on current Linux)
seems to process PME# wakeup events outside of system sleep states?
(Even when "lspci" shows PME# as active for a device ...)
> This would include open device nodes for many devices, open network
> connections for network devices, active children for bridges and
> controllers, etc.
Same thing applies. Many devices can be suspended but wake up on demand.
And even pass the wakeup events up the hardware connectivity tree. In
fact, being able to do that is a requirement to support that "USB mouse
on Centrino laptop" example: USB mouse suspended, ditto the USB host
controller, then the CPU can enter C3 state and save a few more Watts.
Move mouse, wakeup the USB controller, CPU leaves C3.
In general, good power management will _want_ to leverage such modes.
Worth noting: it's very similar to what modern CPUs do internally,
powering parts off until they're needed. The same model can apply
to other chips; and to boards that integrate those chips...
- Dave
next prev parent reply other threads:[~2005-03-31 18:18 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-26 16:53 klists and struct device semaphores Alan Stern
2005-03-28 16:56 ` Patrick Mochel
2005-03-28 19:48 ` Alan Stern
2005-03-29 16:38 ` Patrick Mochel
2005-03-28 17:44 ` Patrick Mochel
2005-03-28 18:16 ` David Brownell
2005-03-28 18:43 ` Patrick Mochel
2005-03-28 21:58 ` Alan Stern
2005-03-31 2:12 ` Patrick Mochel
2005-03-31 16:18 ` Alan Stern
2005-03-31 17:59 ` Patrick Mochel
2005-03-31 18:18 ` David Brownell [this message]
2005-03-31 18:26 ` Patrick Mochel
2005-03-31 18:46 ` David Brownell
2005-03-31 19:08 ` Patrick Mochel
2005-03-31 19:08 ` Dmitry Torokhov
2005-03-29 16:18 ` Alan Stern
2005-03-29 16:26 ` Dmitry Torokhov
2005-03-31 2:16 ` Patrick Mochel
2005-03-31 3:01 ` Dmitry Torokhov
2005-03-31 5:47 ` Patrick Mochel
2005-03-31 16:24 ` Alan Stern
2005-03-31 18:04 ` Patrick Mochel
2005-03-31 19:49 ` Alan Stern
2005-04-02 18:06 ` Alan Stern
2005-04-06 7:39 ` Patrick Mochel
2005-04-06 19:45 ` Alan Stern
2005-04-07 20:08 ` Patrick Mochel
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=200503311018.02135.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--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