On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > "Rafael J. Wysocki" <rjw@xxxxxxx> writes: > >> On Monday 03 May 2010, Mark Brown wrote: >>> On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote: >>> >>> > At least from the kernel perspective, both suspend blockers and >>> > runtime PM have the same goal. Given that, which framework should the >>> > driver writer target? Both? Seems like duplicate effort. Using >>> > suspend blockers assumes the system is in opportunitstic suspend mode >>> > and (at least in the keypad example given) assumes a suspend-blocker >>> > aware userspace (Android.) Without both, targeted power savings will >>> > not be acheived. >>> >>> The other concern here is that for many mobile systems the actual >>> semantic intended by "suspend" as it's currently used is more runtime PM >>> like than full suspend - the classic example of this is that when >>> suspending while on a call in a phone you don't want to suspend the >>> modem or audio CODEC, you want to leave them running. If you use a full >>> system suspend then the drivers for affected components have to play >>> guessing games (or add currently non-standard knobs for apps to twiddle) >>> to decide if the system intends them to actually implement the suspend >>> or not but with runtime PM it all falls out very naturally without any >>> effort on the part of the driver. >>> >>> > To me, runtime PM is a generic and flexible approach that can be used >>> > with any userspace. Driver writers should not have to care whether >>> > the system is in "opportunistic" mode or about whether userspace is >>> > suspend blocker capable. They should only have to think about when >>> > the device is (or should be) idle. >>> >>> I fully agree with this. We do need to ensure that a runtime PM based >>> system can suspend the CPU core and RAM as well as system suspend can >>> but that seems doable. >> >> I _think_ it would be hard at least. On ACPI-based systems it's not doable at >> all AFAICS. > > Please forgive the ignorance of ACPI (in embedded, we thankfully live > in magical world without ACPI) but doesn't that already happen with > CPUidle and C-states? I think of CPUidle as basically runtime PM for > the CPU. IOW, runtime PM manages the devices, CPUidle manages the CPU > (via C-states), resulting in dynaimc PM for the entire system. What > am I missing? > I'm not that familiar with ACPI either, but I think the S-states entered by suspend are much lower power than the C-states entered by idle. >> 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. > 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. > > This last point is especially troubling. I don't find it a comforting > path to go down if the drivers have to start caring about which PM > policy is currently in use. > > Kevin > -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
