On Thu, 2012-01-19 at 12:21 +0000, Joe Woodward wrote: > 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? Well, none of these sound probable to me. I don't see any connection with GPIOs or UART as such with DSS (I mean something that could cause sync losts). The only thing that I can see affecting DSS via GPIO/UART is indirectly via PM, with voltages or clocks. But if DSS responds in some way, I presume the voltages are ok. And your clocks should be low enough to work with lower OPPs also. So I'm quite out of ideas. Of course there could be a problem in the omapdss when it returns its registers. But it wouldn't explain why the synclosts end if you press a key in the console. > 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? No. That should cause fifo underflows. I don't know the exact reasons for sync_lost, but I think it generally means that the DSS sub-modules lose sync with each other. Mostly this is due to clock config, but can be cause also by other (wrong) configuration which makes a DSS sub-module behave somehow wrong (or halt totally). > And before looking at this too much more, is the changing of the pm_runtime_put to the _sync versions the correct fix? Well. I think it's a correct fix, in functional sense. However, I would like to use non-sync versions normally, but that's just for performance optimization. > 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! The only idea I have currently is to add/enable debug prints which show information about PM changing its states, so we could see if something actually changes at the moment you press a key in the console. What kind of setup did you have again? I wonder if I could reproduce it easily with overo/beagle (it was omap3, wasn't it?)? Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
