development kernel tree: Changes to 'stable'

[git at git.openmoko.org]

 drivers/i2c/chips/pcf50633.c      |    6 ++++++
 drivers/mfd/glamo/glamo-core.c    |    6 ++++++
 drivers/mfd/glamo/glamo-core.h    |    1 +
 drivers/serial/s3c2410.c          |    7 +++++++
 include/linux/resume-dependency.h |   29 ++++++++++++++++++++++++++++-
 5 files changed, 48 insertions(+), 1 deletions(-)

New commits:
commit 88bf43840b9df0eb0a077a1394eb564be80a412e
Author: Andy Green <andy at openmoko.com>
Date:   Mon Aug 11 20:50:05 2008 +0100

    clean-checkpatch-gsm-resume-dep.patch
    
    Signed-off-by: Andy Green <andy at openmoko.com>

commit 04c9c142a341af62081e856d32149d9f544dbfbe
Author: Andy Green <andy at openmoko.com>
Date:   Mon Aug 11 20:49:56 2008 +0100

    clean-remove-suspend-dependencies-syslog.patch
    
    Signed-off-by: Andy Green <andy at openmoko.com>

commit 36879992de8774cbf8686740bbda383cc6fbdcbb
Author: \\\\\\\"Mike (mwester)\\\\\\ <mwester at dls.net>
Date:   Mon Aug 11 20:16:09 2008 +0100

    always-call-resume-dependencies.patch
    
    Attached is a patch that has greatly reduced the frequency of failures
    to resume (due to an oops from the glamo resume handler), and the
    dreaded "white screen after resume".  I can't say that it fixes all of
    these, although I have yet to see the white-screen since applying this
    patch and suspending/resuming several hundred times (with the 30-second
    suspend on the 2008.8 image and the endless stream of GSM error messages
    generated by something in that image, it has proved to be very useful to
    do an automated stress test!)
    
    This patch will apply to stable, and should make stable slightly more,
    well, "stable".
    
    [Feel free to remove the debug messages if someone feels strongly about
    that; I left them in because I think they might be useful in triaging
    further crashes; I'm not at all convinced that this patch will fix all
    the cases of resume failures.]
    
    [[And, yes, this is ugly, really ugly.]]
    
    [[[Oh yeah - there's still one extreme case that will result in an oops:
     if a dependent driver is built as a module, and it is unloaded, and it
    happened that the preceding suspend/resume was aborted, and that abort
    happened between the dependent driver and the driver upon which it is
    dependent, then a list entry will be left behind referencing the
    unloaded module.  There's just no good way to fix that given the way the
    resume dependency plumbing is connected up right now, so just avoid
    using modules for any of the drivers involved in the resume dependency
    stuff.]]]
    
    Regards,
    Mike (mwester)
    commit 905d2fc9c45f622418ce9ef4e67c23453aab7571
    Author: Mike Westerhof <mwester at dls.net>
    Date:   Mon Aug 11 11:11:25 2008 -0500
    
        always-call-resume-dependencies.patch
    
        Ensure that a dependent resume handler is always executed,
        even if the resume handler for driver upon which it is
        dependent never suspends (and therefore never resumes either).
        Also make sure that we do not end up with duplicate
        dependencies registered, something that can happen if the
        suspend is aborted due to driver failure or an early resume
        (such as occurs when the GSM interrupts during suspend).
    
        Signed-off-by: Mike Westerhof <mwester at dls.net>