1. 15 8月, 2017 1 次提交
  2. 02 11月, 2016 2 次提交
  3. 03 6月, 2016 2 次提交
  4. 20 5月, 2016 2 次提交
  5. 29 12月, 2015 1 次提交
  6. 24 9月, 2015 1 次提交
    • J
      OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled · 8a9d4626
      Jyri Sarha 提交于
      Reconfigure and restart audio when display is enabled, if audio
      playback was active before. This is needed in a situation when an
      audio+video stream application opens the audio stream before the
      video. When video stream is opened the display mode may change and
      that aborts audio playback, because the display is momentarily
      turned off.
      
      The audio configuration is stored when it is successfully applied and
      a boolean is set when the audio playback is started and unset when
      stopped. This data is used to reconfigure the audio when display is
      re-enabled. The audio playback is aborted if the reconfiguration fails.
      
      A new spin lock is introduced in order to protect state variables
      related to audio playback status. This is needed for the transition
      from display enabled state (when audio start/stop commands can be
      written to HW) to display disabled state (when audio start/stop
      commands update only the hdmi.audio_playing variable) to always
      serialize correctly with the start/stop audio commands. The already
      existing mutex can not be used, because the audio start and stop
      commands are executed in atomic context.
      
      For example: when display is turned back on we take the spinlock and
      we can be sure that the audio start/stop status will not change while
      we update the HW according to hdmi.audio_playing state and set
      hdmi.display_enabled to true. After releasing the lock
      hdmi.display_enabled is true and all audio_start and audio_stop
      commands write their stuff directly to HW.
      Signed-off-by: NJyri Sarha <jsarha@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8a9d4626
  7. 01 12月, 2014 2 次提交
  8. 26 11月, 2014 6 次提交
  9. 12 11月, 2014 5 次提交
  10. 04 7月, 2014 5 次提交
  11. 09 5月, 2014 4 次提交
    • T
      OMAPDSS: HDMI: Add OMAP5 HDMI support · f5bab222
      Tomi Valkeinen 提交于
      This adds a new driver to omapdss for OMAP5 HDMI. However, the new
      driver uses common HDMI files which are shared with OMAP4 HDMI driver.
      
      OMAP5 HDMI has a different HDMI core IP compared to OMAP4, but has very
      similar PLL and PHY IPs which can be handled with common code.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      f5bab222
    • A
      OMAPDSS: HDMI: PHY changes for OMAP5 · 19289fdc
      Archit Taneja 提交于
      OMAP5 HDMI PHY has some differences compared to OMAP4 HDMI PHY. This
      patch creates a features struct which help the driver configure the PHY
      based on what SoC it is.
      
      Some of the features aren't currenlty used, but will come in use later.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      19289fdc
    • A
      OMAPDSS: HDMI: support larger register offsets for OMAP5 HDMI core · 8955b727
      Archit Taneja 提交于
      The HDMI core IP on OMAP5 has a wider address range for registers. The offsets
      for the later registers can't fit into the u16 type currently used for hdmi
      register read and write functions. Use u32 for offsets instead.
      Signed-off-by: NArchit Taneja <archit@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      8955b727
    • T
      OMAPDSS: HDMI: move irq & phy pwr handling · dcf5f729
      Tomi Valkeinen 提交于
      HDMI IRQ handling was moved into hdmi_phy.c when restructuring the HDMI
      driver. While this worked fine, it's not correct.
      
      The HDMI IRQ handling should be either in the hdmi_wp, or in the main
      hdmi driver. This patch moves the handling to the main hdmi driver, as I
      feel it's a more appropriate choice.
      
      This move also requires changing the handling of the PHY power, as that
      was partly handled in the IRQ handler. The PHY power is handled via the
      WP module. An option would be to give HDMI PHY driver function pointers
      that it could use to manage the PHY power, but as the PHY power is not
      needed to access the PHY registers, the handling was also moved to the
      main HDMI driver. This could be changed later if need be.
      
      Note that there's slightly similar power issue with the PLL: the HDMI
      PLLs power is also handled via the WP module. For now, the PLL power
      handling is still done inside the PLL driver.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      dcf5f729
  12. 07 5月, 2014 1 次提交
  13. 17 4月, 2014 1 次提交
  14. 13 1月, 2014 3 次提交
  15. 09 10月, 2013 4 次提交