PM: Make it possible to avoid wakeup events from being lost
in [Kernel]
|
Prev: PM: Make it possible to avoid wakeup events from being lost
Next: Call cond_resched() at bottom of main look in balance_pgdat()
From: Jesse Barnes on 28 Jun 2010 15:20 On Mon, 28 Jun 2010 21:01:53 +0200 "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > --- linux-2.6.orig/drivers/pci/pci.c > +++ linux-2.6/drivers/pci/pci.c > @@ -1275,6 +1275,22 @@ bool pci_check_pme_status(struct pci_dev > return ret; > } > > +/* > + * Time to wait before the system can be put into a sleep state after reporting > + * a wakeup event signaled by a PCI device. > + */ > +#define PCI_WAKEUP_COOLDOWN 100 > + > +/** > + * pci_wakeup_event - Report a wakeup event related to a given PCI device. > + * @dev: Device to report the wakeup event for. > + */ > +void pci_wakeup_event(struct pci_dev *dev) > +{ > + if (device_may_wakeup(&dev->dev)) > + pm_wakeup_event(&dev->dev, PCI_WAKEUP_COOLDOWN); > +} > + > /** > * pci_pme_wakeup - Wake up a PCI device if its PME Status bit is set. > * @dev: Device to handle. > @@ -1285,8 +1301,10 @@ bool pci_check_pme_status(struct pci_dev > */ > static int pci_pme_wakeup(struct pci_dev *dev, void *ign) > { > - if (pci_check_pme_status(dev)) > + if (pci_check_pme_status(dev)) { > pm_request_resume(&dev->dev); > + pci_wakeup_event(dev); > + } > return 0; > } > I assume the units here are ms? And the wakeup event propagation check is pushed down into pci_wakeup_event, is there no place to check whether the device is configured to generate wakeups in the core device or PM code? Other than that, the PCI part is Acked-by: Jesse Barnes <jbarnes(a)virtuousgeek.org> -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 28 Jun 2010 16:50 On Mon, Jun 28, 2010 at 09:01:53PM +0200, Rafael J. Wysocki wrote: > Below is the patch I'd like to add to suspend-2.6/linux-next. Looks nice to me, thanks for doing this: Acked-by: Greg Kroah-Hartman <gregkh(a)suse.de> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 30 Jun 2010 03:20 Hi Rafael! On Mon, 28 Jun 2010 21:01:53 +0200 "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > On Monday, June 28, 2010, Alan Stern wrote: > > On Mon, 28 Jun 2010, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rjw(a)sisk.pl> > Subject: PM: Make it possible to avoid wakeup events from being lost I have nothing substantial to add, but just wanted to let you know that this approach seems like a good alternative to me. As far as I can see the userspace suspend-blocker interface could be expressed in terms of this kernel facility which brings android closer to mainline. The only thing I haven't thought through yet is the 'maintain a discrete set of constraints' vs 'just increment a number' thing. Especially if what we loose in information through that (in comparison to 'the other approach') is made up for by easier in-kernel-API. I _think_ if there is any need for in-kernel-accounting (i don't know that) it could be retro-fitted by using the trace event infrastructure? Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: mark gross on 30 Jun 2010 09:50
On Wed, Jun 30, 2010 at 09:10:38AM +0200, Florian Mickler wrote: > Hi Rafael! > > On Mon, 28 Jun 2010 21:01:53 +0200 > "Rafael J. Wysocki" <rjw(a)sisk.pl> wrote: > > > On Monday, June 28, 2010, Alan Stern wrote: > > > On Mon, 28 Jun 2010, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <rjw(a)sisk.pl> > > Subject: PM: Make it possible to avoid wakeup events from being lost > > I have nothing substantial to add, but just wanted to let you know that > this approach seems like a good alternative to me. As far as I can see > the userspace suspend-blocker interface could be expressed in terms of > this kernel facility which brings android closer to mainline. > > The only thing I haven't thought through yet is the 'maintain a discrete > set of constraints' vs 'just increment a number' thing. Especially if > what we loose in information through that (in comparison to 'the other > approach') is made up for by easier in-kernel-API. I _think_ if there > is any need for in-kernel-accounting (i don't know that) it could be > retro-fitted by using the trace event infrastructure? Adding ftracing hooks and some less invasive partial state or trace support to this and pm_qos is likely the next order of business. --mgross > > Cheers, > Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |