On Wed, 2012-01-18 at 22:15 +1100, NeilBrown wrote: > On Wed, 18 Jan 2012 09:13:59 +0200 Tomi Valkeinen <tomi.valkeinen@xxxxxx> > wrote: > > > On Fri, 2012-01-13 at 22:20 +1100, NeilBrown wrote: > > > Having CPUIDLE makes the DSS2 problem worse: lots of > > > > > > [ 21.085113] omapdss DISPC error: SYNC_LOST on channel lcd, > > > restarting the output with video overlays disabled > > > > > > messages whenever the CPU isn't busy. > > > > I'm not sure if it is the case here, but DSS has restrictions about the > > max DSS clocks on different OPPs. For example, on OMAP4430 LCD clock > > maximum is 186MHz at OPP100, and 93MHz at OPP50. So it's a quite big > > drop, causing problems with all but the rather small displays. > > > > And the DSS driver doesn't have any support to handle this at the > > moment, as there isn't support in the PM framework to do this. I think > > the only way to handle this at the moment is for the DSS driver to set > > an arbitrarily high constraint on, say, mem throughput, and hope that it > > keeps the OMAP in the required OPP. > > > > Tomi > > > > This LCD panel on this device sets: > .pixel_clock = 22000, > in the "struct omap_video_timings" so I'm guessing that is 22MHz? No, that's the pixel clock. There are probably limitations on the pix clock also, but usually the problem is the functional clocks, which need to be n x pck, where n depends on the needs for scaling. 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
