Attempted summary of suspend-blockers LKML thread
in [Kernel]
|
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Matthew Garrett on 8 Aug 2010 13:20 On Sun, Aug 08, 2010 at 08:08:33PM +0300, Felipe Contreras wrote: > On Sun, Aug 8, 2010 at 7:08 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: > > It's clearly possible for a pathological Android application to destroy > > the power management policy. But to do that, the author would have to > > explicitly take a wakelock. That's difficult to do by accident. > > The writer can take a wakelock the whole time the application is > running (isn't that the typical case?), because perhaps the author > realizes that way the application works correctly, or he copy-pasted > it from somewhere else. No, that's not the typical case. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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: Rafael J. Wysocki on 8 Aug 2010 13:30 On Saturday, August 07, 2010, Alan Stern wrote: > On Sat, 7 Aug 2010, Rafael J. Wysocki wrote: > > > > Arguably not every PCI interrupt should be regarded as a wakeup event, so > > > I think we can simply say in the cases when that's necessary the driver should > > > be responsible for using pm_wakeup_event() or pm_stay_awake() / pm_relax() as > > > appropriate. > > > > > > My patch only added it to the bus-level code which covered the PME-based > > > wakeup events that _cannot_ be handled by device drivers. > > In other words, your bus-level changes were a necessary but not > sufficient start. I can buy that. > > > Also please note that it depends a good deal on the definition of a "wakeup > > event". Under the definition used when my patch was being developed, ie. that > > wakeup events are the events that would wake up the system from a sleep state, > > PCI interrupts cannot be wakeup events, unless the given device remains in the > > full power state although the system has been suspended (standard PCI devices > > are not allowed to generate signals except for PME from low-power states). > > Um, what do you mean by "event"? Let's take a concrete example. > Suppose you have a system where you want USB plug or unplug events to > cause a wakeup. This is relevant to the discussion at hand if your USB > host controller is a PCI device. > > By your reckoning, a plug or unplug event that occurs while the system > is asleep would be a wakeup event by definition. And yet you say that > the same plug or unplug event occurring while the controller was at > full power would not count as a wakeup event? And in particular, it > should not prevent the system from suspending before the event can be > fully processed? That doesn't make sense. The same event is the same > event, regardless of the context in which it occurs. If it is treated > as a wakeup event in context then it should be treated as a wakeup > event in other contexts too. In this example the event is not a PCI interrupt itself, which is a consqeuence of the event, but the USB plug-unplug. So, whoever detects the plug-unplug should use pm_stay_awake() or pm_wakeup_event(). That may be an interrupt handler of a PCI USB controller, so if that is the case, the controller driver probably should use one of these functions in its interrupt handler. Still, that by no measn implies that _every_ PCI interrupt should in principle be regarded as a wakeup event. Thanks, Rafael -- 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 Brown on 8 Aug 2010 14:40 On 8 Aug 2010, at 18:08, Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > On Sun, Aug 8, 2010 at 7:08 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote: >> It's clearly possible for a pathological Android application to destroy >> the power management policy. But to do that, the author would have to >> explicitly take a wakelock. That's difficult to do by accident. > > The writer can take a wakelock the whole time the application is > running (isn't that the typical case?), because perhaps the author > realizes that way the application works correctly, or he copy-pasted > it from somewhere else. That would be exceptionally unusual. A more common case is that the application will take a wakelock while performing some specific long running task which needs no user intervention such as downloading a file or displaying constantly update status that the user is not expected to respond to. There's no need for applications to take wakelocks while the user is directly interacting with them since the system will be kept awake as a result of the user interaction, the wakelocks are used to override the default suspend that occurs when the user is not interacting with the device.-- 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: Alan Stern on 8 Aug 2010 15:10 On Sun, 8 Aug 2010, Rafael J. Wysocki wrote: > > > Also please note that it depends a good deal on the definition of a "wakeup > > > event". Under the definition used when my patch was being developed, ie. that > > > wakeup events are the events that would wake up the system from a sleep state, > > > PCI interrupts cannot be wakeup events, unless the given device remains in the > > > full power state although the system has been suspended (standard PCI devices > > > are not allowed to generate signals except for PME from low-power states). > > > > Um, what do you mean by "event"? Let's take a concrete example. > > Suppose you have a system where you want USB plug or unplug events to > > cause a wakeup. This is relevant to the discussion at hand if your USB > > host controller is a PCI device. > > > > By your reckoning, a plug or unplug event that occurs while the system > > is asleep would be a wakeup event by definition. And yet you say that > > the same plug or unplug event occurring while the controller was at > > full power would not count as a wakeup event? And in particular, it > > should not prevent the system from suspending before the event can be > > fully processed? That doesn't make sense. The same event is the same > > event, regardless of the context in which it occurs. If it is treated > > as a wakeup event in context then it should be treated as a wakeup > > event in other contexts too. > > In this example the event is not a PCI interrupt itself, which is a consqeuence > of the event, but the USB plug-unplug. So, whoever detects the plug-unplug > should use pm_stay_awake() or pm_wakeup_event(). That may be an > interrupt handler of a PCI USB controller, so if that is the case, the > controller driver probably should use one of these functions in its interrupt > handler. Still, that by no measn implies that _every_ PCI interrupt should in > principle be regarded as a wakeup event. Okay, agreed. I just wanted you to grant that some PCI interrupts should be treated like wakeup events even if they don't actually wake the system up from a sleep state. The "PCI interrupts cannot be wakeup events" statement is a little strong. Alan Stern -- 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: Rafael J. Wysocki on 8 Aug 2010 15:20
On Saturday, August 07, 2010, Arve Hj�nnev�g wrote: > 2010/8/7 Arve Hj�nnev�g <arve(a)android.com>: > > 2010/8/7 Rafael J. Wysocki <rjw(a)sisk.pl>: > >> On Saturday, August 07, 2010, Arve Hj�nnev�g wrote: > >>> 2010/8/6 Alan Stern <stern(a)rowland.harvard.edu>: > >>> > On Thu, 5 Aug 2010, Arve Hj�nnev�g wrote: > ... > >>> >> total_time, total time the wake lock has been active. This one should > >>> >> be obvious. > >>> > > >>> > Also easily added. > >>> > > >>> Only with a handle passed to all the calls. > >> > >> Well, I'm kind of tired of this "my solution is the only acceptable one" > >> mindset. IMHO, it's totally counter productive. > >> > > > > How do you propose to track how long a driver has blocked suspend when > > you have an unblock call that takes no arguments. > > > > Also, I did not not see a response to my question about why you don't > want to pass a handle. It doesn't really matter what I personally want. In fact, I'm not totally opposed to that idea, although there are disadvantages (eg. a "handle" would really mean a pointer to an object with certain life cycle that needs to be managed by the caller and it's not that clear to me who should manage the objects that the PCI wakeup code would pass to pm_wakeup_event(), for one example). I sent a pull request for your original patchset to Linus after all. :-) I said I didn't think "it would fly", meaning that I was afraid the other kernel developers wouldn't like that change. The reason why I think so is that you'd like to add a whole new infrastructure whose only purpose would be debugging that would only be useful to systems using opportunistic suspend. That, however, is only Android right now and it cannot use the mainline kernel for other reasons, so basically we would add infrastructure that's useful to no one. Thanks, Rafael -- 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/ |