1. 07 Dec, 2012 10 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: move ovl function setup to apply.c · 6abae7a1
      Tomi Valkeinen authored
      Most of the functions that are assigned to the fields in ovl struct are
      in apply.c. By moving the function pointer setup into apply.c we can
      make these functions static.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      6abae7a1
    • Tomi Valkeinen's avatar
      OMAPDSS: move ovl-mgr function setup to apply.c · 0c49ff74
      Tomi Valkeinen authored
      Most of the functions that are assigned to the fields in ovl-mgr struct
      are in apply.c. By moving the function pointer setup into apply.c we can
      make these functions static.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      0c49ff74
    • Tomi Valkeinen's avatar
      OMAPDSS: move ovl & ovl-mgr init to apply.c · 23dfd1ac
      Tomi Valkeinen authored
      Overlay and overlay_manager structs will only be needed in the compat
      mode.
      
      This patch moves initialization of overlay and overlay_manager structs
      to apply.c, so that they are handled in omapdss_compat_init().
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      23dfd1ac
    • Tomi Valkeinen's avatar
      OMAPDSS: add omapdss_compat_init() · 8dd2491a
      Tomi Valkeinen authored
      Add two new exported functions, omapdss_compat_init and
      omapdss_compat_uninit, which are to be used by omapfb, omap_vout to
      enable compatibility mode for omapdss. The functions are called by
      omapdss internally for now, and moved to other drivers later.
      
      The compatibility mode is implemented fully in the following patches.
      For now, enabling compat mode only sets up the private data in apply.c.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      8dd2491a
    • Tomi Valkeinen's avatar
      OMAPFB: connect ovl managers to all dssdevs · 6b6f1edf
      Tomi Valkeinen authored
      Commit 5d89bcc3 (OMAPDSS: remove initial
      display code from omapdss) moved setting up the initial overlay, overlay
      manager, output and display connections from omapdss to omapfb.
      
      However, currently omapfb only handles the connection related to the
      default display, which means that no overlay managers are connected to
      other displays.
      
      This patch changes omapfb to go through all dssdevs, and connect an
      overlay manager to them.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      6b6f1edf
    • Tomi Valkeinen's avatar
      OMAPDSS: manage output-dssdev connection in output drivers · 486c0e17
      Tomi Valkeinen authored
      We currently attach an output to a dssdev in the initialization code for
      dssdevices in display.c. This works, but doesn't quite make sense: an
      output entity represents (surprisingly) an output of DSS, which is
      managed by an output driver. The output driver also handles adding new
      dssdev's for that particular output.
      
      It makes more sense to make the output-dssdev connection in the output
      driver. This is also in line with common display framework.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      486c0e17
    • Tomi Valkeinen's avatar
      OMAPFB: remove warning when trying to alloc at certain paddress · 09a8c45c
      Tomi Valkeinen authored
      omapfb gives a WARN_ONCE if a predefined physical address is given for
      allocating the framebuffer memory, as this is not currently supported.
      
      However, the same warning happens if omapfb fails to allocate memory
      during runtime, as when the allocation has failed, omapfb tries to
      re-allocate the old memory with the physical address of the old memory
      area.
      
      Remove the warning from omapfb_alloc_fbmem, as it serves no purpose on
      the failure case above, and move it to omapfb_parse_vram_param, so that
      we only warn if physical address is given via omapfb module parameters.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      09a8c45c
    • Tomi Valkeinen's avatar
      OMAPFB: simplify locking · b41deecb
      Tomi Valkeinen authored
      Kernel lock verification code has lately detected possible circular
      locking in omapfb. The exact problem is unclear, but omapfb's current
      locking seems to be overly complex.
      
      This patch simplifies the locking in the following ways:
      
      - Remove explicit omapfb mem region locking. I couldn't figure out the
        need for this, as long as we take care to take omapfb lock.
      
      - Get omapfb lock always, even if the operation is possibly only related
        to one fb_info. Better safe than sorry, and normally there's only one
        user for the fb so this shouldn't matter.
      
      - Make sure fb_info lock is taken first, then omapfb lock.
      
      With this patch the warnings about possible circular locking does not
      happen anymore.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      b41deecb
    • Tomi Valkeinen's avatar
      OMAPFB: move dssdev->sync call out from omapfb_realloc_fbmem · 636f4e1b
      Tomi Valkeinen authored
      Currently omapfb_realloc_fbmem() calls dssdev->sync to ensure any
      possible frame update is finished. This patch moves the call to
      dssdev->sync from omapfb_realloc_fbmem to the callers of
      omapfb_realloc_fbmem.
      
      This keeps dssdev related calls out from omapfb_realloc_fbmem, which
      makes sense as the function should only deal with fb memory. Also, this
      seems to avoid a lockdep warning about possible circular locking.
      However, the exact reason for that warning is still unclear.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      636f4e1b
    • Tomi Valkeinen's avatar
      OMAPFB: remove exported udpate window · 09645d25
      Tomi Valkeinen authored
      omapfb contains an exported omapfb_update_window function, which, at
      some point in history, was used by a closed source SGX driver. This was
      a hack even then, and should not be needed anymore. So remove it.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      09645d25
  2. 30 Nov, 2012 1 commit
  3. 29 Nov, 2012 3 commits
  4. 27 Nov, 2012 15 commits
  5. 26 Nov, 2012 1 commit
  6. 23 Nov, 2012 1 commit
    • Tomi Valkeinen's avatar
      OMAPFB: fix compilation error · 9b76c9cd
      Tomi Valkeinen authored
      omapfb compilation fails on x86 (but not on omap):
      
      drivers/video/omap2/omapfb/omapfb-ioctl.c: In function ‘omapfb_ioctl’:
      drivers/video/omap2/omapfb/omapfb-ioctl.c:861:23: error: ‘SZ_1M’ undeclared (first use in this function)
      drivers/video/omap2/omapfb/omapfb-ioctl.c:861:23: note: each undeclared identifier is reported only once for each function it appears in
      
      Fix this by including linux/sizes.h.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      9b76c9cd
  7. 22 Nov, 2012 2 commits
  8. 20 Nov, 2012 2 commits
  9. 19 Nov, 2012 2 commits
  10. 16 Nov, 2012 3 commits