["Rafael J. Wysocki" <rjw@xxxxxxx>] > > Just to make things crystal clear, in fact I don't like any patches in this > series. > > The wakelocks seem to be overdesigned to me and the "early suspend" thing > doesn't really fit our suspend-resume framework, especially after the changes > made recently to the PCI PM code (and the changes that are going to be made > to it shortly). Out of curiosity, do these changes provide a model where the system can be in suspend 99+% of the time, waking up for specific events (voice/data telephony, user interaction, etc), and rapidly returning to suspend when the processing required is complete? That's the larger goal that the wakelock design seeks to accomplish, which is working pretty well for us in shipping mobile devices. Being in suspend, where periodic user and kernel timers aren't running, and random userspace threads aren't possibly spinning, rather than just being in idle in the lowest power possible state, represent a pretty significant power savings. None of the hardware we're working with has a PCI bus, or ACPI, or much of any traditional desktop/server pc features, which may account for some of the difference in outlook and approach here. Brian _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
