On Thu, 2012-01-19 at 11:29 +0000, Joe Woodward wrote: > ... (apologies for awful formatting of the previous mail) ... > > > Well, I don't see how UART could directly affect DSS. The thing that > > comes to my mind is that typing a char in the console causes a change > > in > > the power management, which then "fixes" the DSS. But then again, I'd > > expect the console to go into sleep/idle state after a short while, > > which should again cause sync_losts. But that's not happening... > > > > Can you show the dss clocks you use (cat debugfs/omapdss/clk)? > > > > It's been a while since I did anything with PM, so I don't remember how > > and if it can be done, but a simple test would be to lock the OMAP to > > always use OPP100. > > > > Tomi > > > > Right, > > I'm running with both CPUIDLE and CPUFREQ disabled at present so I assume that means I should always be in OPP100? > > The panel is 800x480 (I've added a configuration to the generic-panel with the correct panel parameters), with just 1 FB device (/dev/fb0). > > Clock dump is shown below: > > # pwd > /debug/omapdss > # cat clk > [ 53.146057] omapdss DSS: dss_runtime_get > [ 53.151000] omapdss DSS: dss_runtime_put > [ 53.155151] omapdss DISPC: dispc_runtime_get > [ 53.160430] omapdss DISPC: dispc_runtime_put > - DSS - > dpll4_ck 432000000 > DSS_FCK (DSS1_ALWON_FCLK) = 432000000 / 12 * 2 = 72000000 > - DISPC - > dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) > fck 72000000 > - LCD1 - > lcd1_clk source = DSS_FCK (DSS1_ALWON_FCLK) > lck 72000000 lck div 1 > pck 36000000 pck div 2 > > > The SYNC_LOST errors sometimes don't happen, and sometimes fix themselves. It does seem that whenever a character is typed in to the UART the SYNC_LOST errors stop immediately. Yep, the clocks are so low that they should work fine with OPP50 also... Tomi -- 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
