public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: PME via interrupt or SCI mechanism?
Date: Mon, 19 Sep 2011 23:43:33 +0200	[thread overview]
Message-ID: <201109192343.33407.rjw@sisk.pl> (raw)
In-Reply-To: <20110912171003.GA7939@xanatos>

Hi,

Sorry for the delayed response, I was traveling during the last week too.

On Monday, September 12, 2011, Sarah Sharp wrote:
> Hi Rafael,
> 
> As I mentioned at LPC, I have a USB host controller that is failing to
> wakeup from D3 when a new USB device is connected to an external hub.
> The system is in S0 at this point.
> 
> You mentioned that there were two ways for hardware to generate PMEs:
> either through the standard PCI interrupt process, or via an ACPI SCI
> call.
> 
> I think the hardware engineers want Linux to set up the PCI device to
> generate PMEs via an SCI call, but I'm not sure if Linux is.  I've tried
> turning on ACPI debugging (with level and layers both set to 0xffffffff
> so I can see all debugging), and I don't see any output at all from ACPI
> functions like acpi_ev_sci_xrupt_handler when the host controller comes
> out of D3.  (It does come out of D3 if I plug in the device within 10
> seconds of PCI suspend, for whatever reason.)
> 
> Is there a way to tell if SCI is being used by a PCI device to generate
> PMEs?

Yes, there is.  First, if the native PCIe PME is used (which means SCI isn't),
there will be entries like these in /proc/interrupts:

 40:          0          0   PCI-MSI-edge      PCIe PME
 41:          0          0   PCI-MSI-edge      PCIe PME
 42:          0          0   PCI-MSI-edge      PCIe PME

If they are not present, it means that the kernel is _trying_ to use SCI
for PME signaling.  In that case, you can check if the number of ACPI
interrupts in /proc/interrupts is increasing when you try to trigger the
events.

In that case you can use the files under /sys/firmware/acpi/interrupts/
to see what GPEs are activated by the wakeup events.


> You also mentioned that Linux has to choose whether to use standard
> interrupts or an SCI to generate PMEs.  You said Linux asks the BIOS if
> the hardware can use interrupts to generate PMEs, and it always uses
> interrupt-based PME generation if the BIOS says yes.

That's correct.

> Do you know where that code is?

drivers/acpi/pci_root.c:acpi_pci_root_add()

> I'd like to see how the BIOS responds to that call, and perhaps get the
> BIOS guys to fix their response if the hardware is supposed to only use
> SCIs to generate PMEs.

The BIOS should respond by clearing bit 2 (PCIe PME) of the control field
returned from _OSC() invoked for the PCIe Root Complex (meaning that the
kernel is not granted control of the native PCIe feature).

Thanks,
Rafael

  reply	other threads:[~2011-09-19 21:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-12 17:10 PME via interrupt or SCI mechanism? Sarah Sharp
2011-09-19 21:43 ` Rafael J. Wysocki [this message]
     [not found]   ` <20110922183201.GA4659@xanatos>
2011-09-25 14:53     ` Rafael J. Wysocki
2011-09-26 22:20       ` Rafael J. Wysocki
2011-09-26 23:48         ` Sarah Sharp
2011-09-27 11:21           ` Luming Yu
2011-09-27 20:32             ` Rafael J. Wysocki
2011-09-28  3:10               ` Luming Yu
2011-09-27 20:54           ` Rafael J. Wysocki
2011-09-27 23:52             ` Sarah Sharp
2011-09-28 22:21               ` Rafael J. Wysocki
2011-09-29  1:40                 ` Matthew Garrett
2011-09-29  9:05                   ` Rafael J. Wysocki
2011-09-29 18:23                 ` Sarah Sharp
2011-09-29 19:39                   ` Rafael J. Wysocki
2011-09-29 20:44                     ` Sarah Sharp
2011-09-29 21:28                       ` Rafael J. Wysocki
2011-09-29 21:38                         ` Rafael J. Wysocki
2011-09-29 21:51                           ` Rafael J. Wysocki
     [not found]                             ` <20110929225700.GA6207@xanatos>
2011-09-30 16:40                               ` Rafael J. Wysocki
2011-09-30 20:21                                 ` Rafael J. Wysocki
2011-10-01  0:30                                   ` Sarah Sharp
2011-10-01 20:29                                     ` Rafael J. Wysocki

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=201109192343.33407.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sarah.a.sharp@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox