1. 11 5月, 2012 3 次提交
  2. 09 5月, 2012 4 次提交
    • A
      OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() · 81ab95b7
      Archit Taneja 提交于
      The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
      function dispc_mgr_get_device() to get the omap_dss_device pointer to which
      the manager is connected, the width of the panel is derived from that.
      
      The manager's timing is stored in it's private data in APPLY. This contains
      the latest timings applied to the manager. Pass these timings to
      dispc_ovl_setup() and use them in the above functions. Remove the function
      dispc_mgr_get_device() as it isn't used any more.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      81ab95b7
    • A
      OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() · 3fa03ba8
      Archit Taneja 提交于
      The pixel clock rate for the TV manager is calculated by checking the device
      type connected to the manager, and then requesting the VENC/HDMI interface for
      the pixel clock rate.
      
      Remove the use of omap_dss_device pointer from here by checking which interface
      generates the pixel clock by reading the DSS_CTRL.VENC_HDMI_SWITCH bit.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      3fa03ba8
    • A
      OMAPDSS: MANAGER: Create a function to check manager timings · b917fa39
      Archit Taneja 提交于
      Create a function dss_mgr_check_timings() which wraps around the function
      dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
      from interface drivers.
      
      dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
      takes the timings maintained in the omap_dss_device struct. This would be later
      replaced by the timings stored in the manager's private data.
      
      Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
      omap_video_timings pointer since these functions just check the timings.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      b917fa39
    • A
      OMAPDSS: DISPC: Remove Fake VSYNC support · 408d9dbb
      Archit Taneja 提交于
      Fake VSYNC support is a hack and has some bugs in it. It isn't used by any user
      of DSS. Remove Fake VSYNC support. For DSI command mode and RFBI panels, a user
      of DSS should wait for the completion of a frame by using the panel driver's
      sync op.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      408d9dbb
  3. 03 5月, 2012 3 次提交
    • C
      OMAPDSS: DISPC: Correct DISPC functional clock usage · 8b53d991
      Chandrabhanu Mahapatra 提交于
      DISPC_FCLK is incorrectly used as functional clock of DISPC in scaling
      calculations. So, DISPC_CORE_CLK replaces as functional clock of DISPC.
      DISPC_CORE_CLK is derived from DISPC_FCLK divided by an independent DISPC
      divisor LCD.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8b53d991
    • C
      OMAPDSS: DISPC: Handle synclost errors in OMAP3 · 7faa9233
      Chandrabhanu Mahapatra 提交于
      In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
      and timing related limitations leading to SYNCLOST errors. Whenever the image
      window is moved towards the right of the screen SYNCLOST errors become
      frequent. Checks have been implemented to see that DISPC driver rejects
      configuration exceeding above limitations.
      
      This code was successfully tested on OMAP3. This code is written based on code
      written by Ville Syrjälä <ville.syrjala@nokia.com> in Linux OMAP kernel. Ville
      Syrjälä <ville.syrjala@nokia.com> had added checks for video overlay horizontal
      timing and DISPC horizontal blanking length limitations.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      7faa9233
    • C
      OMAPDSS: DISPC: Enable predecimation · aed74b55
      Chandrabhanu Mahapatra 提交于
      In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and
      up to 2 times in OMAP2. However, with predecimation, the image can be reduced
      to 16 times by fetching only the necessary pixels in memory. Then this
      predecimated image can be downscaled further by the DISPC scaler.
      
      The pipeline is configured to use a burst of size 8 * 128 bits which consists
      of 8 mini bursts of 16 bytes each. So, horizontal predecimation more than 16
      can lead to complete discarding of such mini bursts. L3 interconnect may
      handover the bus to some other initiator and inturn delay the fetching of
      pixels leading to underflows. So, maximum predecimation limit is fixed at 16.
      
      Based on the downscaling required, a prior calculation of predecimation values
      for width and height of an image is done. Since, Predecimation reduces quality
      of an image higher priorty is given to DISPC Scaler for downscaling.
      
      This code was successfully tested on OMAP2, OMAP3 and OMAP4. Horizontal and
      vertical predecimation worked fine except for some synclost errors due to
      undocumented errata in OMAP3 which are fixed later and skewed images were seen
      on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in
      the future patches.
      
      This code is based on code written by Lajos Molnar <lajos@ti.com> who had added
      predecimation support for NV12/YUV/rotated/SDMA buffers.
      Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      aed74b55
  4. 23 4月, 2012 3 次提交
  5. 06 3月, 2012 1 次提交
  6. 25 2月, 2012 1 次提交
    • T
      ARM: OMAP2+: Drop DISPC L3 firewall code · 1ca8c07b
      Tony Lindgren 提交于
      This is only needed when using SRAM for framebuffer,
      and the support for SRAM framebuffer is about to get
      removed.
      
      Otherwise we cannot move most of plat/io.h to be a local
      iomap.h for mach-omap2.
      
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: linux-fbdev@vger.kernel.org
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1ca8c07b
  7. 23 2月, 2012 1 次提交
  8. 21 2月, 2012 2 次提交
  9. 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
  10. 25 1月, 2012 5 次提交
  11. 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
  12. 02 12月, 2011 10 次提交
  13. 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
  14. 01 11月, 2011 1 次提交
  15. 03 10月, 2011 1 次提交
    • 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