development kernel tree: Changes to 'stable'

[git at git.openmoko.org]

 arch/arm/plat-s3c24xx/neo1973_pm_gsm.c |    4 +-
 drivers/i2c/chips/pcf50633.c           |   30 ++++++++--------
 drivers/mfd/glamo/glamo-mci.c          |   59 ++++++++++++++++++++++++-------
 3 files changed, 62 insertions(+), 31 deletions(-)

New commits:
commit 1d04b142ffeaa15129f046751f1366b0f0614f47
Author: Andy Green <andy at openmoko.com>
Date:   Mon Jul 21 00:51:30 2008 +0100

    debug-add-glamo-drive-strength-module-param.patch
    Suggested-by: Werner Almesberger <werner at openmoko.org>
    
    This patch allows users to control two additional settings
    in Glamo MCI driver from kernel commandline or module
    parameters.
    
    
    First is Glamo drive strength on SD IOs including CLK.
    This ranges from 0 (weakest) to 3 (strongest).
    
    echo 0 > /sys/module/glamo_mci/parameters/sd_drive
    
    (Changes to this take effect on next SD Card transaction)
    
    or, from kernel commandline
    
    glamo_mci.sd_drive=0
    
    On tests here with 0 strength, communication to SD card
    (shipped 512MB Sandisk) seemed fine, and a dd of 10MB
    urandom had the same md5 when written to cache as after
    a reboot.  I set the default to 2.
    
    
    Second is whether we allow SD_CLK when the SD interface
    is idle.
    
    # stop the clock when we are idle (default)
    echo 0 > /sys/module/glamo_mci/parameters/sd_idleclk
    
    # run the SD clock all the time
    echo 1 > /sys/module/glamo_mci/parameters/sd_idleclk
    
    (changes take effect on next SD Card transaction)
    
    From kernel commandline, eg:
    
    glamo_mci.sd_idleclk=1
    
    Normally you don't want to run the SD Clock all the time.
    
    
    Signed-off-by: Andy Green <andy at openmoko.com>

commit 7588286c13ce04de9ce9b9a844033e07d0e71c93
Author: Andy Green <andy at openmoko.com>
Date:   Mon Jul 21 00:51:15 2008 +0100

    debug-move-dev-info-to-dbg.patch
    Suggested-by: Sean McNeil <sean at mcneil.com>
    
    To see if some subtle race is involved, Sean has tried
    removing syslog traffic during resume and found he was
    not seeing the resume crash any more.  We're giving it
    a try to see if it changes the behaviour for anyone
    else.  It would mean we have a pretty fine race in there
    somewhere.
    
    Signed-off-by: Andy Green <andy at openmoko.com>