Re: DSS2/PM on 3.2 broken?

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

On Wed, 2012-01-18 at 22:15 +1100, NeilBrown wrote:
> On Wed, 18 Jan 2012 09:13:59 +0200 Tomi Valkeinen <tomi.valkeinen@ti.com>
> 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