1. 09 5月, 2012 12 次提交
    • 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: APPLY: Remove an unnecessary omap_dss_device pointer · b3d795ab
      Archit Taneja 提交于
      The omap_dss_device pointer declared in dss_ovl_setup_fifo() isn't used. Remove
      the pointer variable declaration and it's assignment.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      b3d795ab
    • A
      OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled · fcc36619
      Archit Taneja 提交于
      The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
      set of timings. If the panel is disabled, they do not disable and re-enable
      the interface. Currently, the manager timings are applied in hdmi_power_on()
      and dpi_set_mode() respectively, these are not called by set_timings if the
      panel is disabled.
      
      When checking overlay and manager data, the DSS driver uses the last applied
      manager timings, and not the timings held by omap_dss_device struct. Hence,
      there is a need to apply the new manager timings even if the panel is disabled.
      
      Apply the manager timings if the panel is disabled. Eventually, there should be
      one common place where the timings are applied independent of the state of the
      panel.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      fcc36619
    • A
      OMAPDSS: APPLY: Remove display dependency from overlay and manager checks · 228b2134
      Archit Taneja 提交于
      In order to check the validity of overlay and manager info, there was a need to
      use the omap_dss_device struct to get the panel resolution. The manager's
      private data in APPLY now contains the manager timings. Hence, we don't need to
      rely on the display resolution any more.
      
      Pass the manager's timings in private data to dss_mgr_check(). Remove the need
      to pass omap_dss_device structs in the functions which check for the validity
      of overlay and manager parameters.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      228b2134
    • A
      OMAPDSS: APPLY: Don't check manager settings if it is disabled · 5dd747e8
      Archit Taneja 提交于
      If a manager is disabled, there is no guarantee at any point in time that all
      it's parameters are configured. There is always a chance that some more
      parameters are yet to be configured by a user of DSS, or by DSS itself.
      
      However, when the manager is enabled, we can be certain that all the parameters
      have been configured, as we can't enable a manager with an incomplete
      configuration. Therefore, if a manager is disabled, don't check for the validity
      of it's parameters or the parameters of the overlays connected to it. Only check
      once it is enabled. Add a check in dss_check_settings_low() to achieve the same.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      5dd747e8
    • 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: Apply manager timings instead of direct DISPC writes · 41721163
      Archit Taneja 提交于
      Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
      interface drivers. The latter function ensures that the timing related DISPC
      registers are configured according to the shadow register programming model.
      
      Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit
      is set by dss_mgr_set_timings().
      Signed-off-by: NArchit Taneja <archit@ti.com>
      41721163
    • A
      OMAPDSS: APPLY: Add manager timings as extra_info in private data · 45324a26
      Archit Taneja 提交于
      DISPC manager size and DISPC manager blanking parameters(for LCD managers)
      follow the shadow register programming model. Currently, they are programmed
      directly by the interface drivers.
      
      To configure manager timings using APPLY, there is a need to introduce extra
      info flags for managers, similar to what is done for overlays. This is needed
      because timings aren't a part of overlay_manager_info struct configured by a
      user of DSS, they are configured internally by the interface or panel drivers.
      
      Add dirty and shadow_dirty extra_info flags for managers, update these flags
      at the appropriate places. Rewrite the function extra_info_update_ongoing()
      slightly as checking for manager's extra_info flags can simplify the code a bit.
      
      Create function dss_mgr_set_timings() which applies the new manager timings to
      extra_info.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      45324a26
    • 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
    • A
      OMAPDSS: Fix DSI_FCLK clock source selection · a2e5d827
      Archit Taneja 提交于
      The wrong bit field was being updated in DSS_CTRL when trying to configure the
      clock source of DSI2 functional clock. Use the correct bit field based on the
      dsi module number.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a2e5d827
    • A
      OMAPDSS: HDMI: define and dump CORE registers in correct order · 9b9c457b
      Archit Taneja 提交于
      The HDMI core register offset macros aren't defined in ascending order of their
      values, some of the offset macros are also redefined. The same issues occur when
      these core registers are dumped.
      
      Clean up the ordering of HDMI core registers and remove repeated registers in
      the definition in ti_hdmi_4xxx_ip.h and in ti_hdmi_4xxx_core_dump().
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9b9c457b
    • A
      OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump · 3c7de247
      Archit Taneja 提交于
      The function ti_hdmi_4xxx_core_dump has some bugs, the following mention the
      bugs and the solutions:
      
      - The macros DUMPCORE and DUMPCOREAV in ti_hdmi_4xxx_core_dump() use
        hdmi_pll_base() for the offsets needed to calculate register addresses, use
        functions hdmi_core_sys_base() amd hdmi_av_base() to calculate the correct
        offsets for CORE_SYS and CORE_AV registers.
      
      - Many of the CORE_AV registers use the DUMPCORE macro, and hence the register
        addresses are calculated incorrectly. Rename the current DUMPCOREAV macro as
        DUMPCOREAV2 as it takes 2 arguments to dump indexed CORE_AV registers, create
        a new macro called DUMPCOREAV which is now used for dumping non-indexed
        CORE_AV registers.
      
      Thanks to Ancy Tom <ancytom@gmail.com> for pointing out the issues.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      3c7de247
  2. 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
  3. 23 4月, 2012 7 次提交
  4. 21 3月, 2012 1 次提交
    • T
      OMAPDSS: register dss drivers in module init · dc7e57fa
      Tomi Valkeinen 提交于
      We do the dss driver registration in a rather strange way: we have the
      higher level omapdss driver, and we use that driver's probe function to
      register the drivers for the rest of the dss devices.
      
      There doesn't seem to be any reason for that, and additionally the
      soon-to-be-merged patch "ARM: OMAP: omap_device: remove
      omap_device_parent" will break omapdss initialization with the current
      registration model.
      
      This patch changes the registration for all drivers to happen at the
      same place, in the init of the module.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      dc7e57fa
  5. 13 3月, 2012 1 次提交
  6. 06 3月, 2012 5 次提交
  7. 01 3月, 2012 1 次提交
    • T
      OMAPDSS: APPLY: make ovl_enable/disable synchronous · a3d0e4ae
      Tomi Valkeinen 提交于
      ovl->enable/disable are meant to be synchronous so that they can handle
      the configuration of fifo sizes. The current kernel doesn't configure
      fifo sizes yet, and so the code doesn't need to block to function (from
      omapdss driver's perspective).
      
      However, for the users of omapdss a non-blocking ovl->disable is
      confusing, because they don't know when the memory area is not used
      any more.
      
      Furthermore, when the fifo size configuration is added in the next merge
      window, the change from non-blocking to blocking could cause side
      effects to the users of omapdss. So by making the functions block
      already will keep them behaving in the same manner.
      
      And, while not the main purpose of this patch, this will also remove the
      compile warning:
      
      drivers/video/omap2/dss/apply.c:350: warning:
      'wait_pending_extra_info_updates' defined but not used
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      a3d0e4ae
  8. 25 2月, 2012 2 次提交
  9. 23 2月, 2012 3 次提交
    • R
      OMAPDSS: HDMI: hot plug detect fix · ca888a79
      Rob Clark 提交于
      The "OMAPDSS: HDMI: PHY burnout fix" commit switched the HDMI driver
      over to using a GPIO for plug detect.  Unfortunately the ->detect()
      method was not also updated, causing HDMI to no longer work for the
      omapdrm driver (because it would actually check if a connection was
      detected before attempting to enable display).
      Signed-off-by: NRob Clark <rob@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ca888a79
    • A
      OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled · a247ce78
      Archit Taneja 提交于
      For DSS clock domain to transition from idle to active state. It's necessary
      to enable the optional clock DSS_FCLK before we enable the module using the
      MODULEMODE bits in the clock domain's CM_DSS_DSS_CLKCTRL register.
      
      This sequence was not followed correctly for the 'dss_hdmi' hwmod and it led
      to DSS clock domain not getting out of idle when pm_runtime_get_sync() was
      called for hdmi's platform device.
      
      Since the clock domain failed to change it's state to active, the hwmod code
      disables any clocks it had enabled before for this hwmod. This led to the clock
      'dss_48mhz_clk' gettind disabled.
      
      When hdmi's runtime_resume() op is called, the call to dss_runtime_get()
      correctly enables the DSS clock domain this time. However, the clock
      'dss_48mhz_clk' is needed for HDMI's PHY to function correctly. Since it was
      disabled previously, the driver fails when it tries to enable HDMI's PHY.
      
      Fix this for now by ensuring that dss_runtime_get() is called before we call
      pm_runtime_get_sync() for hdmi's platform device. A correct fix for later would
      be to modify the DSS related hwmod's mainclks, and also some changes in how
      opt clocks are handled in the DSS driver.
      
      This fixes the issue of HDMI not working when it's the default display. The
      issue is not seen if any other display is already enabled as the first display
      would have correctly enabled the DSS clockdomain.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a247ce78
    • T
      OMAPDSS: Remove video SRAM support · 2a803c88
      Tomi Valkeinen 提交于
      OMAP SRAM can be used as video memory on OMAP1 and 2. However, there
      usually is very little SRAM available, thus limiting its use, and no
      board supported by the kernel currently uses it.
      
      This patch removes the use of SRAM as video ram for the omapdss driver
      to simplify memory handling.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      2a803c88
  10. 21 2月, 2012 5 次提交