Arve Hjønnevåg <arve@xxxxxxxxxxx> writes: > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman > <khilman@xxxxxxxxxxxxxxxxxxx> wrote: >> "Rafael J. Wysocki" <rjw@xxxxxxx> writes: >> [...] >>> However, the real question is whether or not the opportunistic suspend feature >>> is worth adding to the kernel as such and I think it is. >>> >>> To me, it doesn't duplicate the runtime PM framework which is aimed at the power >>> management of individual devices rather than the system as a whole. >> >> From the use cases presented, the *usage* of suspend blockers is aimed >> at power management of individual devices or subsystems, just like >> usage of runtime PM. >> > No, suspend blockers are mostly used to ensure wakeup events are not > ignored, and to ensure tasks triggered by these wakeup events > complete. OK, but my point was that their *usage* is at the level of inidividual devices and subsystems, just like runtime PM. Hence, duplicate work. >> So I still see a large duplication in the usage and the goals of both >> frameworks. The goal of both is to always enter lowest-power state >> except >> >> - if there's activity (runtime PM for devices, CPUidle for CPU) >> - if there's a suspend blocker (opportunitic suspend) >> >> In addition, it will likely cause duplicate work to be done in >> drivers. Presumably, PM aware drivers will want to know if the system >> is in opportunistic mode. For example, for many drivers, doing >> runtime PM may not be worth the effort if the system is in >> opportunistic mode. > > Why? If a device is not in use it should be off regardless of what > state the rest of the system is in. Not necessarily. If a device is not in use, what power state it goes into depends on many device/subsystem specific things. For example, recent activity (timeouts), whether it will be busy soon (pending transfers), latency/throughput constraints, dependency on other devices, or any other device/subsystem specific reason. All of these can be handled with runtime PM. None of which are taken into consideration with opportunistic suspend. Kevin _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
