1. 22 5月, 2012 2 次提交
    • T
      OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv · 36377357
      Tomi Valkeinen 提交于
      Commit 05dd0f53 ("OMAPDSS: DISPC: Update
      Accumulator configuration for chroma plane") adds
      dispc_ovl_set_accu_uv() function that sets the accu, but the function
      only handles YUV and NV12 modes, and BUGs otherwise.
      
      The patch also adds a call to the function, but unfortunately the place
      of call was such that the mode could be other than YUV or NV12, thus
      crashing the driver.
      
      This patchs moves the call to a slightly later spot, at which point only
      YUV and NV12 modes are handled.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>
      36377357
    • T
      OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays · 3568f2a4
      Tomi Valkeinen 提交于
      There is a problem related to DSS FIFO thresholds and power management
      on OMAP3. It seems that when the full PM hits in, we get underflows. The
      core reason is unknown, but after experiments it looks like only
      particular FIFO thresholds work correctly.
      
      This bug is related to an earlier patch, which added special FIFO
      threshold configuration for OMAP3, because DSI command mode output
      didn't work with the normal threshold configuration.
      
      However, as the above work-around worked fine for other output types
      also, we currently always configure thresholds in this special way on
      OMAP3. In theory there should be negligible difference with this special
      way and the standard way. The first paragraph explains what happens in
      practice.
      
      This patch changes the driver to use the special threshold configuration
      only when the output is a manual update display on OMAP3. This does
      include RFBI displays also, and although it hasn't been tested (no
      boards using RFBI) I suspect the similar behaviour is present there
      also, as the DISPC side should work similarly for DSI command mode and
      RFBI.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Joe Woodward <jw@terrafix.co.uk>
      3568f2a4
  2. 21 5月, 2012 1 次提交
    • A
      OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods · 6f28c296
      Archit Taneja 提交于
      DSI supports interleaving of command mode packets during the HSA, HFP, HBP and
      BLLP blanking intervals in a video mode stream. This is useful as a user may
      want to read or change the configuration of a panel without stopping the video
      stream.
      
      On OMAP DSI, we can queue HS or LP command mode packets in the TX FIFO, and
      the DSI HW takes care of interleaving this data during the one of the blanking
      intervals. The DSI HW needs to be programmed with the maximum amount of data
      that can be interleaved in a particular blanking period. A blanking period
      cannot be used to send command mode data for it's complete duration, there is
      some amount of time required for the DSI data and clock lanes to transition
      to the desired LP or HS state.
      
      Based on the state of the lanes at the beginning and end of the blanking period,
      we have different scenarios, with each scenario having a different value of time
      required to transition to HS or LP. Refer to the section 'Interleaving Mode' in
      OMAP TRM for more info on the scenarios and the equations to calculate the time
      required for HS or LP transitions.
      
      We use the scenarios which takes the maximum time for HS or LP transition, this
      gives us the minimum amount of time that can be used to interleave command mode
      data. The amount of data that can be sent during this minimum time is calculated
      for command mode packets both in LP and HS. These are written to the registers
      DSI_VM_TIMING4 to DSI_VM_TIMING6.
      
      The calculations don't take into account the time required of transmitting BTA
      when doing a DSI read, or verifying if a DSI write went through correctly. Until
      these latencies aren't considered, the behaviour of DSI is unpredictable when
      a BTA is interleaved during a blanking period. Enhancement of these calculations
      is a TODO item.
      
      The calculations are derived from DSI parameter calculation tools written by
      Sebastien Fagard <s-fagard@ti.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      6f28c296
  3. 15 5月, 2012 1 次提交
    • C
      OMAPDSS: DISPC: Update Accumulator configuration for chroma plane · 05dd0f53
      Chandrabhanu Mahapatra 提交于
      DISPC has two accumulator registers DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1 each
      with horizontal and vertical bit fields. The bit fields can take values in the
      range of -1024 to 1023. Based on bit field values DISPC decides on which one out
      of 8 phases the filtering starts. DISPC_VIDp_ACCU_0 is used for progressive
      output and for interlaced output both DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1
      are used.
      
      The current accumulator values in DISPC scaling logic for chroma plane takes
      default values for all color modes and rotation types. So, the horizontal and
      vertical up and downsampling accumulator bit field values have been updated for
      better performance.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      05dd0f53
  4. 11 5月, 2012 30 次提交
  5. 09 5月, 2012 6 次提交
    • A
      OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() · 81ab95b7
      Archit Taneja 提交于
      The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
      function dispc_mgr_get_device() to get the omap_dss_device pointer to which
      the manager is connected, the width of the panel is derived from that.
      
      The manager's timing is stored in it's private data in APPLY. This contains
      the latest timings applied to the manager. Pass these timings to
      dispc_ovl_setup() and use them in the above functions. Remove the function
      dispc_mgr_get_device() as it isn't used any more.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      81ab95b7
    • A
      OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() · 3fa03ba8
      Archit Taneja 提交于
      The pixel clock rate for the TV manager is calculated by checking the device
      type connected to the manager, and then requesting the VENC/HDMI interface for
      the pixel clock rate.
      
      Remove the use of omap_dss_device pointer from here by checking which interface
      generates the pixel clock by reading the DSS_CTRL.VENC_HDMI_SWITCH bit.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      3fa03ba8
    • A
      OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer · b3d795ab
      Archit Taneja 提交于
      The omap_dss_device pointer declared in dss_ovl_setup_fifo() isn't used. Remove
      the pointer variable declaration and it's assignment.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      b3d795ab
    • A
      OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled · fcc36619
      Archit Taneja 提交于
      The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
      set of timings. If the panel is disabled, they do not disable and re-enable
      the interface. Currently, the manager timings are applied in hdmi_power_on()
      and dpi_set_mode() respectively, these are not called by set_timings if the
      panel is disabled.
      
      When checking overlay and manager data, the DSS driver uses the last applied
      manager timings, and not the timings held by omap_dss_device struct. Hence,
      there is a need to apply the new manager timings even if the panel is disabled.
      
      Apply the manager timings if the panel is disabled. Eventually, there should be
      one common place where the timings are applied independent of the state of the
      panel.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      fcc36619
    • A
      OMAPDSS: APPLY: Remove display dependency from overlay and manager checks · 228b2134
      Archit Taneja 提交于
      In order to check the validity of overlay and manager info, there was a need to
      use the omap_dss_device struct to get the panel resolution. The manager's
      private data in APPLY now contains the manager timings. Hence, we don't need to
      rely on the display resolution any more.
      
      Pass the manager's timings in private data to dss_mgr_check(). Remove the need
      to pass omap_dss_device structs in the functions which check for the validity
      of overlay and manager parameters.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      228b2134
    • A
      OMAPDSS: APPLY: Don't check manager settings if it is disabled · 5dd747e8
      Archit Taneja 提交于
      If a manager is disabled, there is no guarantee at any point in time that all
      it's parameters are configured. There is always a chance that some more
      parameters are yet to be configured by a user of DSS, or by DSS itself.
      
      However, when the manager is enabled, we can be certain that all the parameters
      have been configured, as we can't enable a manager with an incomplete
      configuration. Therefore, if a manager is disabled, don't check for the validity
      of it's parameters or the parameters of the overlays connected to it. Only check
      once it is enabled. Add a check in dss_check_settings_low() to achieve the same.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      5dd747e8