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 http://marc.info/?l=linux-acpi&m=120500563430488&w=2 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
