1. 02 11月, 2016 8 次提交
  2. 07 6月, 2016 2 次提交
    • J
      drm/omapdrm: Workaround for errata i734 (LCD1 Gamma) in DSS dispc · fbff010b
      Jyri Sarha 提交于
      Workaround for errata i734 in DSS dispc
       - LCD1 Gamma Correction Is Not Working When GFX Pipe Is Disabled
      
      For gamma tables to work on LCD1 the GFX plane has to be used at least
      once after DSS HW has come out of reset. The workaround sets up a
      minimal LCD setup with GFX plane and waits for one vertical sync irq
      before disabling the setup and continuing with the context
      restore. The physical outputs are gated during the operation.
      
      For details see:
      OMAP543x Multimedia Device Silicon Revision 2.0 Silicon Errata
      Literature Number: SWPZ037E
      Or some other relevant errata document for the DSS IP version.
      Signed-off-by: NJyri Sarha <jsarha@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      fbff010b
    • J
      drm/omapdrm: Add gamma table support to DSS dispc · acc3a231
      Jyri Sarha 提交于
      Add gamma table support to DSS dispc.
      
      DSS driver initializes the default gamma table at component bind time
      and holds a copy of all gamma tables in its internal data structure.
      
      Each call to dispc_mgr_set_gamma() updates the internal table and
      triggers write to the HW, if it is enabled. The tables are restored to
      HW in PM resume callback. The drivers internal data structure match
      the HW tables in size and in number of significant bits per color
      component. The dispc_mgr_set_gamma() converts the size of any given
      table for the internal data structure using linear interpolation.
      Default gamma table is restored if NULL is given in place of gamma
      lut.
      
      dispc_mgr_gamma_size() gives HW gamma table size for the channel and
      returns 0 if gamma table is not supported by the HW or the DSS driver.
      Signed-off-by: NJyri Sarha <jsarha@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      acc3a231
  3. 03 6月, 2016 1 次提交
  4. 20 5月, 2016 6 次提交
  5. 03 3月, 2016 5 次提交
  6. 29 12月, 2015 15 次提交
  7. 17 12月, 2015 1 次提交
    • T
      OMAPDSS: DISPC: always set ALIGN when available · e5f80917
      Tomi Valkeinen 提交于
      By default DISPC asserts hsync and vsync sequentially, i.e. there's
      first hsync and that is immediately followed by vsync. This is the only
      available behaviour on OMAP2/3, and default behaviour on OMAP4+.
      
      OMAP4+ has ALIGN bit in POL_FREQ register, which makes DISPC assert both
      syncs at the same time.
      
      It has been observed that some panels don't like sequential syncs (AM5
      EVM's panel). After studying the datasheets for multiple panels and
      encoders, and MIPI DPI spec, it looks like there is no standard way to
      handle this.
      
      Sometimes the datasheets don't mention the required syncs behaviour at
      all, sometimes the datasheets have images that hint towards simultaneous
      syncs, and sometimes it is explicitly mentioned that simultaneous syncs
      are needed. No panels or encoders requiring sequential sync was found.
      
      It thus seems to be safe to default to simultaneous syncs when the ALIGN
      bit is available. This fixed AM5 EVM's panel, and no side effects have
      been observed on other panels or encoders.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      e5f80917
  8. 17 6月, 2015 2 次提交
    • T
      OMAPDSS: DISPC: scaler debug print · e4c5ae7f
      Tomi Valkeinen 提交于
      Improve the DISPC debug print for scaling.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      e4c5ae7f
    • T
      OMAPDSS: DISPC: do only y decimation on OMAP3 · 7059e3d8
      Tomi Valkeinen 提交于
      The current driver does both x and y decimation on OMAP3 DSS. Testing
      shows that x decimation rarely works, leading to underflows.
      
      The exact reason for this is unclear, as the underflows seem to happen
      even with low pixel clock rates, and I would presume that if the DSS can
      manage a display with 140MHz pixel clock, it could manage x decimation
      with factor 2 with a low pixel clock (~30MHz).
      
      So it is possible that there is a problem somewhere else, in memory
      management, or DSS DMA, or similar. I have not found anything that would
      help this.
      
      So, to fix the downscaling scaling, this patch removes x decimation for
      OMAP3. This will limit some of the more demanding downscaling scenarios,
      but one could argue that using DSS to downscale such a large amount is
      insane in the first place, as the produced image is rather bad quality.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      7059e3d8