diff options
author | Russell King <rmk+kernel@arm.linux.org.uk> | 2012-01-22 20:58:55 +0000 |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2012-01-22 21:10:40 +0000 |
commit | 0af5e4c36e70cfd4ae96d3704a425c414f530f2a (patch) | |
tree | afdc1e7313af454430166d145f7a22e3e94dc961 /include/linux/mfd/mcp.h | |
parent | c23bb602af24a635d0894aa7091e184385bf8a9f (diff) | |
download | linux-0af5e4c36e70cfd4ae96d3704a425c414f530f2a.tar.gz linux-0af5e4c36e70cfd4ae96d3704a425c414f530f2a.tar.bz2 linux-0af5e4c36e70cfd4ae96d3704a425c414f530f2a.zip |
MFD: ucb1x00-ts: fix resume failure
If the ucb1x00 touchscreen is resumed while the touchscreen is being
touched, the main thread stops responding. This occurs because two
things happen:
1. When we suspended, we were woken up, and executed the loop.
Finding that the touchscreen was not pressed, we prepare to
schedule for a maximum timeout, before being stopped in
try_to_freeze().
2. an irq occurs, we disable the irq, and mark it as disabled,
and wake the thread. This wake occurs while the thread is
still within __refrigerator()
3. The thread is unfrozen, and __refrigerator() sets the threads
state back to INTERRUPTIBLE.
We then drop into schedule_timeout() with an infinite timeout and the
IRQ disabled. This prevents any further screen touches activating
the thread.
Fix this by using kthread_freezable_should_stop() which handles the
freezing issues for us outside of the hotspot where the task state
matters. Include a flag to ignore the touchscreen until it is
released to avoid sending unintended data to the application.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'include/linux/mfd/mcp.h')
0 files changed, 0 insertions, 0 deletions