1. 11 May, 2012 11 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: create DPI & SDI drivers · a57dd4fe
      Tomi Valkeinen authored
      
      
      We currently have separate device/driver for each DSS HW module. The DPI
      and SDI outputs are more or less parts of the DSS or DISPC hardware
      modules, but in SW it makes sense to represent them as device/driver
      pairs similarly to all the other outputs. This also makes sense for
      device tree, as each node under dss will be a platform device, and
      handling DPI & SDI somehow differently than the rest would just make the
      code more complex.
      
      This patch modifies the dpi.c and sdi.c to create drivers for the
      platform devices.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      a57dd4fe
    • Tomi Valkeinen's avatar
      OMAPDSS: create DPI & SDI devices · 53f576a8
      Tomi Valkeinen authored
      
      
      We currently have separate device/driver for each DSS HW module. The DPI
      and SDI outputs are more or less parts of the DSS or DISPC hardware
      modules, but in SW it makes sense to represent them as device/driver
      pairs similarly to all the other outputs. This also makes sense for
      device tree, as each node under dss will be a platform device, and
      handling DPI & SDI somehow differently than the rest would just make the
      code more complex.
      
      This patch modifies arch/arm/mach-omap2/display.c to create platform
      devices for DPI and SDI, and later patches will implement driver for
      them.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      53f576a8
    • Tomi Valkeinen's avatar
      OMAPDSS: create custom pdevs for DSS omap_devices · 966eaed0
      Tomi Valkeinen authored
      
      
      Instead of using omap_device_build() to create the omap_devices for DSS
      hwmods, create them with a custom function. This will allow us to create
      a parent-child hierarchy for the devices so that the omapdss_core device
      is parent for the rest of the dss hwmod devices.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      966eaed0
    • Tomi Valkeinen's avatar
      OMAPDSS: use platform_driver_probe for core/dispc/dss · 11436e1d
      Tomi Valkeinen authored
      
      
      The platform devices for omapdss, dss and dispc drivers are always
      present, so we can use platform_driver_probe instead of
      platform_driver_register.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      11436e1d
    • Tomi Valkeinen's avatar
      OMAPDSS: remove return from platform_driver_unreg · 04c742c3
      Tomi Valkeinen authored
      
      
      For unknown reasons we seem to have a return in each of the omapdss's
      uninit functions, which is a void function.
      
      Remove the returns.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      04c742c3
    • Tomi Valkeinen's avatar
      OMAPDSS: clean up the omapdss platform data mess · 00928eaf
      Tomi Valkeinen authored
      
      
      The omapdss pdata handling is a mess. This is more evident when trying
      to use device tree for DSS, as we don't have platform data anymore in
      that case. This patch cleans the pdata handling by:
      
      - Remove struct omap_display_platform_data. It was used just as a
        wrapper for struct omap_dss_board_info.
      - Pass the platform data only to omapdss device. The drivers for omap
        dss hwmods do not need the platform data. This should also work better
        for DT, as we can create omapdss device programmatically in generic omap
        boot code, and thus we can pass the pdata to it.
      - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
        that the dss hwmod drivers can call.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      00928eaf
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id · e23d83b0
      Tomi Valkeinen authored
      
      
      The DSI driver uses dsi_get_dsidev_id() to get the ID number for the DSI
      instance. However, there were a few places where dsidev->id was used
      instead of the function. Fix those places to use the function.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      e23d83b0
    • Tomi Valkeinen's avatar
      OMAPDSS: TFP410: pdata rewrite · 958f2717
      Tomi Valkeinen authored
      
      
      To ease device tree adaptation in the future, rewrite TFP410 platform
      data handling to be done inside probe(), so that probe() is the only
      place where we need to handle the DT/pdata choice.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      958f2717
    • Tomi Valkeinen's avatar
      OMAPFB: fix parsing of vram parameter · 3a028bb9
      Tomi Valkeinen authored
      
      
      omapfb_parse_vram_param()'s check for end pointer returned from
      simple_strtoul() is wrong, causing the code to bug if the second or
      later vram parameters are non-parseable, for example
      "omapfb.vram=0:2M,:5M".
      
      However, even in that case the code will most likely bail out with
      -EINVAL in the following checks, so the bug is probably not a fatal one.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Reported-by: default avatarHein Tibosch <hein_tibosch@yahoo.es>
      3a028bb9
    • Grazvydas Ignotas's avatar
      OMAPDSS: OMAPFB: always allow to configure overlay · b3e68d30
      Grazvydas Ignotas authored
      
      
      Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
      Instead of failing, allow it to configure the first overlay as if there
      was only one overlay, the remaining ones will have to be configured in
      other ways (sysfs).
      
      This allows overlay-controlling programs (like video players) to function
      properly when framebuffer is cloned to another display (like TV).
      
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      b3e68d30
    • Grazvydas Ignotas's avatar
      OMAPDSS: VENC: allow switching venc output type at runtime · 0aca3c63
      Grazvydas Ignotas authored
      
      
      VENC output type (composite/svideo) doesn't have to be fixed by board
      wiring, it is possible to also provide composite signal through svideo
      luminance connector (software enabled), which is what pandora does.
      
      Having to recompile the kernel for users who have TV connector types
      that don't match default board setting is very inconvenient, especially
      for users of a consumer device, so add support for switching VENC output
      type at runtime over a new sysfs file output_type.
      
      Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      0aca3c63
  2. 10 May, 2012 1 commit
    • Tomi Valkeinen's avatar
      Merge branch 'for-l-o-3.5' · 9b71fb5c
      Tomi Valkeinen authored
      Conflicts:
      	drivers/video/omap2/displays/panel-taal.c
      
      Merge OMAP DSS related board file changes. The branch will also be
      merged through linux-omap tree to solve conflicts.
      9b71fb5c
  3. 09 May, 2012 20 commits
    • Tomi Valkeinen's avatar
      Merge branch 'archit/set-timing-work' · 1dfafbc6
      Tomi Valkeinen authored
      
      
      An overlay manager's timings (the manager size, and blanking parameters
      if an LCD manager) are DISPC shadow registers, and they should hence
      follow the correct programming model.
      
      This series makes the video timings an extra_info parameter in manager's
      private data. The interface drivers now apply the timings instead of
      directly writing to registers.
      
      This change also prevents the need to use display resolution for overlay
      checks, hence making some of the APPLY functions less dependent on the
      display. Some DISPC functions that needed display width can also use
      these privately stored timings.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      1dfafbc6
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() · 81ab95b7
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      81ab95b7
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() · 3fa03ba8
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      3fa03ba8
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer · b3d795ab
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      b3d795ab
    • Archit Taneja's avatar
      OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled · fcc36619
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      fcc36619
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Remove display dependency from overlay and manager checks · 228b2134
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      228b2134
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Don't check manager settings if it is disabled · 5dd747e8
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      5dd747e8
    • Archit Taneja's avatar
      OMAPDSS: MANAGER: Create a function to check manager timings · b917fa39
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      b917fa39
    • Archit Taneja's avatar
      OMAPDSS: Apply manager timings instead of direct DISPC writes · 41721163
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      41721163
    • Archit Taneja's avatar
      OMAPDSS: APPLY: Add manager timings as extra_info in private data · 45324a26
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      45324a26
    • Archit Taneja's avatar
      OMAPDSS: DISPC: Remove Fake VSYNC support · 408d9dbb
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      408d9dbb
    • Archit Taneja's avatar
      OMAPDSS: Fix DSI_FCLK clock source selection · a2e5d827
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      a2e5d827
    • Archit Taneja's avatar
      OMAPDSS: HDMI: define and dump CORE registers in correct order · 9b9c457b
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      9b9c457b
    • Archit Taneja's avatar
      OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump · 3c7de247
      Archit Taneja authored
      
      
      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: default avatarArchit Taneja <archit@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      3c7de247
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: implement generic DSI pin config · e4a9e94c
      Tomi Valkeinen authored
      
      
      In preparation for device tree, this patch changes how the DSI pins are
      configured. The current configuration method is only doable with board
      files and the configuration data is OMAP specific.
      
      This patch moves the configuration data to the panel's platform data,
      and the data can easily be given via DT in the future. The configuration
      data format is also changed to a generic one which should be suitable
      for all platforms.
      
      The new format is an array of pin numbers, where the array items start
      from clock + and -, then data1 + and -, and so on. For example:
      
      {
      	0,	// pin num for clock lane +
      	1,	// pin num for clock lane -
      	2,	// pin num for data1 lane +
      	3,	// pin num for data1 lane -
      	...
      }
      
      The pin numbers are translated by the DSI driver and used to configure
      the hardware appropriately.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      e4a9e94c
    • Tomi Valkeinen's avatar
      OMAPDSS: Taal: move reset gpio handling to taal driver · 3acc797c
      Tomi Valkeinen authored
      
      
      The reset GPIO for Taal panel driver is currently requested in the
      4430sdp board file. This patch moves the gpio request/free into the Taal
      driver, where it should be.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      3acc797c
    • Tomi Valkeinen's avatar
      OMAPDSS: TFP410: rename dvi files to tfp410 · dac8eb5f
      Tomi Valkeinen authored
      
      
      Now that the tfp410 driver has been renamed in the code, this patch
      finishes the renaming by renaming the files.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      dac8eb5f
    • Tomi Valkeinen's avatar
      OMAPDSS: TFP410: rename dvi -> tfp410 · 2e6f2ee7
      Tomi Valkeinen authored
      
      
      The driver for the TFP410 DPI-to-DVI chip was named quite badly as "DVI
      panel driver". This patch renames the code to use tfp410 name for the
      driver.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      2e6f2ee7
    • Tomi Valkeinen's avatar
      OMAP: board-files: remove custom PD GPIO handling for DVI output · e813a55e
      Tomi Valkeinen authored
      
      
      Now that the panel-dvi driver handles the PD (power-down) GPIO, we can
      remove the custom PD handling from the board files.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      e813a55e
    • Tomi Valkeinen's avatar
      OMAPDSS: panel-dvi: add PD gpio handling · 2da35193
      Tomi Valkeinen authored
      
      
      The driver for the TFP410 chip should handle the power-down signal of
      the chip, instead of the current way of handling it in the board files.
      
      This patch adds power_down_gpio into the device's platform data, and
      adds the necessary code in the driver to request and handle the GPIO.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      2da35193
  4. 03 May, 2012 3 commits
    • Chandrabhanu Mahapatra's avatar
      OMAPDSS: DISPC: Correct DISPC functional clock usage · 8b53d991
      Chandrabhanu Mahapatra authored
      
      
      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: default avatarChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      8b53d991
    • Chandrabhanu Mahapatra's avatar
      OMAPDSS: DISPC: Handle synclost errors in OMAP3 · 7faa9233
      Chandrabhanu Mahapatra authored
      
      
      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: default avatarChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      7faa9233
    • Chandrabhanu Mahapatra's avatar
      OMAPDSS: DISPC: Enable predecimation · aed74b55
      Chandrabhanu Mahapatra authored
      
      
      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: default avatarChandrabhanu Mahapatra <cmahapatra@ti.com>
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      aed74b55
  5. 23 Apr, 2012 5 commits