1. 17 6月, 2013 2 次提交
    • T
      OMAPDSS: remove dispc's dependency to VENC/HDMI · 5391e87d
      Tomi Valkeinen 提交于
      DISPC needs to know the clock rate for DIGIT (i.e. TV) channel, and this
      clock is provided by either VENC or HDMI modules. Currently DISPC will
      call a function in VENC/HDMI, asking what the clock rate is. This means
      we have a fixed dependency from DISPC to both VENC and HDMI.
      
      To have a more generic approach, and in particular to allow adding OMAP5
      HDMI driver, we need to remove this dependency. This patch makes
      VENC/HDMI inform DISPC when the their clock changes, thus reversing the
      dependency and removing the issue.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5391e87d
    • T
      OMAPDRM: fix overlay manager handling · 04b1fc02
      Tomi Valkeinen 提交于
      Currently omapdrm creates crtcs, which map directly to DSS overlay
      managers, only on demand at init time. This would make it difficult to
      manage connecting the display entities in the future, as the code cannot
      just search for a suitable overlay manager.
      
      We cannot fix this the sane way, which would be to create crtcs for each
      overlay manager, because we need an overlay for each crtc. With limited
      number of overlays, that's not possible.
      
      So the solution for now is to detach the overlay manager from the crtc.
      crtcs are still created on demand at init time, but all overlay managers
      are always initialized by the omapdss.
      
      This way we can create and connect whole display pipelines from the
      overlay manager to the display, regardless of which crtcs omapdrm would
      create.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      04b1fc02
  2. 10 4月, 2013 3 次提交
    • A
      OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5 · d0df9a2c
      Archit Taneja 提交于
      DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve
      more power savings when DISPC is configured in Smart Standby mode. This
      mechanism leads to underflows when multiple DISPC pipes are enabled.
      
      There is a register field which can let us revert to the older mechanism of
      asserting Mstandby. Configure this field to prevent underflows.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      d0df9a2c
    • A
      OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers · c35eeb2e
      Archit Taneja 提交于
      When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we
      need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This
      is needed because the stride for the UV plane(using a 16 bit Tiler container) is
      double the stride for the Y plane(using a 8 bit Tiler container) for the 0 or
      180 degree views. The ROW_INC register is meant for the Y plane, and the HW will
      calculate the row increment needed for the UV plane by using double the stride
      value based on whether this bit is set or not.
      
      Set the bit when we are using a 2D Tiler buffer and when rotation is 0 or 180
      degrees. The stride value is the same for 90 and 270 degree Tiler views, hence
      the bit shouldn't be set.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c35eeb2e
    • A
      omapdss: DISPC: add max pixel clock limits for LCD and TV managers · ca5ca69c
      Archit Taneja 提交于
      Each version of OMAP has a limitation on the maximum pixel clock frequency
      supported by an overlay manager. This limit isn't checked by omapdss. Add
      dispc feats for lcd and tv managers and check whether the target timings can
      be supported or not.
      
      The pixel clock limitations are actually more complex. They depend on which OPP
      OMAP is in, and they also depend on which encoder is the manager connected to.
      The OPP dependence is ignored as DSS forces the PM framework to be on OPP100
      when DSS is enabled, and the encoder dependencies are ignored by DISPC for now.
      These limits should come from the encoder driver.
      
      The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left
      as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ca5ca69c
  3. 03 4月, 2013 3 次提交
  4. 12 12月, 2012 2 次提交
    • T
      OMAPDSS: DISPC: remove dispc fck uses · 8105c94b
      Tomi Valkeinen 提交于
      The previous patch changes dispc to get the dispc fck rate from dss core
      driver. This was the only use of the dispc fck in dispc, and thus we can
      now remove the clock handling.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8105c94b
    • T
      OMAPDSS: DISPC: get dss clock rate from dss driver · 5aaee69d
      Tomi Valkeinen 提交于
      Dispc currently gets dispc's fck with clk_get() and uses clk_get_rate()
      to get the rate for scaling calculations. This causes a problem with
      common clock framework, as omapdss uses the dispc functions inside a
      spinlock, and common clock framework uses a mutex in clk_get_rate().
      
      Looking at the DSS clock tree, the above use of the dispc fck is not
      quite correct. The DSS_FCLK from PRCM goes to DSS core block, which has
      a mux to select the clock for DISPC from various options, so the current
      use of dispc fck bypasses that. Fortunately we never change the dispc
      clock mux for now.
      
      To fix the issue with clk_get_rate(), this patch caches the dss clock
      rate in dss.c when it is set. Dispc will then ask for the clock rate
      from dss. While this is not very elegant, it does fix the issue, and
      it's not totally wrong when considering that the dispc fck actually
      comes via dss.
      
      In the future we should probably look into common clock framework and
      see if that could be used to represent the DSS clock tree properly.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5aaee69d
  5. 07 12月, 2012 5 次提交
  6. 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
  7. 27 11月, 2012 10 次提交
  8. 20 11月, 2012 2 次提交
  9. 12 11月, 2012 3 次提交
    • A
      OMAPDSS: DISPC: Use output width and height to calculate row/pix inc for writeback · 6be0d73e
      Archit Taneja 提交于
      When calculating row and pixel increments for graphics and video pipes, we need
      to consider the dimensions of the input frame to know how to read from the
      buffer. Hence, we need to calculate these parameters from the input to the
      pipeline.
      
      For writeback, the row and pixel increments need to be calculated based on the
      output of the writeback pipeline, i.e, the dimensions of the frame after
      scaling. Ensure that dispc driver uses values of out_width and out_height when
      calling calc_dma/calc_tiler_rotation_offset.
      
      For graphics and video pipes, the original code passed the original height as
      frame_height to calc_dma_rotation_offset, and not the predecimated height. This
      is left as it is for now. We need to figure out why pre decimated height isn't
      needed.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      6be0d73e
    • A
      OMAPDSS: DISPC: Don't allow predecimation for writeback · 1c031441
      Archit Taneja 提交于
      Since writeback writes to a buffer instead of reading from one, predecimation
      doesn't make sense for it. Configure the width and height predecimation limits
      to 1 if the plane is writeback.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      1c031441
    • A
      OMAPDSS: DISPC: Fix calc_scaling_44xx() bugs for writeback pipeline · 5d501085
      Archit Taneja 提交于
      dispc_ovl_calc_scaling_44xx() doesn't work correctly for writeback. There are
      two issues with it:
      
      - the function tries to calculate pixel clock for the input plane using
        dispc_plane_pclk_rate(), calling this with writeback as input plane results in
        a BUG(), this function shouldn't be called for writeback at all. Fix this by
        calculating pixel clock only when we are not in mem to mem mode.
      
      - the maximum input_width is the product of the downscale ratio supported and
        the and the given output_width. This was calculated incorrectly by dividing
        output_width with maxdownscale. Fix this.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5d501085
  10. 07 11月, 2012 1 次提交
  11. 06 11月, 2012 1 次提交
  12. 05 11月, 2012 1 次提交
  13. 29 10月, 2012 6 次提交