> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> The device no longer hits retention if element DMA > mode is taken for at least the duration of the > serial console timeout. Force element DMA mode to > shut down through smartidle. Probably this behaves as you say but it seems possible that the bug is somewhere else in device handling. The generic hope is you can set smart-idle + wakeups at init time and never need to touch them again. There are a few known cases where the hardware IP does have some bug which force you to dynamically play with bits. Clockactivity settings are usually static also, but depending on how you configure your device (slave or master clocking) you will need to dynamically set these. It most you don't need all this dynamic twiddling of the idle protocol handshake bits. Doing it once at pm_init is what should be necessary. One example which comes to mind is MMC with DMA mode. Early drivers were finding RET was gated once the driver was active. In the first pass port to 3430 the writer toggled smart/no/forced idle and the system went happily back to sleep. However, after some profiling it was seen that this method of putting the device down ended up causing the clock disable to the device to take a very long time. Another level of digging into documents was done and it was found that it was necessary to reset some command line as part of a clean shut down. Doing it this way allowed the system to idle, and the time to shut down clocks was just a few nS instead of uS. As I recall some status was not cleared until the reset of the line. It did happen that toggling through handshakes had a side effect of also clearing it, but not in the intended way. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
