• Jeffrey Lee's avatar
    Big refactor, introduce GraphicsV overlay API support · e285399d
    Jeffrey Lee authored
    Detail:
      This change introduces initial support for the GraphicsV overlay API.
      RGB & YUV overlays are supported, along with rotation and scaling.
      Vertical flipping isn't supported yet, and there are still a number of bugs to track down, along with some potential improvements.
      The code has also been refactored significantly, in an attempt to protect all critical state with spinlocks/mutexes (as appropriate), and to reduce the number of globals so that it's easier to see what's touching what. Previously very little locking was performed, which could lead to issues if VSyncs or synclost interrupts occurred during certain operations. Now, the data should be structured in such a way that this shouldn't cause problems.
      Notable things:
      * State which needs to be writable from interrupt handlers is protected by spinlocks
      * State which needs to be readable from interrupt handlers is protected by reader-writer spinlocks
      * State which doesn't need to be accessed from interrupt handlers is unprotected (mutexes can be introduced in the future to make the code SMP-safe)
      * Using non-alpha screen modes for the desktop will currently result in only "basic" overlays being supported (i.e. overlays which appear ontop of the desktop). In some cases this could be improved by falling back to a software pointer, but for now the only way to get Z-Order overlays is to use a screen mode with an alpha channel.
      * Memory allocation for overlays is abstracted via the buffer interface (h/buffer). This has three implementations: basic buffers for untransformed overlays, VRFB-transformed buffers for OMAP3, and TILER-transformed buffers for OMAP4.
      * Ultimately all overlay memory is allocated as physically contiguous pages within a PMP - although since TILER contains its own MMU this isn't strictly necessary on OMAP4
      * Overlay memory is mapped as write-through cacheable for CPU access; experimentation with different cache policies has yet to be performed. However a potential future optimisation would be to perform lazy unmapping of overlay buffers, reducing the map/unmap overhead in well-behaved code which only maps buffers when they're needed
    Admin:
      Tested on BB-xM, Pandaboard
    
    
    Version 0.41. Tagged as 'OMAPVideo-0_41'
    e285399d
Makefile 2.25 KB