1. 21 2月, 2012 1 次提交
    • T
      OMAPDSS: cleanup probe functions · cd3b3449
      Tomi Valkeinen 提交于
      Now that dss is using devm_ functions for allocation in probe functions,
      small reordering of the allocations allows us to clean up the probe
      functions more.
      
      This patch moves "unmanaged" allocations after the managed ones, and
      uses plain returns instead of gotos where possible. This lets us remove
      a bunch of goto labels, simplifying the probe's error handling.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      cd3b3449
  2. 26 1月, 2012 1 次提交
    • T
      OMAPDSS: use sync versions of pm_runtime_put · 0eaf9f52
      Tomi Valkeinen 提交于
      omapdss doesn't work properly on system suspend. The problem seems to be
      the fact that omapdss uses pm_runtime_put() functions when turning off
      the hardware, and when system suspend is in process only sync versions
      are allowed.
      
      Using non-sync versions normally and sync versions when suspending would
      need rather ugly hacks to convey the information of
      suspending/not-suspending to different functions. Optimally the driver
      wouldn't even need to care about this, and the PM layer would handle
      syncing when suspend is in process.
      
      This patch changes all omapdss's pm_runtime_put calls to
      pm_runtime_put_sync. This fixes the suspend problem, and probably the
      performance penalty of always using sync versions is negligible.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NKevin Hilman <khilman@ti.com>
      0eaf9f52
  3. 25 1月, 2012 5 次提交
  4. 02 1月, 2012 3 次提交
    • C
      OMAPDSS: DISPC: Update Scaling Clock Logic · 7282f1b7
      Chandrabhanu Mahapatra 提交于
      Clock requirements for scaling in OMAP2, OMAP3 and OMAP4 are different. In
      OMAP2 and OMAP3 the required clock rate is a function of pixel clock, vertical
      downscale ratio and horizontal downscale ratio whereas in OMAP4 it is a
      function of pixel clock and horizontal downscale ratio only. Selection of 3-tap
      vs 5-tap coefficients depends on clock rate line buffer width in OMAP3 whereas
      in OMAP4 it is independent of clock rate and line buffer width. In OMAP2 3-tap
      for vertical and 5-tap for horizontal scaling is used. In OMAP4 5-tap is used
      both for horizontal and vertical scaling for better performance. Also, the
      number and width of line buffers differs in OMAP3 and OMAP4.
      
      So, clock functions have been fined tuned for OMAP3 and support has been added
      added for OMAP4. This code has been tested on OMAP2, OMAP3 and OMAP4, and
      scaling issues due to clock errors have been resolved.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      7282f1b7
    • C
      OMAPDSS: DISPC: Update Fir Coefficients · debd9074
      Chandrabhanu Mahapatra 提交于
      The FIR coefficients present in kernel are being updated to new coefficients
      consisting of 24 coefficient tables, with 12 each for 3 tap and 5 tap scenario,
      which are chosen on the basis of DISPC up/downsampling filters M value. M is
      the inverse of low pass cut off frequency of the sampling filter. For vertical
      scaling 3 tap or 5 tap tables are used based on the clock rate and width of
      the line buffer whereas in OMAP2 3 tap is always used. For horizontal scaling
      however 5 tap tables are always used.
      
      New coefficients and the corresponding logic have been tested on OMAP2, OMAP3
      and OMAP4. Horizontal and vertical scaling worked fine except for some 3 tap
      vs 5 tap issue during vertical upscaling and clock failing issues which is
      acknowledged in the next patch. Vertical upscaling was found to perform better
      under 5 taps. The 24 coefficient tables have been moved to another file
      dispc_coefs.c for proper maintainance.
      
      This code is written based on code written by Lajos Molnar <lajos@ti.com> in
      Android Kernel for scaling. Lajos Molnar <lajos@ti.com> had fine tuned the FIR
      coefficient selection process and reduced outliness and blockiness around
      images when upscaling more than 2 times.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      debd9074
    • R
      OMAPDSS: fix potential NULL pointer ref in OCP_ERR handling path · 00f17e45
      Rob Clark 提交于
      The dispc's error handler tries to disable all outputs when OCP_ERR
      happens. However, the code doesn't check if there actually is a display
      on each particular output, nor if there's a driver for the display. This
      may lead to NULL pointer reference.
      Signed-off-by: NRob Clark <rob@ti.com>
      [tomi.valkeinen@ti.com: added patch description]
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      00f17e45
  5. 02 12月, 2011 10 次提交
  6. 18 11月, 2011 1 次提交
    • T
      OMAPDSS: DISPC: skip scaling calculations when not scaling · f95cb5eb
      Tomi Valkeinen 提交于
      Current code calculates scaling factors for video overlays even when the
      overlays are not scaled. Change the code to skip calculations when not
      scaling.
      
      This optimizes the code a bit, but also fixes a problem when configuring
      an overlay for a disabled display: if the display is disabled we don't
      necessarily know the pixel clock used when the display is enabled, and
      in some cases (like HDMI) the pixel clock is set to zero until a proper
      video mode is set later. A wrong pixel clock will mess up the
      scaling calculations, causing an error like:
      
      omapdss DISPC error: failed to set up scaling, required fclk rate = 0
      Hz, current fclk rate = 170666666 Hz
      
      A proper fix would be to check later whether the clocks are enough for the
      scaling, at the point when the overlay or display is actually enabled,
      but this patch removes the problem for now.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f95cb5eb
  7. 01 11月, 2011 1 次提交
  8. 03 10月, 2011 3 次提交
    • A
      OMAPDSS: DISPC: zorder support for DSS overlays · 54128701
      Archit Taneja 提交于
      Add zorder support on OMAP4, this feature allows deciding the visibility order
      of the overlays based on the zorder value provided as an overlay info parameter
      or a sysfs attribute of the overlay object.
      
      Use the overlay cap OMAP_DSS_OVL_CAP_ZORDER to determine whether zorder is
      supported for the overlay or not. Use dss feature FEAT_ALPHA_FREE_ZORDER
      if the caps are not available.
      
      Ensure that all overlays that are enabled and connected to the same manager
      have different zorders. Swapping zorders of 2 enabled overlays currently
      requires disabling one of the overlays.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      54128701
    • A
      OMAPDSS: DISPC: VIDEO3 pipeline support · b8c095b4
      Archit Taneja 提交于
      Add support for VIDEO3 pipeline on OMAP4:
      - Add VIDEO3 pipeline information in dss_features and omapdss.h
      - Add VIDEO3 pipeline register coefficients in dispc.h
      - Create a new overlay structure corresponding to VIDEO3.
      - Make changes in dispc.c for VIDEO3
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      b8c095b4
    • A
      OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting · 11354dd5
      Archit Taneja 提交于
      On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
      to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
      OMAP4, alpha blending is always enabled by default, if the above bits are set,
      we switch to an OMAP3 compatibility mode where the zorder values in the pipeline
      attribute registers are ignored and a fixed priority is configured.
      
      Rename the manager_info member "alpha_enabled" to "partial_alpha_enabled" for
      more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
      FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and OMAP4
      alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2 user is
      expected to check for the ZORDER cap, if an overlay doesn't have this cap, the
      user is expected to set the parameter partial_alpha_enabled. If the overlay has
      ZORDER cap, the DSS2 user can assume that alpha blending is already enabled.
      
      Don't support OMAP3 compatibility mode for now. Trying to read/write to
      alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does not
      set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.
      
      Change alpha_enabled to partial_alpha_enabled in the omap_vout driver. Use
      overlay cap "OMAP_DSS_OVL_CAP_GLOBAL_ALPHA" to check if overlay supports alpha
      blending or not. Replace this with checks for VIDEO1 pipeline.
      
      Cc: linux-media@vger.kernel.org
      Cc: Lajos Molnar <molnar@ti.com>
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      11354dd5
  9. 30 9月, 2011 15 次提交