aboutsummaryrefslogtreecommitdiff
path: root/drivers/base/core.c
diff options
context:
space:
mode:
authorAndy Green <andy@openmoko.com>2008-11-19 17:09:50 +0000
committerAndy Green <agreen@pads.home.warmcat.com>2008-11-19 17:09:50 +0000
commit65c79ff69dc050ab6b278ef31389fba60facb2db (patch)
tree9b35d1599c6a71257ffbc7008d87bb88549c34fb /drivers/base/core.c
parenta9a56c3089cfdeb37ed31417a4c95ab4914350d6 (diff)
fix-pcf50633-disable-irq-from-suspend-until-resume.patch
Disable pcf interrupt (not for wake, just as interrupt) in suspend, re-enable it again just before we force-call the workqueue function at end of pcf resume, which leads to pcf interrupt source registers getting cleared so it can signal an interrupt normally again. This change ends the uncontrolled appearance of pcf interrupts during resume time which previously caused the work to attempt to use the I2C stuff before i2c host device had itself resumed. Now the isr work is only queued, and the isr work function called, definitively after pcf resume completes. In suspend time, the work function may have been queued some time before and be pending, and it could still show up at a bad time. Therefore if the work function sees that it is coming since the start of pcf50633 suspend function, it aborts without attempting to read the pcf interrupt regs, leaving them for resume to take care of. USB current limit and no battery work functions are also made aware of suspend state and act accordingly. Lastly I noticed that in early resume, i2c_get_clientdata(&pcf->client) returns NULL, presumably because i2c device is still suspended. This could easily make trouble for async events like interrupt work, since pcf pointer is the client data. Disabling appearance of the work until after pcf50633 resume will also avoid that. Signed-off-by: Andy Green <andy@openmoko.com>
Diffstat (limited to 'drivers/base/core.c')
0 files changed, 0 insertions, 0 deletions