[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111001003010.GA26349@xanatos>
Date: Fri, 30 Sep 2011 17:30:10 -0700
From: Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>,
Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: PME via interrupt or SCI mechanism?
On Fri, Sep 30, 2011 at 10:21:06PM +0200, Rafael J. Wysocki wrote:
> OK, please test the appended patch. The difference is that it should only
> continuously poll devices that don't get notifications. You'll still see
> the debug messages from your previous patches, but this one should be a bit
> less wasteful than the previous one in general.
This patch seems to work. The GPE fires and the xHCI host controller
comes out of D3 after a stream of:
Sep 30 17:07:32 talon kernel: [ 197.745312] ehci_hcd 0000:00:1d.0: pci_acpi_wake_dev
Sep 30 17:07:32 talon kernel: [ 197.745321] ehci_hcd 0000:00:1a.0: pci_acpi_wake_dev
Sep 30 17:07:32 talon kernel: [ 197.745326] snd_hda_intel 0000:00:1b.0: pci_acpi_wake_dev
Sep 30 17:07:32 talon kernel: [ 197.745331] e1000e 0000:00:19.0: pci_acpi_wake_dev
It does seem to take less time to come out of D3 than the previous patch
though.
I occasionally do not see the host controller come out of D3 when I plug
in a new device, but the interrupt count for GPE 0D doesn't increment
when that happens, so it's probably just a BIOS or hardware bug. Did
mention this was bleeding edge hardware?
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists