Messages in this thread | | | Subject | Re: [PATCH 0/8] Suspend block api (version 6) | From | Kevin Hilman <> | Date | Tue, 04 May 2010 11:04:49 -0700 |
| |
Arve Hjønnevåg <arve@android.com> writes:
> On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman > <khilman@deeprootsystems.com> wrote: >> "Rafael J. Wysocki" <rjw@sisk.pl> 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
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |