From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Linux PCI <linux-pci@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.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
Date: Tue, 6 Oct 2009 23:32:32 +0200 [thread overview]
Message-ID: <200910062332.32132.rjw@sisk.pl> (raw)
In-Reply-To: <20091006103213.1803cb65@jbarnes-g45>
On Tuesday 06 October 2009, Jesse Barnes wrote:
> On Mon, 21 Sep 2009 02:26:10 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > On Monday 14 September 2009, Matthew Garrett wrote:
> > > On Mon, Sep 14, 2009 at 12:53:05AM +0200, Rafael J. Wysocki wrote:
> > > > On Monday 14 September 2009, Matthew Garrett wrote:
> > > > > On Sun, Sep 13, 2009 at 11:24:03PM +0200, Rafael J. Wysocki
> > > > > wrote:
> > > > > > + } else if (!dev->wakeup.flags.run_wake) {
> > > > > > + acpi_set_gpe_type(dev->wakeup.gpe_device,
> > > > > > +
> > > > > > dev->wakeup.gpe_number,
> > > > > > + ACPI_GPE_TYPE_WAKE);
> > > > >
> > > > > Is this going to work for cases where we have multiple devices
> > > > > attached to the same GPE? The common one is EHCI, where both
> > > > > EHCI HCDs will be one a single GPE. If we wake one, that'll
> > > > > then disable the GPE for the other. Further wakeup events will
> > > > > then be lost.
> > > >
> > > > You're right, I overlooked that. Some kind of refcounting is
> > > > needed here.
> > >
> > > I've sent patches to implement this at the GPE level, which also
> > > change the API for requesting them. I'm waiting on feedback from
> > > Bob Moore.
> >
> > In the meantime I realized there's one more thing we need to take
> > care of. Namely, if a wake-up GPE is shared between multiple devices,
> > it need not be necessary to install notify handlers for all of them.
> > For example, if one of these devices is the root bridge, we will walk
> > all of the hierarchy under it looking for devices that have PME set,
> > so we need not install notify handlers for any devices that share the
> > wake-up GPE with the root bridge. Similarly, there's no need to
> > install a notify handler for a device that shares the wake-up GPE
> > with a bridge (non-root) it is under.
> >
> > Taking that into account I have prepared another version of the
> > @subject patch which is appended below. It also takes the PM vs
> > hotplug issue into account. The idea is pretty straightforward,
> > everything should be clear from the changelog and the comments within
> > the patch.
> >
>
> What's the latest on this set? Is this the final version? Anyone have
> issues with this version?
This was the last one I sent, haven't received any feedback whatever.
Perhaps I'll send the entire patchset as is again for completness?
Thanks,
Rafael
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
pm list <linux-pm@lists.linux-foundation.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Len Brown <lenb@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Shaohua Li <shaohua.li@intel.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: Re: [RFC][PATCH 3/4] PCI / ACPI PM: Platform support for PCI PME wake-up
Date: Tue, 6 Oct 2009 23:32:32 +0200 [thread overview]
Message-ID: <200910062332.32132.rjw@sisk.pl> (raw)
In-Reply-To: <20091006103213.1803cb65@jbarnes-g45>
On Tuesday 06 October 2009, Jesse Barnes wrote:
> On Mon, 21 Sep 2009 02:26:10 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > On Monday 14 September 2009, Matthew Garrett wrote:
> > > On Mon, Sep 14, 2009 at 12:53:05AM +0200, Rafael J. Wysocki wrote:
> > > > On Monday 14 September 2009, Matthew Garrett wrote:
> > > > > On Sun, Sep 13, 2009 at 11:24:03PM +0200, Rafael J. Wysocki
> > > > > wrote:
> > > > > > + } else if (!dev->wakeup.flags.run_wake) {
> > > > > > + acpi_set_gpe_type(dev->wakeup.gpe_device,
> > > > > > +
> > > > > > dev->wakeup.gpe_number,
> > > > > > + ACPI_GPE_TYPE_WAKE);
> > > > >
> > > > > Is this going to work for cases where we have multiple devices
> > > > > attached to the same GPE? The common one is EHCI, where both
> > > > > EHCI HCDs will be one a single GPE. If we wake one, that'll
> > > > > then disable the GPE for the other. Further wakeup events will
> > > > > then be lost.
> > > >
> > > > You're right, I overlooked that. Some kind of refcounting is
> > > > needed here.
> > >
> > > I've sent patches to implement this at the GPE level, which also
> > > change the API for requesting them. I'm waiting on feedback from
> > > Bob Moore.
> >
> > In the meantime I realized there's one more thing we need to take
> > care of. Namely, if a wake-up GPE is shared between multiple devices,
> > it need not be necessary to install notify handlers for all of them.
> > For example, if one of these devices is the root bridge, we will walk
> > all of the hierarchy under it looking for devices that have PME set,
> > so we need not install notify handlers for any devices that share the
> > wake-up GPE with the root bridge. Similarly, there's no need to
> > install a notify handler for a device that shares the wake-up GPE
> > with a bridge (non-root) it is under.
> >
> > Taking that into account I have prepared another version of the
> > @subject patch which is appended below. It also takes the PM vs
> > hotplug issue into account. The idea is pretty straightforward,
> > everything should be clear from the changelog and the comments within
> > the patch.
> >
>
> What's the latest on this set? Is this the final version? Anyone have
> issues with this version?
This was the last one I sent, haven't received any feedback whatever.
Perhaps I'll send the entire patchset as is again for completness?
Thanks,
Rafael
next prev parent reply other threads:[~2009-10-06 21:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-13 21:20 [RFC][PATCH 0/4] PCI / ACPI PM: Run-time PM, PME handling and PCI bus type callbacks Rafael J. Wysocki
2009-09-13 21:20 ` [RFC][PATCH 1/4] PCI PM: Add function for checking PME status of devices Rafael J. Wysocki
2009-09-13 22:15 ` Matthew Garrett
2009-09-13 22:15 ` Matthew Garrett
2009-09-13 21:20 ` Rafael J. Wysocki
2009-09-13 21:22 ` [RFC][PATCH 2/4] PCI PM: PCIe PME root port service driver (rev. 3) Rafael J. Wysocki
2009-09-13 21:22 ` Rafael J. Wysocki
2009-09-13 21:24 ` [RFC][PATCH 3/4] PCI / ACPI PM: Platform support for PCI PME wake-up Rafael J. Wysocki
2009-09-13 22:25 ` Matthew Garrett
2009-09-13 22:25 ` Matthew Garrett
2009-09-13 22:53 ` Rafael J. Wysocki
2009-09-13 22:55 ` Matthew Garrett
2009-09-13 23:08 ` Rafael J. Wysocki
2009-09-13 23:08 ` Rafael J. Wysocki
2009-09-21 0:26 ` Rafael J. Wysocki
2009-10-06 17:32 ` Jesse Barnes
2009-10-06 17:32 ` Jesse Barnes
2009-10-06 21:32 ` Rafael J. Wysocki [this message]
2009-10-06 21:32 ` Rafael J. Wysocki
2009-09-21 0:26 ` Rafael J. Wysocki
2009-09-13 22:55 ` Matthew Garrett
2009-09-13 22:53 ` Rafael J. Wysocki
2009-09-13 21:24 ` Rafael J. Wysocki
2009-09-13 21:25 ` [RFC][PATCH 4/4] PCI PM: Run-time callbacks for PCI bus type Rafael J. Wysocki
2009-09-13 21:25 ` 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=200910062332.32132.rjw@sisk.pl \
--to=rjw@sisk.pl \
--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 \
/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.