suspend blockers & Android integration
in [Kernel]
|
Prev: How do I ignore the changes made by CVS keyword substitution efficiently?
Next: [PATCH 1/2] x86: make save_stack_address() !CONFIG_FRAME_POINTER friendly
From: David Brownell on 11 Jun 2010 22:50 --- On Fri, 6/11/10, James Bottomley <James.Bottomley(a)suse.de> wrote: > > Do we at least have a clean way that a driver can > > reject a system suspend?� I've lost track of > many > > issues, but maybe this could be phrased as a QOS > > constraint:� the current config of driver X > needs > > clock Y active to enter the� target system > suspend > > state, driver's suspend() method reports as > much.� Then the entry to > > that system state gets blocked > > if the clock isn't enabled. > > So in QoS modifications to android patches, the answer is "yes" ... > except that the current android patch set didn't actually > have this type > of wakelock in it. Except, we're not talking "wakelock" ... :) So ... no, these cases still have no solution. (I think that's at least five years now.) > The one thing that does look difficult is that these power > constraints > are device (and sometimes SoC) specific. Exactly why they make good examples for turning up framework limitations... like having overlooked constraints coming from various SoC peripherals. > Expressing them in a generic way > for the cpu govenors to make sense of might be hard. Requiring "CPU governors" to be involved in such stuff feels a bit off-course to me. At least, if the involvement is very deep. The constraints are from the integrated peripherals, not (usually) from the CPU There are plent of places to hang SoC or device specific data, once there's awareness that without such data, (which PCs hide behind ACPI bytecode) the PM framework is missing out on support for some desirable low power modes. > > > (That QOS constraint should be removed when that > > driver no longer needs to issue wakeups; that's > > not quite the same as "removed by driver.resume(). > > The USB one needs user input, doesn't it, I don't quite see that. The drivers get called in enough places, and they'll know if the system is going to be in a suspend state where they need to be partially aactive (with various QOS constraints, or they can't work. > since user hotplug might (or > might not) be one of the wakeup sources. If it wakes via hotplug, then the driver must already Do The Right Thing; what input would be needed (Beyond changing the cable config)? > > James > > > -- -- 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 12 Jun 2010 11:30 On Fri, 11 Jun 2010, Arve Hj�nnev�g wrote: > > Wait a second. �Maybe I have misunderstood how timeouts are supposed to > > work with wakelocks. �I thought the idea was that the wakelock would be > > released when the timeout expires or the event queue is emptied, > > That is one way to use it, and I did this so code that opened an input > device without reading from it would not prevent suspend forever. In > the last patchset I posted, I instead used an ioctl to enable the > suspend blocker. > > > whichever comes first. �Now it sounds like you're saying that the > > wakelock doesn't get released until the timeout expires, even if > > userspace finishes processing all pending events before then. > > > > For incoming network traffic we use a wakelock with a timeout to > prevent suspend long enough for the data to make it to user-space > since we have not added wakelocks to the network stack. > We did this to avoid changing to the network stack, tty layer, etc. I see. These are examples where wakelocks are _not_ released by any userspace action, so they don't seem to fit well into my all-userspace scheme. At least, not in their current form. On the other hand, if the network/tty wakeup events eventually cause data to become available on a socket or device file, then they wouldn't need any special treatment in my scheme. The socket/file descriptors could be handled the same as any others. (Although you might need to change some apps, to make them follow the usual pattern of poll, activate suspend blocker, read, process, release suspend blocker.) In other words, the fact that everything has been moved into userspace means that you wouldn't have to worry about the missing wakelocks in the network stack or tty layer, and consequently wouldn't have to worry about using timed wakelocks there. > > Sure. �But specifically, which drivers on Android generate wakeup > > events? �And which of them don't fully handle their events in their > > interrupt handlers? > > > > Keypad, network, charger, rtc, but I'm sure I forgot some. > > > Maybe another way to put this is: Where in the kernel do you intend to > > add suspend blockers? > > > > In addition to the drivers that enable the wakeup events, we have > added suspend blockers to the input event code and power supply > framework. The tty layer and network stack would also need suspend > blockers to avoid using timeouts. I see. The keypad, charger (power supply), and rtc drivers sound pretty platform-specific. Probably nobody would complain too strongly about adding suspend blockers there. The input, network, and tty layers are more general, though. That's where you're most likely to encounter resistance. People have been complaining about "suspend blockers being added all throughout the kernel". It might help if you pointed out that it's just in these three layers (and maybe at only a few specific points within each layer). 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: Mark Brown on 12 Jun 2010 13:20
On Fri, Jun 11, 2010 at 04:48:15PM -0400, Alan Stern wrote: > On Fri, 11 Jun 2010, Mark Brown wrote: > > The clock framework is implemented independantly for each CPU. > That's not an impediment, since drivers' requirements regarding which > clocks remain running in which power states are necessarily > platform-dependent also. It does mean that you can't make any general statements about what the clock framework does and doesn't do which is what the person I was replying to (the quoting you did as you cut'n'pasted replies to multiple messages seems more than a little confused, sorry) seemed to want. -- 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/ |