On Thursday 14 February 2013 03:38 PM, Tomi Valkeinen wrote:
On 2013-02-14 11:30, Florian Neuhaus wrote:
Hi Tomi,
Tomi Valkeinen wrote on 2013-02-07:
FIFO underflow means that the DSS hardware wasn't able to fetch enough
pixel data in time to output them to the panel. Sometimes this happens
because of plain misconfiguration, but usually it happens because of
the hardware just can't do things fast enough with the configuration
the user has set.
In this case I see that you are using VRFB rotation on fb0, and the
rotation is
270 degrees. Rotating the fb is heavy, especially 90 and 270 degrees.
It may be that when the DSS is resumed, there's a peak in the mem
usage as DSS suddenly needs to fetch lots of data.
Another issue that could be involved is power management. After the
DSS is suspended, parts of OMAP may be put to sleep. When the DSS is
resumed, these parts need to be woken up, and it may be that there's a
higher mem latency for a short period of time right after resume.
Which could again cause DSS not getting enough pixel data.
You say the issue doesn't happen if you disable fb0. What happens if
you disable fb0, blank the screen, then unblank the screen, and after
that enable fb0 again?
By "disable fb0" do you mean disconnect fb0 from ovl0 or disable ovl0?
I have done both:
http://pastebin.com/Bxm1Z2RY
This works as expected.
I think both disconnecting fb0 and ovl0, and disabling ovl0 end up doing
the same, which is disabling ovl0. Which is what I meant.
So, if I understand correctly, this only happens at unblank, and can be
circumvented by temporarily keeping ovl0 disabled during the unblank,
and enabling ovl0 afterwards works fine.
So for some reason the time of unblank is "extra heavy" for the memory bus.
Archit, I have a feeling that enabling the LCD is heavier on the memory
bus than what happens at VBLANK, even if both start fetching the pixels
for a fresh frame. You've been twiddling with the FIFO stuff, am I right
there?
I don't think it's heavier in terms of memory bandwidth when you enable
the LCD compared to the fetch of new frame content on a VBLANK. In both
cases, the DSS tries to preload a few set of lines.
In terms of responsiveness from the interconnect, it's possible that DSS
has a lower priority(in the round robin queue of initiators) compared to
when it was active.
I don't know if LCD enable vs VBLANK has some sort of difference with VRFB.
Further tests I have done:
Enable fb1/ovl1 and hit some keys on the keyboard to let fb0/ovl0 update in the
background causes a fifo underflow too:
http://pastebin.com/f3JnMLsV
This happens only, if I enable the vrfb (rotate=3). So the whole thing
seems to be a rotation issue. Do you have some hints to trace down
the problem?
Not rotation issue as such, but memory bandwidth issue.
How about if you disable VRFB rotation, either totally, or set the
rotation to 0 or 180 degrees?
Disable rotation is not an option for me, as we have a "wrong" oriented
portrait display with 480x800 which we must use in landscape mode...
I understand, I only meant that for testing purposes. VRFB rotation with
0 and 180 cause a slight impact on the mem bus, whereas 90 and 270
rotation cause a large impact. Also, as I mentioned earlier, the PM may
also affect this, as things may have been shut down in the OMAP. So
disabling PM related features could also "fix" the problem.
In many cases underflows are rather hard to debug and solve. There are
things in the DSS hardware like FIFO thresholds and prefetch, and VRFB
tile sizes, which can be changed (although unfortunately only by
modifying the drivers). How they should be changed if a difficult
question, though, and whether it'll help is also a question mark.
One thing which might help to debug this is to comment out the underflow
error handling, and see if it continues to happen, this will tell if it
was just a temporary bandwidth issue, or it's some consistent PM related
thing
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
