All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.