LKML Archive on
help / color / mirror / Atom feed
From: David Brownell <>
To: Zhao Yakui <>
	Zhang Rui <>,
	Maxim Levitsky <>,,,,,
	Holger Macht <>
Subject: Re: [PATCH] ACPI: Add sysfs interface for acpi device wakeup
Date: Wed, 19 Mar 2008 23:12:05 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <1205989967.4061.80.camel@localhost.localdomain>

On Wednesday 19 March 2008, Zhao Yakui wrote:
> On Wed, 2008-03-19 at 11:52 -0700, David Brownell wrote:

> > Currently ACPI wakeup mechanisms are not at all integrated with
> > driver model mechanisms, or with non-ACPI bits of the system.
> > 
> > The "why" of that is that those patches still haven't been merged;
> > and the "why" of *that* is, AFAICT, that ACPI sleep/wake/resume
> > support is still in serious flux.
> > 
> > The current model is, yes, those are just flags ... and they only
> > kick in during driver state transitions.  Someday we can hope
> > they will support runtime power management (e.g. putting PCI
> > devices in PCI_D3hot to save power, then letting them trigger
> > runtime wake events when external hardware asks for that) ...
> > but for now, those transitions only kick in when the system as
> > a whole enters a sleep state, via /sys/power/state writes.
> Right. Now the system only supports that the device wakes the whole
> sleeping system.

That's "barely" supported ... disabled by default, hard to
turn on, rarely (if ever) used, and so on.

> Maybe it is necessary to add the runtime wakeup 
> support. (For example: the PCI device that supports PME)

That'd go more smoothly if we first made the "easier" wake
event support work properly.  After all, that's basically
just making code that's been there for years always kick
in during system sleep transitions, and helping to make sure
the relevant drivers know how to use it ...

> > In short:  only USB portions of the tree have those flags set,
> > since USB (a) has some workarounds for the lack of ACPI support
> > on OHCI and EHCI controllers, like 00:1d.7, and (b) supports
> > those flags for devices that ACPI doesn't know about, such as
> > most USB keyboards, hubs, mice, and so forth.  Plus, (c) you
> > aren't using the rtc-cmos driver, which works better with the
> > rest of Linux than the legacy drivers/char/rtc driver.
> It seems that the following only means that the PME is supported by the
> USB PCI device.
> > /sys/devices/pci0000:00/0000:00:1d.7/power/wakeup

It's set by that HCD as it initializes, because ACPI still
doesn't do so.  There are hardware flags the BIOS sets and
the HCD sees, which in this case partially make up for the
weak support from ACPI.

And it's not specific to PME#, except with EHCI.  With
OHCI for example those flags get set with "legacy" PCI
power management too.

> When the system enters the sleeping state, whether the 1d.7 PCI device
> can wake the system is related to the following two factors:
>     a. /proc/acpi/wakeup flag for 1d.7 PCI device is enabled.
>     b. the Power/wakeup flag in Sys I/F is enabled. ( It means that PME
> is supported and configured)

And the /proc/acpi/wakeup stuff needs to go away, in favor
of standard driver model mechanisms that (a) aren't specific
to ACPI, and (b) don't default to "off, and hard to turn on".

Note that on at least some systems it seems that the ACPI bits
aren't entirely necessary.  When the driver enables PCI wakeup
mechanisms, the hardware reacts well enough to wake the system
even if ACPI has not *also* told it do do so.  (Of course it'd
be better if there were no issues about whether ACPI has been
appropriately stroked.)

> > > Also a second file is missing from which state (S3,S4,S5) the device can
> > > wake the machine up.
> > 
> > Those labels are ACPI-specific, and anything at the core of
> > Linux (like the driver model and its wakeup flags) should
> > never be ACPI-specific!
> Yes. the second file is ACPI-specific. We should add this file.

Why?  "Just because" or is there a real need it would address?

> And the 
> info should be obtained by the associated ACPI device. Maybe it is
> better that it is create in the subdirectory of ACPI device and the link
> is created.

If ACPI-specific state like that "should" be exported, it should
be in an ACPI-specific portion of the tree.  And as for that link,
I'm still not clear on why the patch in

still hasn't merged ... that provides the relevant linkage in
as neutral a way as possible.

> > Plus, it's not clear how much that matters.  It's not as if
> > drivers should prevent entering sleep states if they can't
> > act as wake event sources in that level (e.g. S3 == "mem").
> > That information can stay in /proc/acpi/wakeup until that's
> > finally removed; if no userspace tools need that info, I see
> > no good reason for exporting it.

      reply	other threads:[~2008-03-20  6:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-27  6:47 [PATCH linux-acpi] Fix /proc/acpi/alarm set error Yi Yang
2007-12-27  8:41 ` [PATCH linux-acpi] Remove superfluous code and correct counting error in function acpi_system_write_alarm Yi Yang
2007-12-29  8:22   ` [PATCH linux-acpi] Correct wakeup set error and append a new column PCI ID Yi Yang
2008-01-01 23:20     ` Pavel Machek
2008-01-02  2:03       ` Yi Yang
2008-01-02 16:09         ` Pavel Machek
2008-01-03  2:02           ` Yi Yang
2008-01-03  2:11           ` Yi Yang
2008-01-04  8:16     ` [PATCH linux-acpi] fix acpi fan state set error Yi Yang
2008-01-07  6:56       ` [PATCH] ACPI: fix processor throttling " Yi Yang
2008-01-08  3:21         ` [PATCH] ACPI: fix processor limit " Yi Yang
2008-01-24  0:45           ` [PATCH] ACPI: create proc entry 'power' only if C2 or C3 is supported Yi Yang
2008-01-24 14:43             ` Mark Lord
2008-01-09 22:21         ` [PATCH] ACPI: Add sysfs interface for acpi device wakeup Yi Yang
2008-01-10  7:43           ` Maxim Levitsky
2008-01-09 23:59             ` Yi Yang
2008-01-10 10:30               ` Matthew Garrett
2008-01-13 18:16               ` Pavel Machek
2008-01-11  8:16             ` Zhang Rui
2008-01-10 23:55               ` Yi Yang
2008-03-19 13:06                 ` Thomas Renninger
2008-03-19 14:37                   ` Yi Yang
2008-03-20  4:32                     ` Zhao Yakui
2008-03-19 18:52                   ` David Brownell
2008-03-20  5:12                     ` Zhao Yakui
2008-03-20  6:12                       ` David Brownell [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] ACPI: Add sysfs interface for acpi device wakeup' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).