1. 07 6月, 2016 1 次提交
    • 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
  2. 03 6月, 2016 1 次提交
  3. 20 5月, 2016 6 次提交
  4. 03 3月, 2016 5 次提交
  5. 29 12月, 2015 15 次提交
  6. 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
  7. 17 6月, 2015 11 次提交
    • 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
    • T
      OMAPDSS: DISPC: check if scaling setup failed · 3ce17b48
      Tomi Valkeinen 提交于
      The DISPC's scaling code seems to presume that decimation always
      succeeds, and so we always do find a suitable downscaling setup.
      However, this is not the case, and the algorithm can fail.
      
      When that happens, the code just proceeds with wrong results, causing
      issues later.
      
      Add the necessary checks to bail out if the scaling algorithm failed.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      3ce17b48
    • T
      OMAPDSS: DISPC: fix 64 bit issue in 5-tap · c582935c
      Tomi Valkeinen 提交于
      The DISPC driver uses 64 bit arithmetic to calculate the required clock
      rate for scaling. The code does not seem to work correctly, and instead
      calculates with 32 bit numbers, giving wrong result.
      
      Fix the code by typecasting values to u64 first, so that the
      calculations do happen in 64 bits.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c582935c
    • T
      OMAPDSS: DISPC: fix row_inc for OMAP3 · f2aee319
      Tomi Valkeinen 提交于
      pixel_inc and row_inc work differently on OMAP2/3 and OMAP4+ DSS. On
      OMAP2/3 DSS, the pixel_inc is _not_ added by the HW at the end of the
      line, after the last pixel, whereas on OMAP4+ it is.
      
      The driver currently works for OMAP4+, but does not handle OMAP2/3
      correctly, which leads to tilted image when row_inc is used.
      
      This patch adds a flag to DISPC driver so that the pixel_inc is added
      when required.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f2aee319
    • T
      OMAPDSS: DISPC: add check for scaling limits · ab6b2582
      Tomi Valkeinen 提交于
      On OMAP3/AM43xx some scaling factors cause underflows/synclosts. After
      studying this, I found that sometimes the driver uses three-tap scaling
      with downscaling factor smaller than x0.5. This causes issues, as x0.5
      is the limit for three-tap scaling.
      
      The driver has FEAT_PARAM_DOWNSCALE parameter, but that seems to be for
      five-tap scaling, which allows scaling down to x0.25.
      
      This patch adds checks for both horizontal and vertical scaling. For
      horizontal the HW always uses 5 taps, so the limit is x0.25.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ab6b2582
    • T
      OMAPDSS: DISPC: fix check_horiz_timing_omap3 args · f5a73482
      Tomi Valkeinen 提交于
      After calculating the required decimation for scaling, the dispc driver
      checks once more if the resulting configuration is valid by calling
      check_horiz_timing_omap3().
      
      Earlier calls to this function have correctly used in_width and
      in_height as parameters, but the last call uses width and height. This
      causes the driver to possibly reject scaling that would work.
      
      This patch fixes the parameters.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f5a73482
    • T
      OMAPDSS: DISPC: fix predecimation for YUV modes · c4661b33
      Tomi Valkeinen 提交于
      DISPC needs even input buffer width for YUV modes. The DISPC driver
      doesn't check this at the moment (although omapdrm does), but worse,
      when DISPC driver does x predecimation the result may be uneven. This
      causes sometimes sync losts, underflows, or just visual errors.
      
      This patch makes DISPC driver return an error if the user gives uneven
      input width for a YUV buffer. It also makes the input width even in case
      of predecimation.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c4661b33
    • T
      OMAPDSS: DISPC: work-around for errata i631 · 3397cc6a
      Tomi Valkeinen 提交于
      Errata i631 description:
      
      "When in YUV4:2:0 format in 1D burst, the DISPC DMA skips lines when
      fetching Chroma sampling."
      
      Workaround:
      
      "If YUV4:2:0-1D burst is required: Set
      DISPC_VIDp_ATTRIBUTES[22]DOUBLESTRIDE to 0x0 and
      DISPC_VIDp_ATTRIBUTES[13:12]ROTATION to 0x1 or 0x3"
      
      The description is somewhat confusing, but testing has shown that DSS
      fetches extra rows from memory when using NV12 format in 1D mode. If the
      memory after the framebuffer is inaccessible, this leads to OCP errors.
      
      The driver always uses DOUBLESTRIDE=0 when using 1D mode, so we only
      need to handle the ROTATION part.
      
      The issue exist on all OMAP4 and OMAP5 based DSS IPs.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      3397cc6a
    • T
      OMAPDSS: componentize omapdss · 736e60dd
      Tomi Valkeinen 提交于
      omapdss kernel module contains drivers for multiple devices, one for
      each DSS submodule. The probing we have at the moment is a mess, and
      doesn't give us proper deferred probing nor ensure that all the devices
      are probed before omapfb/omapdrm start using omapdss.
      
      This patch solves the mess by using the component system for DSS
      submodules.
      
      The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi,
      venc) are the same: probe & remove functions are changed to bind &
      unbind, and new probe & remove functions are added which call
      component_add/del.
      
      The dss_core driver (dss.c) acts as a component master. Adding and
      matching the components is simple: all dss device's child devices are
      added as components.
      
      However, we do have some dependencies between the drivers. The order in
      which they should be probed is reflected by the list in core.c
      (dss_output_drv_reg_funcs). The drivers are registered in that order,
      which causes the components to be added in that order, which makes the
      components to be bound in that order. This feels a bit fragile, and we
      probably should improve the code to manage binds in random order.
      However, for now, this works fine.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      736e60dd
    • T
      OMAPDSS: remove uses of __init/__exit · ede92695
      Tomi Valkeinen 提交于
      The following patches will add component handling to omapdss, improving
      the handling of deferred probing. However, at the moment we're using
      quite a lot of __inits and __exits in the driver, which prevent normal
      dynamic probing and removal.
      
      This patch removes most of the uses of __init and __exit, so that we can
      register drivers after module init, and so that we can unregister
      drivers even if the module is built-in.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      ede92695