Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

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

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

On Wed, 2012-05-16 at 12:08 +0300, Tomi Valkeinen wrote:
> On Tue, 2012-05-15 at 11:55 -0600, Paul Walmsley wrote:
> > Hello Tomi,
> > 
> > On Mon, 14 May 2012, Tomi Valkeinen wrote:
> > 
> > > I've been doing testing to understand the problem, but so far I don't
> > > have any idea why things go wrong. I haven't found out any logic in
> > > which configuration works and which doesn't. Looks to me that for some
> > > reason the PM prevents DSS from getting data fast enough with certain
> > > fifo thresholds.
> > > 
> > > I have two ways to avoid the problem, but I've been reluctant to make
> > > patches for those because I feel it's just hiding the problem. One way
> > > is to change DISPC SIDLEMODE or MIDLEMODE to disallow idle/standby. The
> > > other is to use certain fifo threshold values, which just seem to work
> > > for unknown reasons.
> > > 
> > > Considering that we already have a SIDLEMODE hack in DSS for omap3 when
> > > using DSI, I wonder if the omap3 PM + DSS combination is just plain
> > > broken, and we should disallow idle. I'm not quite sure what are the
> > > implications of that.
> > > 
> > > I'd appreciate comments from the PM people =).
> > 
> > This may be caused by one of the DPLLs going into autoidle.  This can 
> > involve a significant wakeup latency.  I'd suggest looking at DPLL3, which 
> > provides the DSS interface clock, and DPLL4, which can provide the DSS 
> > functional clock.
> > 
> > Could you try:
> > 
> > 1. applying something like the patch at the bottom of this message and 
> > seeing if it makes any difference?
> > 
> > 2. if #1 does not work, changing the "dpll3" in the patch to "dpll4" ?
> > 
> > 3. if #2 does not work, disabling autoidle on both dpll3 and dpll4?
> 
> Disabling DPLL3 autoidle fixes the problem. Disabling DPLL4 autoidle
> doesn't affect the problem.

JFYI, I also tested changing DISPC's SYSCONFIG:CLOCKACTIVITY, which, to
me, sounds a bit related to dpll autoidle. By default it's 0, "interface
and functional clocks can be switched off". I tested the three other
values, but none of them had any effect.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]