On Wednesday 19 March 2008, Thomas Renninger wrote:
And I have some more split-out versions of those patches
now, too. Cleanups and simplifications should be more
directly mergeable, and the tricky bits affecting GPE use
can be addressed by folk who are actively involved in the
nitty-gritty of making the power management parts of ACPI
work right for Linux.
I think I'll repost them soonish, to linux-pm and, as relevant,
to linux-acpi. LKML for stuff that's IMO mergeable as-is.
Right.
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.
There's a bit of state in the ACPI device nodes that's not
currently visible through PCI or PNP. The patch I posted
a while back to cross-link ACPI nodes to the "real" nodes
should help sort out some of that. (Basically, it's just
an updated version of a patch from Zhang Rui.)
Not from me, but that sounds like a useful direction. In
the same vein, it'd make sense to properly root PCI from the
PNP record for the PCI root.
I've not happened across that myself.
Agreed.
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.
If you had applied patches like my "teach ACPI how to use the
wakeup flags", you should see more devices with such flags.
Hmm, and (d) you've got a system that doesn't do much in terms
of ACPI wakeup: a PCI root bridge, and maybe some buttons. Why
that root bridge shows up as a "no-bus" node I don't know...
there's usually a PNP node for it, and otherwise it'd seem like
it should be a PCI device. (The buttons seem to never show up.)
It's not uncommon for the ACPI device tables to list devices
that don't actually exist in /proc/acpi/wakeup. Many of the
devices with no sysfs node seem to be of that type. To me,
this just highlights the current weak handling of wakeups in
the ACPI stack.
Yes.
Because that can change dynamically. Classic example: a USB
device with two active configurations, plus "configuration zero".
Whether it's wakeup-capable depends on a bit in the descriptor
for the active configuration ... so config zero may never waake
the system, while either (or both!) of the active configs might.
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!
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.
That doesn't seem helpful ... it'd mean that you couldn't
manage wakeup policy for individual devices.
This issue is an ACPI-ism, having to do with how wakeup
is implemented on one platform: "GPE" signals, which are
not exposed in any useful way, rather than IRQs (fully
exposed and shareable, see irq_chip.set_wake) or some other
mechanism. So it doesn't belong in the driver model core.
One part of the bug 6892 discussion is specifically about
how PCI bridges don't support wakeup events ... PME# signals,
or their PCIE equivalent, as issued by add-in PCI cards.
I think that'll work better if ACPI gets sane support for
wakeup from the built-in devices first. And oddly enough,
basic patches supporting that have been around for well over
a year now ...
I'll do my bit by (re)reposting the patches I have.
- Dave
--
