"Joe Woodward" <jw@xxxxxxxxxxxxxx> writes: [...] > If I do (either from the console or via a button press on the screen) > then I never get a SYNC_LOST. > > echo 0 > /sys/devices/omapdss/display0/enabled > echo 1 > /sys/devices/omapdss/display0/enabled > > Just trying to think of some ideas that may be affecting the DSS... > - Could it to be to do with the GPIO being used as a wake source (i.e. does the GPIO driver do runtime_pm properly?)? > - Could it to be to do with the UART as it seems to fix itself whenever a character is pressed? > - Could it to be to do with the ordering in which drivers are resumed? Here's my guess/hunch as to why the UART wakeup helps and GPIO doesn't. The UART's are idled using timeouts, so after any activity (including a wakeup) the UART timeout will not alow the UARTs to idle (and thus the system to hit low power states) for a given timeout period. I don't know what DSS does on wakeup, but presumably it has a burst of activity to do right away. Because of the UART timeout, the DSS probably completes its "burst" of activity before the system ever idles to a low power state. With a GPIO wakeup, the system can (re)idle and possibly hit low power states immediately after the wakeup. If that is the case, that suggests that the DSS probably needs a constraint someplace to prevent this from happening, at least during this "burst" period. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
