-----Original Message----- From: Tomi Valkeinen <tomi.valkei...@ti.com> To: Joe Woodward <j...@terrafix.co.uk> Cc: NeilBrown <ne...@suse.de>, Paul Walmsley <p...@pwsan.com>, khil...@ti.com, t-kri...@ti.com, govindra...@ti.com, linux-omap@vger.kernel.org Date: Thu, 19 Jan 2012 13:36:59 +0200 Subject: Re: DSS2/PM on 3.2 broken?
> 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... 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? Is the SYNC_LOST normally due to a lack of memory bandwidth? If so, it is possible to find out what the kernel is doing during the resume? And before looking at this too much more, is the changing of the pm_runtime_put to the _sync versions the correct fix? Sorry for so many questions, but I'm interested in getting this fixed as it's the only thing stopping me from switching to 3.2 from 3.0! Cheers, Joe -- 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
