Re: AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)

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

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

On 2013-02-14 13:07, Laurent Pinchart wrote:

>> 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.
> 
> Naive question here, instead of killing the overlay completely when an 
> underflow happens, couldn't the DSS driver somehow recover from that condition 
> by restarting whatever needs to be restarted ?

Yes. Killing the overlay is just the safest choice. Presumably if an
underflow happens, the problem is still there, and it'll just happen
again if you re-enable the overlay. Obviously this is not always the
case, as this problem at hand shows.

There's much to improve with the DSS driver's error handling, though. I
think first step would be to remove it totally from DSS, and move it to
omapfb/omapdrm. It's a bit difficult to handle the errors at the lowest
level.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]