Skip to content

L
linux
Switch branch/tag
  1. 07 Sep, 2012 6 commits
    • 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
  3. 03 Sep, 2012 1 commit
  5. 01 Sep, 2012 5 commits
  7. 30 Aug, 2012 5 commits
  9. 29 Aug, 2012 18 commits
  11. 28 Aug, 2012 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7