1. 23 4月, 2012 1 次提交
  2. 26 1月, 2012 1 次提交
    • T
      OMAPDSS: HDMI: PHY burnout fix · c49d005b
      Tomi Valkeinen 提交于
      A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
      if the HDMI PHY is kept powered on when the cable is not connected.
      
      This patch solves the problem by adding hot-plug-detection into the HDMI
      IP driver. This is not a real HPD support in the sense that nobody else
      than the IP driver gets to know about the HPD events, but is only meant
      to fix the HW bug.
      
      The strategy is simple: If the display device is turned off by the user,
      the PHY power is set to OFF. When the display device is turned on by the
      user, the PHY power is set either to LDOON or TXON, depending on whether
      the HDMI cable is connected.
      
      The reason to avoid PHY OFF when the display device is on, but the cable
      is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
      "ticking" and thus the DISPC does not receive pixel clock from the HDMI
      IP. This would, for example, prevent any VSYNCs from happening, and
      would thus affect the users of omapdss. By using LDOON when the cable is
      disconnected we'll avoid the HW bug, but keep the HDMI working as usual
      from the user's point of view.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c49d005b
  3. 05 1月, 2012 2 次提交
  4. 02 12月, 2011 13 次提交
    • T
      OMAPDSS: Add comments about blocking of ovl/mgr functions · 9d11c321
      Tomi Valkeinen 提交于
      Add comments specifying what ovl/mgr functions may block.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9d11c321
    • T
      OMAPDSS: APPLY: remove device_changed field · ff4733dc
      Tomi Valkeinen 提交于
      omap_overlay_manager contains device_changed field, which no longer has
      any use. So remove the field and the few places where it is touched.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ff4733dc
    • T
      OMAPDSS: APPLY: move channel-field to extra_info set · 5d5a97a6
      Tomi Valkeinen 提交于
      Setting overlay's output channel is currently handled at the same time
      as other overlay attributes. This is not right, as the normal attributes
      should only affect one overlay and manager, but changing the channel
      affects two managers.
      
      This patch moves the channel field into the "extra_info" set, handled
      together with enabled-status.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5d5a97a6
    • T
      OMAPDSS: APPLY: move ovl->info to apply.c · c1a9febf
      Tomi Valkeinen 提交于
      struct omap_overlayr contains info and info_dirty fields, both of which
      should be internal to apply.c.
      
      This patch moves those fields into ovl_priv data, and names them
      user_info and user_info_dirty.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c1a9febf
    • T
      OMAPDSS: APPLY: move mgr->info to apply.c · 388c4c6c
      Tomi Valkeinen 提交于
      struct omap_overlay_manager contains info and info_dirty fields, both of
      which should be internal to apply.c.
      
      This patch moves those fields into mgr_priv data, and names them
      user_info and user_info_dirty.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      388c4c6c
    • T
      OMAPDSS: APPLY: rewrite overlay enable/disable · aaa874a9
      Tomi Valkeinen 提交于
      Overlays are currently enabled and disabled with a boolean in the struct
      omap_overlay_info. The overlay info is set with ovl->set_overlay_info(),
      and made into use with mgr->apply().
      
      This doesn't work properly, as the enable/disable status may affect also
      other overlays, for example when using fifo-merge. Thus the enabling and
      disabling of the overlay needs to be done outside the normal overlay
      configuration.
      
      This patch achieves that by doing the following things:
      
      1) Add function pointers to struct omap_overlay: enable(), disable() and
      is_enabled(). These are used to do the obvious. The functions may block.
      
      2) Move the "enabled" field from struct omap_overlay to ovl_priv_data.
      
      3) Add a new route for settings to be applied to the HW, called
      "extra_info". The status of the normal info and extra_info are tracked
      separately.
      
      The point here is to allow the normal info to be changed and
      applied in non-blocking matter, whereas the extra_info can only be
      changed when holding the mutex. This makes it possible to, for example,
      set the overlay enable flag, apply it, and wait until the HW has taken
      the flag into use.
      
      This is not possible if the enable flag would be in the normal info, as
      a new value for the flag could be set at any time from the users of
      omapdss.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      aaa874a9
    • T
      OMAPDSS: APPLY: move mgr->enabled to mgr_priv_data · bf213523
      Tomi Valkeinen 提交于
      struct omap_overlay_manager contains "enabled"-field, used to track if
      the manager is enabled or not. This field should be internal to apply.c.
      
      This patch moves the field to mgr_priv_data, and applies the necessary
      locking when accessing the field.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bf213523
    • T
      OMAPDSS: DSI: call mgr_enable/disable for cmd mode displays · 9a147a65
      Tomi Valkeinen 提交于
      The current code uses dsi_video_mode_enable/disable functions to
      enable/disable DISPC output for video mode displays. For command mode
      displays we have no notion in the DISPC side of whether the panel is
      enabled, except when a dss_mgr_start_update() call is made.
      
      However, to properly maintain the DISPC state in apply.c, we need to
      know if a manager used for a manual update display is currently in use.
      
      This patch achieves that by changing dsi_video_mode_enable/disable to
      dsi_enable/disable_video_output, which is called by both video and
      command mode displays. For video mode displays it starts the actual
      pixel stream, as it did before. For command mode displays it doesn't do
      anything else than mark that the manager is currently in use.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9a147a65
    • T
      OMAPDSS: store overlays in a list for each manager · 07e327c9
      Tomi Valkeinen 提交于
      Current way of handling overlay-manager links is a bit strange: each
      manager has a static array, containing pointers to all the overlays
      (even those used by other managers). The overlays contain a pointer to
      the manager being used.
      
      This patch makes the system a bit saner: each manager has a linked list
      of overlays, and only the overlays linked to that manager are in the
      list.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      07e327c9
    • T
      OMAPDSS: store managers in an array · 5617ad09
      Tomi Valkeinen 提交于
      Overlay managers are stored in a linked list. There's no need for this
      list, as an array would do just as fine.
      
      This patch changes the code to use an array for overlay managers.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5617ad09
    • T
      OMAPDSS: APPLY: track whether a manager is enabled · be729178
      Tomi Valkeinen 提交于
      Add "enabled" field to struct omap_overlay_manager, which tells if the
      output is enabled or not. This will be used in apply.c in the following
      patches.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      be729178
    • T
      OMAPDSS: hide manager's enable/disable() · 7797c6da
      Tomi Valkeinen 提交于
      omap_overlay_manager struct contains enable() and disable() functions.
      However, these are only meant to be used from inside omapdss, and thus
      it's bad to expose the functions.
      
      This patch adds dss_mgr_enable() and dss_mgr_disable() functions to
      apply.c, which handle enabling and disabling the output.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      7797c6da
    • T
      OMAPDSS: remove partial update from DSI · 5476e74a
      Tomi Valkeinen 提交于
      Partial update for manual update displays has never worked quite well:
      * The HW has limitations on the update area, and the x and width need to
        be even.
      * Showing a part of a scaled overlay causes artifacts.
      * Makes the management of dispc very complex
      
      Considering the above points and the fact that partial update is not
      used anywhere, this and the following patches remove the partial update
      support. This will greatly simplify the following re-write of the apply
      mechanism to get proper locking and additional features like fifo-merge.
      
      This patch removes the partial update from the dsi.c.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5476e74a
  5. 08 11月, 2011 1 次提交
    • T
      ARM: OMAP: HWMOD: Unify DSS resets for OMAPs · 13662dc5
      Tomi Valkeinen 提交于
      This patch adds a custom DSS reset function used on OMAPs from OMAP2
      forward.
      
      The function doesn't actually do a reset, it only waits for the reset to
      complete. The reason for this is that on OMAP4 there is no possibility
      to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets
      all the other DSS modules also, thus breaking the HWMOD model where
      every DSS module is handled independently.
      
      This fixes the problem with DSS reset on OMAP4, caused by the fact that
      because there's no SW reset for dss_core on OMAP4, the HWMOD framework
      doesn't try to reset dss_core and thus the DSS clocks were never enabled
      at the same time. This causes causes the HWMOD reset to fail for
      dss_dispc and dss_rfbi.
      
      The common reset function will also allow us to fix another problem in
      the future: before doing a reset we need to disable DSS outputs, which
      are in some cases enabled by the bootloader, as otherwise DSS HW seems
      to get more or less stuck, requiring a power reset to recover.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      [paul@pwsan.com: modified to build arch/arm/mach-omap2/display.o
       unconditionally to avoid an error when !CONFIG_OMAP2_DSS]
      Signed-off-by: NPaul Walmsley <paul@pwsan.com>
      13662dc5
  6. 03 10月, 2011 3 次提交
    • A
      OMAPDSS: DISPC: zorder support for DSS overlays · 54128701
      Archit Taneja 提交于
      Add zorder support on OMAP4, this feature allows deciding the visibility order
      of the overlays based on the zorder value provided as an overlay info parameter
      or a sysfs attribute of the overlay object.
      
      Use the overlay cap OMAP_DSS_OVL_CAP_ZORDER to determine whether zorder is
      supported for the overlay or not. Use dss feature FEAT_ALPHA_FREE_ZORDER
      if the caps are not available.
      
      Ensure that all overlays that are enabled and connected to the same manager
      have different zorders. Swapping zorders of 2 enabled overlays currently
      requires disabling one of the overlays.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      54128701
    • A
      OMAPDSS: DISPC: VIDEO3 pipeline support · b8c095b4
      Archit Taneja 提交于
      Add support for VIDEO3 pipeline on OMAP4:
      - Add VIDEO3 pipeline information in dss_features and omapdss.h
      - Add VIDEO3 pipeline register coefficients in dispc.h
      - Create a new overlay structure corresponding to VIDEO3.
      - Make changes in dispc.c for VIDEO3
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      b8c095b4
    • A
      OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting · 11354dd5
      Archit Taneja 提交于
      On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
      to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
      OMAP4, alpha blending is always enabled by default, if the above bits are set,
      we switch to an OMAP3 compatibility mode where the zorder values in the pipeline
      attribute registers are ignored and a fixed priority is configured.
      
      Rename the manager_info member "alpha_enabled" to "partial_alpha_enabled" for
      more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
      FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and OMAP4
      alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2 user is
      expected to check for the ZORDER cap, if an overlay doesn't have this cap, the
      user is expected to set the parameter partial_alpha_enabled. If the overlay has
      ZORDER cap, the DSS2 user can assume that alpha blending is already enabled.
      
      Don't support OMAP3 compatibility mode for now. Trying to read/write to
      alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does not
      set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.
      
      Change alpha_enabled to partial_alpha_enabled in the omap_vout driver. Use
      overlay cap "OMAP_DSS_OVL_CAP_GLOBAL_ALPHA" to check if overlay supports alpha
      blending or not. Replace this with checks for VIDEO1 pipeline.
      
      Cc: linux-media@vger.kernel.org
      Cc: Lajos Molnar <molnar@ti.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      11354dd5
  7. 30 9月, 2011 16 次提交
  8. 25 7月, 2011 2 次提交
  9. 01 7月, 2011 1 次提交