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: 3142 bytes --]

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.

But... Isn't the iface clock only needed to program DSS? When the DSS is
just running independently, plain func clock should be enough, right? Or
is iface clock used for the communication between DSS and
CORE/DPLL/wakeup/something?

I also suspect that this could be just a plain DSS bug. The default FIFO
low/high thresholds are 960/1023 bytes (i.e. DSS starts refilling the
FIFO when there are 960 or less bytes in the fifo, and stops at 1023.
The fifo is 1024 bytes). The values are calculated with fifo_size -
burst_size and fifo_size - 1.

We are now using FIFO merge features, which combines multiple fifos into
one when possible, making the fifo size 1024*3 = 3072. Using the same
low threshold and increasing the high threshold to 960/3071 works fine.
Changing the high threshold to 3008 causes underflows. Increasing the
low threshold to ~1600 makes DSS work again.

So I think that the high thresholds of 3071 and 3008 are so close to
each other that there shouldn't be any real difference in practice,
presuming everything works. But, for whatever reason, fetching of the
pixels becomes much more inefficient or with much higher start latency,
causing the underflows.

I guess we'd need HW people to debug this, but their interest in OMAP3
is probably long gone. So I think I'll just have to use values that seem
to work for the use cases we test.

 Tomi


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