1. 11 2月, 2014 1 次提交
    • T
      OMAPDSS: DISPC: decimation rounding fix · eec77da2
      Tomi Valkeinen 提交于
      The driver uses DIV_ROUND_UP when calculating decimated width & height.
      For example, when decimating with 3, the width is calculated as:
      
        width = DIV_ROUND_UP(width, decim_x);
      
      This yields bad results for some values. For example, 800/3=266.666...,
      which is rounded to 267. When the input width is set to 267, and pixel
      increment is set to 3, this causes the dispc to read a line of 801
      pixels, i.e. it reads a wrong pixel at the end of the line.
      
      Even more pressing, the above rounding causes a BUG() in pixinc(), as
      the value of 801 is used to calculate row increment, leading to a bad
      value being passed to pixinc().
      
      This patch fixes the decimation by removing the DIV_ROUND_UP()s when
      calculating width and height for decimation.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      eec77da2
  2. 14 1月, 2014 1 次提交
    • I
      OMAPDSS: DISPC: Fix 34xx overlay scaling calculation · e4998634
      Ivaylo Dimitrov 提交于
      commit 7faa9233 OMAPDSS: DISPC: Handle
      synclost errors in OMAP3 introduces limits check to prevent SYNCLOST errors
      on OMAP3. However, it misses the logic found in Nokia kernels that is
      needed to correctly calculate whether 3 tap or 5 tap rescaler to be used as
      well as the logic to fallback to 3 taps if 5 taps clock results in too
      tight horizontal timings. Without that patch "horizontal timing too tight"
      errors are seen when a video with resolution above 640x350 is tried to be
      played. The patch is a forward-ported logic found in Nokia N900 and N9/50
      kernels.
      Signed-off-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      e4998634
  3. 13 1月, 2014 2 次提交
    • A
      OMAPDSS: DISPC: Preload more data in pipeline DMAs for OMAP4+ SoCs · 8bc65552
      Archit Taneja 提交于
      DISPC pipeline DMAs preload some bytes of pixel data in the vertical blanking
      region before the start of each frame. The preload ensures the pipeline doesn't
      underflow when the active region of the display starts.
      
      DISPC_GFX/VIDp_PRELOAD registers allow us to program how many bytes of data
      should be preloaded for each pipeline. Calculating a precise preload value
      would be a complex function of the pixel clock of the connected display, the
      vertical blanking duration and the interconnect traffic at that instance. If
      the register is left untouched, a default value is preloaded.
      
      We observe underflows for OMAP4+ SoCs for certain bandwidth intensive use cases
      with many other initiators active, and in situations where memory access isn't
      very efficient(like accessing Tiler mapped buffers and EMIF configured in
      non-interleaved more). The cause of the underflow is because the default preload
      value isn't sufficient for the DMA to reach a steady state. We configure the
      PRELOAD register such that the pipelines preload data up to the high threshold
      of the FIFO.
      
      Preloading lot of data for older SoCs can have a negative impact. Due to slower
      interconnects, it's possible that the DISPC DMA cannot preload up to the high
      threshold within the vertical blanking region of the panel. We leave the PRELOAD
      registers to their reset values since we haven't faced underflows with these
      SoCs because of low value of PRELOAD.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8bc65552
    • T
      OMAPDSS: DISPC: fix context restore · be07dcd7
      Tomi Valkeinen 提交于
      DISPC_MSTANDBY_CTRL register is used in the driver, but it's not
      restored in dispc_restore_context(), causing problems after resume.
      
      Instead of adding DISPC_MSTANDBY_CTRL to dispc_restore_context(), let's
      call _omap_dispc_initial_config() as the first thing in
      dispc_runtime_resume(). This will initialize the DISPC core registers
      properly, and will avoid similar issues in the future.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      be07dcd7
  4. 09 1月, 2014 1 次提交
    • T
      drm/omap: fix (un)registering irqs inside an irq handler · 6da9f891
      Tomi Valkeinen 提交于
      omapdrm (un)registers irqs inside an irq handler. The problem is that
      the (un)register function uses dispc_runtime_get/put() to enable the
      clocks, and those functions are not irq safe by default.
      
      This was kind of fixed in 48664b21
      (OMAPDSS: DISPC: set irq_safe for runtime PM), which makes dispc's
      runtime calls irq-safe.
      
      However, using pm_runtime_irq_safe in dispc makes the parent of dispc,
      dss, always enabled, effectively preventing PM for the whole DSS module.
      
      This patch makes omapdrm behave better by adding new irq (un)register
      functions that do not use dispc_runtime_get/put, and using those
      functions in interrupt context. Thus we can make dispc again
      non-irq-safe, allowing proper PM.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Rob Clark <robdclark@gmail.com>
      6da9f891
  5. 30 12月, 2013 2 次提交
  6. 30 10月, 2013 1 次提交
  7. 23 9月, 2013 1 次提交
  8. 19 9月, 2013 1 次提交
    • T
      OMAPDSS: DISPC: set irq_safe for runtime PM · 48664b21
      Tomi Valkeinen 提交于
      We have a bug with omapdrm, where omapdrm calls dispc's pm_runtime
      function in atomic context, and dispc's pm_runtime is not marked as
      irq_safe:
      
      BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:952
      
      Dispc's runtime PM callbacks are irq safe, so we can just set the
      irq_safe flag to fix the issue.
      
      However, in the long term, I'd rather have omapdrm manage the runtime PM
      calls in a better way. Calling get/put for every small operation that
      touches the dispc registers is very inefficient. It'd be better and
      cleaner to have clear "in-use" and "not-in-use" states for dispc, so
      that we don't need to do register context restore for small operations,
      only to turn dispc off right afterwards.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      48664b21
  9. 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
  10. 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
  11. 03 4月, 2013 3 次提交
  12. 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
  13. 07 12月, 2012 5 次提交
  14. 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
  15. 27 11月, 2012 10 次提交
  16. 20 11月, 2012 2 次提交
  17. 12 11月, 2012 2 次提交