diff options
author | Haavard Skinnemoen <haavard.skinnemoen@atmel.com> | 2008-09-13 02:33:23 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-09-13 14:41:52 -0700 |
commit | 3aa04f1b07352be89960bddca4db0d5d8c09510c (patch) | |
tree | da1d1862f745989af20f54f25ed53ab726070324 /fs | |
parent | 8275d102f8dbaa4f437f6b03b00d85bfb4e16025 (diff) | |
download | kernel_samsung_aries-3aa04f1b07352be89960bddca4db0d5d8c09510c.zip kernel_samsung_aries-3aa04f1b07352be89960bddca4db0d5d8c09510c.tar.gz kernel_samsung_aries-3aa04f1b07352be89960bddca4db0d5d8c09510c.tar.bz2 |
atmel_lcdfb: disable LCD and DMA engines when suspending
When suspending the system with atmel_lcdfb enabled, I sometimes see
this:
atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
Which can be explained by the fact that we're not stopping the LCD
controller and its DMA engine when suspending, we're just gating the
clocks to them.
There's another potential issue which may be harder to trigger but
much more nasty: If we gate the clocks at _just_ the right moment,
e.g. when the DMA engine is doing a bus transaction, we may cause the
DMA engine to violate the system bus protocol and cause a lockup.
Avoid these issues by shutting down the LCD controller before entering
suspend (and restarting it when resuming). This prevents the underrun
from happening in the first place, and prevents whatever nastiness is
happening when the bus clock stops in the middle of a DMA transfer.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions