lkml.org 
[lkml]   [2010]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] [RFC][PATCH] PM: Avoid losing wakeup events during suspend


    --- On Sun, 6/20/10, David Brownell <david-b@pacbell.net> wrote:

    ... in a sort of "aren't we asking the
    wrong questions??" manner ...


    I suspect that
    looking at the problem in terms of how to
    coordinate subsystems (an abstraction which
    is at best very ad-hoc today!) we would
    end up with a cleaner model, which doesn't
    bother so many folk the ay wakelocks or
    even suspend blockers seem to bother them...


    > From: David Brownell <david-b@pacbell.net>
    > Subject: Re: [linux-pm] [RFC][PATCH] PM: Avoid losing wakeup events during suspend
    > To: markgross@thegnar.org, "Alan Stern" <stern@rowland.harvard.edu>
    > Cc: "Neil Brown" <neilb@suse.de>, linux-pm@lists.linux-foundation.org, "Dmitry Torokhov" <dmitry.torokhov@gmail.com>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "mark gross" <640e9920@gmail.com>
    > Date: Sunday, June 20, 2010, 9:04 PM
    >
    > > > > Indeed, the same problem arises if the
    > event
    > > isn't delivered to
    > > > > userspace until after userspace is frozen.
    >
    > Can we put this more directly:  the problem is
    > that the *SYSTEM ISN'T FULLY SUSPENDED* when the
    > hardware wake event triggers?  (Where "*SYSTEM*
    > includes userspace not just kernel.  In fact the
    > overall system is built from many subsystems,
    > some in the kernel and some in userspace.
    >
    > At the risk of being prematurely general:  I'd
    > point out that these subsystems probably have
    > sequencing requirements.  kernel-then-user is
    > a degenerate case, and surely oversimplified.
    > There are other examples, e.g. between kernel
    > subsystems...  Like needing to suspend a PMIC
    > before the bus it uses, where that bus uses
    > a task to manage request/response protocols.
    > (Think I2C or SPI.)
    >
    > This is like the __init/__exit sequencing mess...
    >
    > In terms of userspace event delivery, I'd say
    > it's a bug in the event mechanism if taking the
    > next step in suspension drops any event.  It
    > should be queued, not lost...  As a rule the
    > hardware queuing works (transparently)...
    >
    > > Of course, the underlying
    > > > > issue here is that the kernel has no direct
    > way
    > > to know when userspace
    > > > > has finished processing an event.
    >
    >
    > Again said more directly:  there's no current
    > mechanism to coordinate subsystems.  Userspace
    > can't communicate "I'm ready" to kernel, and
    > vice versa.  (a few decades ago, APM could do
    > that ... we dropped such mechanisms though, and
    > I'm fairly sure APM's implementation was holey.)
    >
    >
    >
    >
    > _______________________________________________
    > linux-pm mailing list
    > linux-pm@lists.linux-foundation.org
    > https://lists.linux-foundation.org/mailman/listinfo/linux-pm
    >

    --
    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-06-21 08:05    [W:5.859 / U:0.284 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site