1. 07 12月, 2012 11 次提交
    • T
      OMAPDSS: add manager ops · 74b65ec2
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      74b65ec2
    • T
      OMAPDSS: move ovl function setup to apply.c · 6abae7a1
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      6abae7a1
    • T
      OMAPDSS: move ovl-mgr function setup to apply.c · 0c49ff74
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      0c49ff74
    • T
      OMAPDSS: move ovl & ovl-mgr init to apply.c · 23dfd1ac
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      23dfd1ac
    • T
      OMAPDSS: add omapdss_compat_init() · 8dd2491a
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8dd2491a
    • T
      OMAPFB: connect ovl managers to all dssdevs · 6b6f1edf
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      6b6f1edf
    • T
      OMAPDSS: manage output-dssdev connection in output drivers · 486c0e17
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      486c0e17
    • T
      OMAPFB: remove warning when trying to alloc at certain paddress · 09a8c45c
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      09a8c45c
    • T
      OMAPFB: simplify locking · b41deecb
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      b41deecb
    • T
      OMAPFB: move dssdev->sync call out from omapfb_realloc_fbmem · 636f4e1b
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      636f4e1b
    • T
      OMAPFB: remove exported udpate window · 09645d25
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      09645d25
  2. 30 11月, 2012 3 次提交
  3. 29 11月, 2012 1 次提交
    • A
      OMAPDSS: Use only "omapdss_dss" platform device to get context lost count · bdb736ab
      Archit Taneja 提交于
      When enabling a hwmod, omap_hwmod refers to the register mentioned in the
      hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
      lost or not. It increments the context lost count for the hwmod and then clears
      the register.
      
      All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs.
      When DSS is enabled, the first hwmod to be enabled is the "dss_core" hwmod since
      it's corresponding platform device is the parent platform device("omapdss_dss").
      The dss_core hwmod updates it's context lost count correctly and clears the
      register. When the hwmods corresponding to the children platform devices are
      enabled, they see that the register is clear, and don't increment their context
      lost count. Therefore, all the children platform devices never report a loss in
      context.
      
      The DISPC driver currently gets the context lost count for DSS power domain from
      it's corresponding platform device instance("omapdss_dispc"). The DISPC platform
      device is one of the child devices, and it's corresponding hwmod("dss_dispc")
      doesn't report the context lost count correctly.
      
      Modify dss_get_ctx_loss_count() such that it always takes the "omapdss_dss"
      platform device as it's input, move the function to dss.c so that it has access
      to that platform device.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bdb736ab
  4. 27 11月, 2012 15 次提交
  5. 26 11月, 2012 1 次提交
  6. 23 11月, 2012 1 次提交
    • T
      OMAPFB: fix compilation error · 9b76c9cd
      Tomi Valkeinen 提交于
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9b76c9cd
  7. 22 11月, 2012 2 次提交
  8. 20 11月, 2012 2 次提交
  9. 19 11月, 2012 2 次提交
  10. 16 11月, 2012 2 次提交