lkml.org 
[lkml]   [2010]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Attempted summary of suspend-blockers LKML thread
    On Fri, Aug 06, 2010 at 04:35:59PM -0700, david@lang.hm wrote:
    > On Fri, 6 Aug 2010, Paul E. McKenney wrote:

    Guys, please try to cut unneeded text from the quotes - it makes it much
    easier to find the new text.

    >>> Well, not really from the Linux point of view. It's not massively
    >>> different to something like keeping an ethernet controller sufficiently
    >>> alive to allow it to provide wake on LAN functionality while the system

    >> The wake-on-LAN and the lights-out management systems are indeed
    >> interesting examples, and actually pretty good ones. The reason I
    >> excluded them is that they don't do any application processing -- their
    >> only purpose is the care and feeding of the system itself. In contrast,
    >> the embedded processors are able to do significant applications processing
    >> (e.g., play back music) while any CPUs are completely shut down and most
    >> of the memory is powered down as well.

    This isn't a particularly meaningful distinction, things like the LoM
    systems on servers are generally at least as capable as things like the
    DSPs doing tasks like offloaded MP3 decode and often provide useful
    services in themselves (like system monitoring). It's really just
    semantics to treat them differently to something like a cellular modem -
    at a high level they're both just independant processors ticking away
    without the application processor.

    > one other significant issue is that on the PC, things like wake-on-LAN,
    > lights out management cards, etc require nothing from the main system
    > other than power. If they do something, they are sending the signal to
    > the chipset, which then wakes the system up. they don't interact with the
    > main processor/memory/etc at all.

    I don't see that it makes much difference what gets kept alive - at the
    end of the day the point is that we're making a decision to keep bits of
    the system alive over suspend.

    > So as I see it, we need to do one of two things.

    > 1. change the suspend definition to allow for some things to not be
    > suspended

    This is essentially what's already happening.

    > 2. change the sleep/low-power mode definition to have a more standardized
    > way of turning things off, and extend it to allow clocks to be turned off
    > as well (today we have things able to be turned off, drive spin-down for
    > example, but per comments in this thread it's all one-off methods)

    Currently things like clock trees are frequently managed orthogonaly to
    the system power state to at least some extent anyway - for example,
    perfectly normal wake events like button presses will often require
    clocks for things like debouncing.


    \
     
     \ /
      Last update: 2010-08-07 02:17    [W:2.316 / U:0.640 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site