NeilBrown <neilb@xxxxxxx> writes: > On Thu, 19 Jan 2012 11:37:39 -0800 Kevin Hilman <khilman@xxxxxx> wrote: > >> "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. > > While I agree with that, I'm wondering if there might be something else odd > relating to the UARTs that we haven't spotted yet. I suspect the problem for both is constraints that aren't stated explicitly. > I'm chasing done the different problem of HDQ not coping with CPUIDLE but I > think it is very likely to have a similar root cause, as HDQ goes wrong at > the same time that DSS goes wrong, and is a vaguely similar way. > > I just tried compiling omap_hwmod.c with "#define DEBUG" and got some strange > results. Strange indeed. I assume you are you using the runtime PM converted driver from Paul? I tried that branch on my 3530/Overo (console on UART3) and didn't see any nul's on my UART3 console. [...] > The other thing I discovered is that when I set the uart 'sleep_timeout' to 5 > (all uarts) so that CPUIDLE can let CORE enter the lower power states, I get > a fairly steady stream of: > > [ 1168.490478] omap_hwmod: uart1: enabling > [ 1168.490509] omap_hwmod: uart1: enabling clocks > [ 1168.490539] omap_hwmod: uart2: enabling > [ 1168.490539] omap_hwmod: uart2: enabling clocks > [ 1168.490631] omap_hwmod: uart3: enabling > [ 1168.490661] omap_hwmod: uart3: enabling clocks > [ 1168.490661] omap_hwmod: uart4: enabling > [ 1168.490692] omap_hwmod: uart4: enabling clocks > [ 1168.578796] omap_hwmod: uart3: idling > [ 1168.578796] omap_hwmod: uart3: disabling clocks > [ 1168.578826] omap_hwmod: uart4: idling > [ 1168.578826] omap_hwmod: uart4: disabling clocks > [ 1168.578857] omap_hwmod: uart1: idling > [ 1168.578857] omap_hwmod: uart1: disabling clocks > [ 1168.578887] omap_hwmod: uart2: idling > [ 1168.578887] omap_hwmod: uart2: disabling clocks > [ 1168.714263] omap_hwmod: uart1: enabling > [ 1168.714294] omap_hwmod: uart1: enabling clocks > [ 1168.714324] omap_hwmod: uart2: enabling > [ 1168.714324] omap_hwmod: uart2: enabling clocks > [ 1168.714416] omap_hwmod: uart3: enabling > [ 1168.714447] omap_hwmod: uart3: enabling clocks > [ 1168.714447] omap_hwmod: uart4: enabling > [ 1168.714477] omap_hwmod: uart4: enabling clocks > [ 1168.803344] omap_hwmod: uart3: idling > [ 1168.803344] omap_hwmod: uart3: disabling clocks > [ 1168.803375] omap_hwmod: uart4: idling > [ 1168.803375] omap_hwmod: uart4: disabling clocks > [ 1168.851257] omap_hwmod: uart3: enabling > [ 1168.851287] omap_hwmod: uart3: enabling clocks > [ 1168.851318] omap_hwmod: uart4: enabling > [ 1168.851318] omap_hwmod: uart4: enabling clocks > [ 1168.885955] omap_hwmod: uart3: idling > [ 1168.885986] omap_hwmod: uart3: disabling clocks > [ 1168.885986] omap_hwmod: uart4: idling > [ 1168.886016] omap_hwmod: uart4: disabling clocks > [ 1168.886383] omap_hwmod: uart3: enabling > [ 1168.886383] omap_hwmod: uart3: enabling clocks > [ 1168.886383] omap_hwmod: uart4: enabling > [ 1168.886413] omap_hwmod: uart4: enabling clocks > [ 1168.944885] omap_hwmod: uart3: idling > [ 1168.944915] omap_hwmod: uart3: disabling clocks At least this part is expected. In the kernel you're using the UART clocks are enabled/disabled during the idle path depending on the low-power state being targetted, so would expect to see lots of UART clock gating going on. Kevin > It seems to mostly be uart3 and uart4. > If there is any interaction between the uart clock and the hdq clock, this > could explain why the HDQ gets confused when all this is happening. > > And if there is a connection there, then there could also be a connection > with a DSS clock which could be confusing it. > > I admit this is largely surmise and hypothesis - but there is definitely > something odd here! > > Thanks, > NeilBrown -- 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
