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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux