lkml.org 
[lkml]   [2010]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/8] Suspend block api (version 6)
From
On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> 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
--
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/

\
 
 \ /
  Last update: 2010-05-04 02:11    [W:0.921 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site