Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 08 9月, 2012 10 次提交
    • T
      OMAPDSS: remove unnecessary includes · fe6a4662
      由 Tomi Valkeinen 提交于 
      Remove unnecessary includes from omapdss.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      fe6a4662
    • T
      OMAPFB1: remove a non-used table · 10bc80f6
      由 Tomi Valkeinen 提交于 
      The old omapfb driver contains a table for DMA element types, which is
not used. Remove it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      10bc80f6
    • T
      OMAPFB1: remove unnecessary includes · 9586778d
      由 Tomi Valkeinen 提交于 
      Remove unnecessary includes from the old omapfb driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9586778d
    • T
      OMAPDSS: Taal: use devm_* functions · 5e56ad44
      由 Tomi Valkeinen 提交于 
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      5e56ad44
    • T
      OMAPDSS: fix use of dssdev->caps · ab585254
      由 Tomi Valkeinen 提交于 
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ab585254
    • T
      OMAPDSS: DSI: calculate dsi clock · ee144e64
      由 Tomi Valkeinen 提交于 
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      ee144e64
    • T
      OMAPDSS: Add DSI fclk maximum to dss_features · bc63f304
      由 Tomi Valkeinen 提交于 
      Add max value of DSI functional clock to dss_features, so that DSI
driver can use it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      bc63f304
    • T
      OMAPDSS: HDMI: use vdda_hdmi_dac · 17486943
      由 Tomi Valkeinen 提交于 
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      17486943
    • T
      OMAPDSS: HDMI: Add delay to wait for 5V power · a84b2065
      由 Tomi Valkeinen 提交于 
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
      a84b2065
    • T
      OMAPDSS: HDMI: Move GPIO handling to HDMI driver · cca35017
      由 Tomi Valkeinen 提交于 
      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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
      cca35017
  3. 30 8月, 2012 12 次提交
  5. 29 8月, 2012 2 次提交
  7. 28 8月, 2012 1 次提交
  9. 25 8月, 2012 1 次提交
  11. 24 8月, 2012 3 次提交
  13. 23 8月, 2012 3 次提交
  15. 22 8月, 2012 8 次提交