1. 07 Sep, 2012 12 commits
    • Tomi Valkeinen's avatar
      OMAPDSS: remove unnecessary includes · fe6a4662
      Tomi Valkeinen authored
      
      
      Remove unnecessary includes from omapdss.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      fe6a4662
    • Tomi Valkeinen's avatar
      OMAPFB1: remove a non-used table · 10bc80f6
      Tomi Valkeinen authored
      
      
      The old omapfb driver contains a table for DMA element types, which is
      not used. Remove it.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      10bc80f6
    • Tomi Valkeinen's avatar
      OMAPFB1: remove unnecessary includes · 9586778d
      Tomi Valkeinen authored
      
      
      Remove unnecessary includes from the old omapfb driver.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      9586778d
    • Tomi Valkeinen's avatar
      OMAPDSS: Taal: use devm_* functions · 5e56ad44
      Tomi Valkeinen authored
      
      
      Use devm_ functions in panel-taal.c's probe when possible. Also reorder
      the initialization sequence so that devm_ allocations are done before
      things that require explicit freeing. This simplifies the probe and
      remove functions.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      5e56ad44
    • Tomi Valkeinen's avatar
      OMAPDSS: fix use of dssdev->caps · ab585254
      Tomi Valkeinen authored
      Recent commit dca2b152
      
       (OMAPDSS: DSI:
      Maintain copy of operation mode in driver data) broke DSI for video mode
      displays. The commit changed the way dssdev->caps are initialized, and
      the result was that every DSI display is initialized with manual-update
      and tear-elim caps.
      
      The code that sets dssdev->caps is not very good, even when fixed.
      omapdss driver shouldn't be writing dssdev->caps at all.
      
      This patch fixes the problem with video mode displays by moving the
      initialization of dssdev->caps to the panel driver. The same change is
      done for RFBI.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      ab585254
    • Tomi Valkeinen's avatar
      OMAP: 4430SDP: remove DSI clock config from board file · 4dc3eed4
      Tomi Valkeinen authored
      
      
      DSI clocks are now configured dynamically by the DSI driver, so we can
      remove the hardcoded clock configuration from the board file.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      4dc3eed4
    • Tomi Valkeinen's avatar
      OMAPDSS: DSI: calculate dsi clock · ee144e64
      Tomi Valkeinen authored
      
      
      Currently the way to configure clocks related to DSI (both DSI and DISPC
      clocks) happens via omapdss platform data. The reason for this is that
      configuring the DSS clocks is a very complex problem, and it's
      impossible for the SW to know requirements about things like
      interference.
      
      However, for general cases it should be fine to calculate the dividers
      for clocks in the SW. The calculated clocks are probably not perfect,
      but should work.
      
      This patch adds support to calculate the dividers when using DSI command
      mode panels. The panel gives the required DDR clock rate and LP clock
      rate, and the DSI driver configures itself and DISPC accordingly.
      
      This patch is somewhat ugly, though. The code does its job by modifying
      the platform data where the clock dividers would be if the board file
      gave them. This is not how it's going to be in the future, but allows us
      to have quite simple patch and keep the backward compatibility.
      
      It also allows the developer to still give the exact dividers from the
      board file when there's need for that, as long as the panel driver does
      not override them.
      
      There are also other areas for improvement. For example, it would be
      better if the panel driver could ask for a DSI clock in a certain range,
      as, at least command mode panels, the panel can work fine with many
      different clock speeds.
      
      While the patch is not perfect, it allows us to remove the hardcoded
      clock dividers from the board file, making it easier to bring up a new
      panel and to use device tree from omapdss.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      ee144e64
    • Tomi Valkeinen's avatar
      OMAPDSS: Add DSI fclk maximum to dss_features · bc63f304
      Tomi Valkeinen authored
      
      
      Add max value of DSI functional clock to dss_features, so that DSI
      driver can use it.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      bc63f304
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: use vdda_hdmi_dac · 17486943
      Tomi Valkeinen authored
      
      
      The HDMI driver requires vdda_hdmi_dac power for operation, but does not
      enable it. This has worked because the regulator has been always
      enabled.
      
      But this may not always be the case, as I encountered when implementing
      HDMI device tree support.
      
      This patch changes the HDMI driver to use the vdda_hdmi_dac.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      17486943
    • Tomi Valkeinen's avatar
      OMAP4: TWL: add vdda_hdmi_dac regulator supply · 8a3d895b
      Tomi Valkeinen authored
      
      
      HDMI requires vdda_hdmi_dac (vdac) power for operation. The regulator,
      or the regulator supplying the vdac, has been enabled by default and
      things have worked without the HDMI driver enabling the vdac.
      
      I encountered the problem when implementing HDMI device tree support,
      where the regulator was not enabled by default.
      
      This patch adds the vdda_hdmi_dac to twl-common.c so that the HDMI
      driver can use it.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      8a3d895b
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: Add delay to wait for 5V power · a84b2065
      Tomi Valkeinen authored
      
      
      TPD12S015A spec says to wait 300us after setting CT_CP_HPD gpio for the
      5V power output to reach 90% of the voltage. This patch adds the delay
      to the driver.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      a84b2065
    • Tomi Valkeinen's avatar
      OMAPDSS: HDMI: Move GPIO handling to HDMI driver · cca35017
      Tomi Valkeinen authored
      
      
      We currently manage HDMI GPIOs in the board files via
      platform_enable/disable calls. This won't work with device tree, and in
      any case the correct place to manage the GPIOs is in the HDMI driver.
      
      This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
      handling is moved to the common hdmi.c file, and this probably needs to
      be revisited when adding OMAP5 HDMI support to see if the GPIO handling
      needs to be moved to IP specific files.
      
      Signed-off-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      cca35017
  2. 03 Sep, 2012 1 commit
  3. 01 Sep, 2012 5 commits
  4. 30 Aug, 2012 5 commits
  5. 29 Aug, 2012 17 commits