From: David Brownell <david-b@pacbell.net>
To: shaohua.li@intel.com
Cc: linux-pm@lists.linux-foundation.org, linux-acpi@vger.kernel.org,
stern@rowland.harvard.edu
Subject: Re: [RFC 0/5] device wakeup event support
Date: Mon, 8 Sep 2008 19:41:10 -0700 [thread overview]
Message-ID: <200809081941.10546.david-b@pacbell.net> (raw)
In-Reply-To: <20080908091926.785882370@sli10-desk.sh.intel.com>
On Monday 08 September 2008, shaohua.li@intel.com wrote:
> This series add device wakeup event detection support. This is the base to
> implement runtime device suspend/resume, though we don't support it now.
> But David said USB is approaching to this. See this bugzilla
> http://bugzilla.kernel.org/show_bug.cgi?id=6892 for detail.
Glad to see more attention here. :)
Note that this issue is specific to systems using PCI (at core),
with additional nuances for PCI systems which use ACPI.
Device wakeup through USB works fine on various non-PCI and
non-ACPI embedded systems, without needing these patches.
It's done so for several years now...
> The current process to handle wakeup event is:
> 1. driver enable wakeup event line pme and suspend
> 2. NPME or ACPI receives wakeup event
> 3. NPME or ACPI call .wakeup_event() to clear and disable wakeup
> event. Driver can do extra things in .wakeup_event() too.
> 4. NPME or ACPI call generic wakeup event handler (device_receive_wakeup_event())
> 5. device resumes, and goto 1 for next round of suspend
>
> There are somethings we need discuss:
> 1. is this generic for other platforms?
> 2. what should the generic wakeup event handler do?
>
> Comments and suggestions are welcome!
My reaction re "generic" is that these mechanisms should
be specific to the busses and platforms involved; see my
comments on patch #1.
However this means that for PCI devices, or PCIE, this can
and should be generic enough to work on non-x86 systems.
It's not quite that generic yet, and there are interactions
between PCI/PCIE and ACPI that will need work. But having
those layers clean is important; and you've got a decent
start on that.
Plus there are various other wake-capable devices, like
the PS2 devices and UART in /proc/acpi/wakeup on one of
my systems:
Device S-state Status Sysfs node
PCI0 S4 disabled no-bus:pci0000:00
PS2M S4 disabled pnp:00:05
PS2K S4 disabled pnp:00:06
UAR1 S4 disabled pnp:00:08
USB1 S3 disabled pci:0000:00:03.0
USB2 S3 disabled pci:0000:00:03.1
USB3 S3 disabled <-- BIOS bug: no such hardware
USB4 S3 disabled pci:0000:00:03.3
S139 S4 disabled <-- BIOS bug: no such hardware
LAN S4 disabled pci:0000:00:04.0
MDM S4 disabled <-- MDM and AUD are the same HW??
AUD S4 disabled pci:0000:00:02.7
SLPB S4 *enabled
But getting a good start on the PCI and ACPI runtime wake
framework will help a lot.
- Dave
next prev parent reply other threads:[~2008-09-09 3:03 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-08 9:19 [RFC 0/5] device wakeup event support shaohua.li
2008-09-08 9:19 ` [RFC 1/5] devcore introduce wakeup_event callback shaohua.li
2008-09-09 2:56 ` David Brownell
2008-09-09 3:49 ` Li, Shaohua
2008-09-09 3:49 ` Li, Shaohua
2008-09-09 5:26 ` David Brownell
2008-09-09 8:36 ` Li, Shaohua
2008-09-09 8:36 ` Li, Shaohua
2008-09-09 11:45 ` Rafael J. Wysocki
2008-09-09 11:45 ` Rafael J. Wysocki
2008-09-09 14:22 ` Alan Stern
2008-09-09 14:22 ` Alan Stern
2008-09-09 14:18 ` Alan Stern
2008-09-09 14:18 ` Alan Stern
2008-09-09 15:52 ` David Brownell
2008-09-09 18:39 ` Alan Stern
2008-09-09 18:39 ` Alan Stern
2008-09-09 15:52 ` David Brownell
2008-09-09 5:26 ` David Brownell
2008-09-09 2:56 ` David Brownell
2008-09-08 9:19 ` shaohua.li
2008-09-08 9:19 ` [RFC 2/5] devcore adds generic wakeup event handler shaohua.li
2008-09-08 9:19 ` shaohua.li
2008-09-08 9:19 ` [RFC 3/5] pci wakeup handler shaohua.li
2008-09-08 9:19 ` shaohua.li
2008-09-08 13:09 ` Rafael J. Wysocki
2008-09-08 13:09 ` Rafael J. Wysocki
2008-09-09 1:44 ` Li, Shaohua
2008-09-09 2:56 ` David Brownell
2008-09-09 2:56 ` David Brownell
2008-09-09 3:38 ` Li, Shaohua
2008-09-09 3:38 ` Li, Shaohua
2008-09-09 1:44 ` Li, Shaohua
2008-09-09 2:56 ` David Brownell
2008-09-09 2:56 ` David Brownell
2008-09-09 3:33 ` Li, Shaohua
2008-09-09 3:33 ` Li, Shaohua
2008-09-09 4:04 ` David Brownell
2008-09-09 4:04 ` David Brownell
2008-09-09 11:09 ` Rafael J. Wysocki
2008-09-09 16:18 ` David Brownell
2008-09-09 16:18 ` David Brownell
2008-09-09 11:09 ` Rafael J. Wysocki
2008-09-08 9:19 ` [RFC 4/5] PCIe native PME detection shaohua.li
2008-09-08 9:19 ` shaohua.li
2008-09-08 21:36 ` Rafael J. Wysocki
2008-09-08 21:36 ` Rafael J. Wysocki
2008-09-09 1:21 ` Li, Shaohua
2008-09-09 1:21 ` Li, Shaohua
2008-09-08 9:19 ` [RFC 5/5] ACPI GPE based wakeup event detection shaohua.li
2008-09-08 20:57 ` Rafael J. Wysocki
2008-09-08 20:57 ` Rafael J. Wysocki
2008-09-09 1:13 ` Zhao Yakui
2008-09-09 1:08 ` Li, Shaohua
2008-09-09 11:17 ` Rafael J. Wysocki
2008-09-09 11:17 ` Rafael J. Wysocki
2008-09-09 1:08 ` Li, Shaohua
2008-09-09 14:08 ` Alan Stern
2008-09-09 14:08 ` Alan Stern
2008-09-09 1:13 ` Zhao Yakui
2008-09-08 9:19 ` shaohua.li
2008-09-09 2:41 ` David Brownell [this message]
2008-09-09 3:54 ` [RFC 0/5] device wakeup event support Li, Shaohua
2008-09-09 3:54 ` Li, Shaohua
2008-09-09 2:41 ` David Brownell
-- strict thread matches above, loose matches on Subject: below --
2008-09-08 9:19 shaohua.li
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=200809081941.10546.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=shaohua.li@intel.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.