Skip to content

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