From: Matthew Garrett <mjg59@srcf.ucam.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Linux PCI <linux-pci@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
pm list <linux-pm@lists.linux-foundation.org>
Subject: Re: [RFC][PATCH 3/4] PCI / ACPI PM: Platform support for PCI PME wake-up (rev. 2)
Date: Fri, 9 Oct 2009 12:23:20 +0100 [thread overview]
Message-ID: <20091009112320.GA23990@srcf.ucam.org> (raw)
In-Reply-To: <200910090054.18693.rjw@sisk.pl>
On Fri, Oct 09, 2009 at 12:54:18AM +0200, Rafael J. Wysocki wrote:
> Unfortunately, the subset of PCI devices that have GPEs associated
> with them is quite limited and the other devices have to rely on
> the GPEs associated with their upstream bridges and, possibly, the
> root bridge to generate ACPI wake-up events in response to PMEs from
> them. Moreover, ACPI devices tend to share wake-up GPEs, in which
> cases it makes sense to install an ACPI notify handler for only one
> of them and "bind" the other devices to it. Furthermore, ACPI-based
> PCI hotplug also uses ACPI notify handlers that in general may
> conflict with the PM notify handlers, unless this issue is
> specifically taken care of.
I'm not sure this approach is correct - for instance, from a Dell
system:
Method (_L0D, 0, NotSerialized)
{
Store (SMI (0xC6, 0x00), Local0)
If (And (Local0, 0x01))
{
Notify (\_SB.PCI0.AZAL, 0x02)
}
If (And (Local0, 0x02))
{
Notify (\_SB.PCI0.EHCI, 0x02)
}
If (And (Local0, 0x04))
{
Notify (\_SB.PCI0.EHC2, 0x02)
}
}
All these devices share a GPE, but registering only one notify handler
would result in us missing the notification in some cases. I also
suspect that this should wait until the GPE rework is done.
--
Matthew Garrett | mjg59@srcf.ucam.org
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Linux PCI <linux-pci@vger.kernel.org>,
pm list <linux-pm@lists.linux-foundation.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
Shaohua Li <shaohua.li@intel.com>,
Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: Re: [RFC][PATCH 3/4] PCI / ACPI PM: Platform support for PCI PME wake-up (rev. 2)
Date: Fri, 9 Oct 2009 12:23:20 +0100 [thread overview]
Message-ID: <20091009112320.GA23990@srcf.ucam.org> (raw)
In-Reply-To: <200910090054.18693.rjw@sisk.pl>
On Fri, Oct 09, 2009 at 12:54:18AM +0200, Rafael J. Wysocki wrote:
> Unfortunately, the subset of PCI devices that have GPEs associated
> with them is quite limited and the other devices have to rely on
> the GPEs associated with their upstream bridges and, possibly, the
> root bridge to generate ACPI wake-up events in response to PMEs from
> them. Moreover, ACPI devices tend to share wake-up GPEs, in which
> cases it makes sense to install an ACPI notify handler for only one
> of them and "bind" the other devices to it. Furthermore, ACPI-based
> PCI hotplug also uses ACPI notify handlers that in general may
> conflict with the PM notify handlers, unless this issue is
> specifically taken care of.
I'm not sure this approach is correct - for instance, from a Dell
system:
Method (_L0D, 0, NotSerialized)
{
Store (SMI (0xC6, 0x00), Local0)
If (And (Local0, 0x01))
{
Notify (\_SB.PCI0.AZAL, 0x02)
}
If (And (Local0, 0x02))
{
Notify (\_SB.PCI0.EHCI, 0x02)
}
If (And (Local0, 0x04))
{
Notify (\_SB.PCI0.EHC2, 0x02)
}
}
All these devices share a GPE, but registering only one notify handler
would result in us missing the notification in some cases. I also
suspect that this should wait until the GPE rework is done.
--
Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2009-10-09 11:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-08 22:51 [RFC][PATCH 0/4] PCI run-time Power Management Rafael J. Wysocki
2009-10-08 22:52 ` [RFC][PATCH 1/4] PCI PM: Add function for checking PME status of devices Rafael J. Wysocki
2009-10-08 22:52 ` Rafael J. Wysocki
2009-10-08 23:32 ` Bjorn Helgaas
2009-10-08 23:32 ` Bjorn Helgaas
2009-10-09 22:11 ` Rafael J. Wysocki
2009-10-09 22:11 ` Rafael J. Wysocki
2009-10-08 22:53 ` [RFC][PATCH 2/4] PCI PM: PCIe PME root port service driver (rev. 3) Rafael J. Wysocki
2009-10-08 22:53 ` Rafael J. Wysocki
2009-10-08 22:54 ` [RFC][PATCH 3/4] PCI / ACPI PM: Platform support for PCI PME wake-up (rev. 2) Rafael J. Wysocki
2009-10-08 22:54 ` Rafael J. Wysocki
2009-10-09 11:23 ` Matthew Garrett [this message]
2009-10-09 11:23 ` Matthew Garrett
2009-10-09 23:05 ` Rafael J. Wysocki
2009-10-09 23:05 ` Rafael J. Wysocki
2009-10-08 22:55 ` [RFC][PATCH 4/4] PCI PM: Run-time callbacks for PCI bus type Rafael J. Wysocki
2009-10-08 22:55 ` Rafael J. Wysocki
2009-11-09 22:42 ` [PATCH] pci: Updates to Rafael's runtime PCI PM patch set Matthew Garrett
2009-11-11 19:58 ` Rafael J. Wysocki
2009-11-11 20:05 ` Matthew Garrett
2009-11-11 20:47 ` Rafael J. Wysocki
2009-11-11 20:47 ` Rafael J. Wysocki
2009-11-11 20:05 ` Matthew Garrett
2009-11-11 19:58 ` 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=20091009112320.GA23990@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=rjw@sisk.pl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.