http://bugzilla.kernel.org/show_bug.cgi?id=6892
------- Comment #12 from [EMAIL PROTECTED] 2007-10-10 02:46 ------- I think adding a new pci_driver method -- wakeup(), pme(), or whatever -- is the right approach to handling runtime PME# signaling. That would be called by whatever handles the PME# signal. So for example on bare hardware the PME# handler would scan PCI to see which devices report PME status, then call those devices' drivers. (Intel has various IXP platforms which are used that way with Linux, potentially handy for development...) That would need to wake up any parent devices which are in low power states. And ACPI would probably need two mechanisms, if I understand correctly. They'd both key on whether the relevant devices have wakeup() methods. Devices in the southbridge probably have individual GPEs; if they can handle runtime wake events, their GPEs would be enabled when putting the device into a low power state. I found the ACPI spec unclear-to-silent about add-on cards, but I think the story there is that PCI bridges have a GPE for their PME# signal. If that GPE triggers, then the handler would do the same scanning done on bare hardware for non-ACPI systems. The /proc/acpi/wakeup stuff should be irrelevant. Some of the PCI/ACPI wakeup patches I've submitted, but which have not been merged (why??), would need to kick in here. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
