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>,
	Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: PME via interrupt or SCI mechanism?
Date: Thu, 29 Sep 2011 23:51:49 +0200	[thread overview]
Message-ID: <201109292351.50176.rjw@sisk.pl> (raw)
In-Reply-To: <201109292338.48690.rjw@sisk.pl>

On Thursday, September 29, 2011, Rafael J. Wysocki wrote:
> On Thursday, September 29, 2011, Rafael J. Wysocki wrote:
> > On Thursday, September 29, 2011, Sarah Sharp wrote:
> > > On Thu, Sep 29, 2011 at 09:39:56PM +0200, Rafael J. Wysocki wrote:
> > > > On Thursday, September 29, 2011, Sarah Sharp wrote:
> > > > > On Thu, Sep 29, 2011 at 12:21:28AM +0200, Rafael J. Wysocki wrote:
> > > > Please try the appended patch and check if you see the "Notification error
> > > > for GPE" message (please keep your previous debug patches applied).
> > > 
> > > Do I need to have the ACPI debug_level or debug_layer set to anything in
> > > particular to see this message?
> > 
> > No, I don't think so, but just in case please try the patch below instead
> > of the previous one.
> 
> Actually, please don't, it's a BIOS-related issue after all.  Apparently,
> wakeup from xHCD is not supported by the BIOS, because the DSDT defines
> the _L0D method for GPE 0D (13), which is the following:
> 
>         Method (_L0D, 0, NotSerialized)
>         {
>             Notify (\_SB.PCI0.EHC1, 0x02)
>             Notify (\_SB.PCI0.EHC2, 0x02)
>             Notify (\_SB.PCI0.HDEF, 0x02)
>             Notify (\_SB.PCI0.GLAN, 0x02)
>         }
> 
> so it notifies some devices, but not the xHCD.
> 
> We might work around this by doing what Matthew has suggested (ie. polling
> all PCI and PCIe devices to check if they have PME pending) or perhaps
> we can do something about this in ACPICA.
> 
> Still, the right fix is to put Notify () for the ACPI objects
> corresponding to xHCD into the above method.

Or to remove this method altogether (in which case our ACPICA code
should take care of the notifications).

Below is a patch (untested!) that should help, but it's kind of
suboptimal.  Nevertheless, please try if it works for you.

Thanks,
Rafael


---
 drivers/pci/pci.c |   57 +++++++++++++++++++-----------------------------------
 1 file changed, 21 insertions(+), 36 deletions(-)

Index: linux/drivers/pci/pci.c
===================================================================
--- linux.orig/drivers/pci/pci.c
+++ linux/drivers/pci/pci.c
@@ -1458,19 +1458,6 @@ static void pci_pme_list_scan(struct wor
 }
 
 /**
- * pci_external_pme - is a device an external PCI PME source?
- * @dev: PCI device to check
- *
- */
-
-static bool pci_external_pme(struct pci_dev *dev)
-{
-	if (pci_is_pcie(dev) || dev->bus->number == 0)
-		return false;
-	return true;
-}
-
-/**
  * pci_pme_active - enable or disable PCI device's PME# function
  * @dev: PCI device to handle.
  * @enable: 'true' to enable PME# generation; 'false' to disable it.
@@ -1480,6 +1467,7 @@ static bool pci_external_pme(struct pci_
  */
 void pci_pme_active(struct pci_dev *dev, bool enable)
 {
+	struct pci_pme_device *pme_dev;
 	u16 pmcsr;
 
 	if (!dev->pm_cap)
@@ -1503,31 +1491,28 @@ void pci_pme_active(struct pci_dev *dev,
 	   hit, and the power savings from the devices will still be a
 	   win. */
 
-	if (pci_external_pme(dev)) {
-		struct pci_pme_device *pme_dev;
-		if (enable) {
-			pme_dev = kmalloc(sizeof(struct pci_pme_device),
-					  GFP_KERNEL);
-			if (!pme_dev)
-				goto out;
-			pme_dev->dev = dev;
-			mutex_lock(&pci_pme_list_mutex);
-			list_add(&pme_dev->list, &pci_pme_list);
-			if (list_is_singular(&pci_pme_list))
-				schedule_delayed_work(&pci_pme_work,
-						      msecs_to_jiffies(PME_TIMEOUT));
-			mutex_unlock(&pci_pme_list_mutex);
-		} else {
-			mutex_lock(&pci_pme_list_mutex);
-			list_for_each_entry(pme_dev, &pci_pme_list, list) {
-				if (pme_dev->dev == dev) {
-					list_del(&pme_dev->list);
-					kfree(pme_dev);
-					break;
-				}
+	if (enable) {
+		pme_dev = kmalloc(sizeof(struct pci_pme_device), GFP_KERNEL);
+		if (!pme_dev)
+			goto out;
+
+		pme_dev->dev = dev;
+		mutex_lock(&pci_pme_list_mutex);
+		list_add(&pme_dev->list, &pci_pme_list);
+		if (list_is_singular(&pci_pme_list))
+			schedule_delayed_work(&pci_pme_work,
+					      msecs_to_jiffies(PME_TIMEOUT));
+		mutex_unlock(&pci_pme_list_mutex);
+	} else {
+		mutex_lock(&pci_pme_list_mutex);
+		list_for_each_entry(pme_dev, &pci_pme_list, list) {
+			if (pme_dev->dev == dev) {
+				list_del(&pme_dev->list);
+				kfree(pme_dev);
+				break;
 			}
-			mutex_unlock(&pci_pme_list_mutex);
 		}
+		mutex_unlock(&pci_pme_list_mutex);
 	}
 
 out:

  reply	other threads:[~2011-09-29 21:49 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
     [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 [this message]
     [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=201109292351.50176.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=mjg59@srcf.ucam.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