On Thu, 19 Aug 2010, Arve Hjønnevåg wrote: > > Okay. Nevertheless, you maintain debugging info in case a driver bug > > causes a wakelock not to be released. If the wakelocks all had > > timeouts then a bug of that sort wouldn't be able to affect battery > > life very much. So why not add the timeouts? > > > > Because we can't. I just described how the keypad driver would break > we just add a timeout to its wakelock. Other drivers, like the usb > gadget driver may need to block suspend for an extended time period. Some wakelocks can't use timeouts because they may have to be held for extended periods. But the others could have timeouts. > > How much degradation do you think you would observe if in-kernel > > wakelocks _always_ used timeouts alone and _never_ were cancelled? > > > > I don't think that is an option. We have kernel wakelocks that need to > be held while the device is in a specific state. Yes, but what about all the others? What I'm getting at is whether it's feasible for each wakelock to be exclusively used either with timeouts or cancellations, but never both. > > In theory this is insufficient -- it doesn't handle the case where one > > MMC device is enabled for wakeup and another isn't. I assume you don't > > really care about this (especially since Android phones aren't likely > > to have more than one MMC device capable of generating wakeup events). > > > > I'm not sure what you mean by insufficient here. If it not optimal if > you also have work that does not need to prevent suspend, but it > should still work correctly. Yeah, that's what I meant. You would end up blocking suspends unnecessarily. It's okay if it doesn't happen very often. > >> It would be better to allocate the structure when user space changes > >> the setting. If you wait until suspend before blocking suspend you may > >> have passed the event on already. > > > > That will work for the structure directly associated with the device. > > Additional structures allocated by the drivers have to be handled > > differently, because the drivers aren't notified when the wakeup-enable > > setting is changed. > > > > I'm not convinced that is it sufficient to detect that a device is > wakeup-enabled on suspend. It isn't. > However it is not a problem I have tried to > solve since we have only used static wakeup sources. Well, we may need to solve it eventually. One possible solution is to imitate what you're doing with MMC: Use a single per-driver wakelock instead of separate wakelocks for each driver/device combination. I don't know if that would work for all the cases, though. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
