1. 07 Dec, 2012 15 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: move irq handling to dispc-compat · 96e2e637
      Tomi Valkeinen authored
      The whole dispc irq handling system we currently have is only needed for
      compat layer, and thus can be moved from dispc.c to the compat layer.
      
      This is quite straigtforward, but we need to add new dispc functions to
      request and free the actual hardware irq: dispc_request_irq() and
      dispc_free_irq().
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      96e2e637
    • Tomi Valkeinen's avatar
      OMAPDSS: move omap_dispc_wait_for_irq_interruptible_timeout to dispc-compat.c · 549acbe7
      Tomi Valkeinen authored
      We have two functions to wait for a dispc interrupt:
      
      int omap_dispc_wait_for_irq_timeout(u32 irqmask, unsigned long timeout);
      int omap_dispc_wait_for_irq_interruptible_timeout(u32 irqmask,
      
      Of these, the former is not used at all, and can be removed. The latter
      is only used by the compat layer, and can be moved to the compat layer
      code.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      549acbe7
    • Tomi Valkeinen's avatar
      OMAPDSS: move blocking mgr enable/disable to compat layer · bb398134
      Tomi Valkeinen authored
      dispc_mgr_enable_sync and dispc_mgr_disable_sync are only used with the
      compat mode. Non-compat will use the simpler enable and disable
      functions.
      
      This patch moves the synchronous enable/disable code to the compat
      layer. A new file is created, dispc-compat.c, which contains low level
      dispc compat code (versus apply.c, which contains slightly higher level
      compat code).
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      bb398134
    • Tomi Valkeinen's avatar
      OMAPDSS: manage framedone irq with mgr ops · 1550202d
      Tomi Valkeinen authored
      Some of the output drivers need to handle FRAMEDONE interrupt from
      DISPC. This creates a direct dependency to dispc code, and we need to
      avoid this to make the compat code to work.
      
      Instead of the output drivers registering for dispc interrupts, we
      create new mgr-ops that are used to register a framedone handler. The
      code implementing the mgr-ops is responsible for calling the handler
      when DISPC FRAMEDONE interrupt happens. The compat layer is improved
      accordingly to do the call to the framedone handler.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      1550202d
    • Tomi Valkeinen's avatar
      OMAPDSS: add manager ops · 74b65ec2
      Tomi Valkeinen authored
      The output drivers need some operations from the overlay managers, like
      enable and set_timings. These will affect the dispc registers, and need
      to be synchronized with the composition-side changes with overlays and
      overlay managers.
      
      We want to handle these calls in the apply.c in the compatibility mode,
      but when in non-compat mode, the calls need to be handled by some other
      component (e.g. omapdrm).
      
      To make this possible, this patch creates a set of function pointers in
      a dss_mgr_ops struct, that is used to redirect the calls into the
      correct destination.
      
      The non-compat users can install their mgr ops with
      dss_install_mgr_ops() function.
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      74b65ec2
    • 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