diff options
author | Andy Green <andy@openmoko.com> | 2008-11-19 17:09:50 +0000 |
---|---|---|
committer | Andy Green <agreen@pads.home.warmcat.com> | 2008-11-19 17:09:50 +0000 |
commit | 65c79ff69dc050ab6b278ef31389fba60facb2db (patch) | |
tree | 9b35d1599c6a71257ffbc7008d87bb88549c34fb /net/decnet | |
parent | a9a56c3089cfdeb37ed31417a4c95ab4914350d6 (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 'net/decnet')
0 files changed, 0 insertions, 0 deletions