1. 03 6月, 2016 1 次提交
  2. 03 3月, 2016 11 次提交
  3. 29 12月, 2015 2 次提交
  4. 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
  5. 17 6月, 2015 2 次提交
    • T
      OMAPDSS: componentize omapdss · 736e60dd
      Tomi Valkeinen 提交于
      omapdss kernel module contains drivers for multiple devices, one for
      each DSS submodule. The probing we have at the moment is a mess, and
      doesn't give us proper deferred probing nor ensure that all the devices
      are probed before omapfb/omapdrm start using omapdss.
      
      This patch solves the mess by using the component system for DSS
      submodules.
      
      The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi,
      venc) are the same: probe & remove functions are changed to bind &
      unbind, and new probe & remove functions are added which call
      component_add/del.
      
      The dss_core driver (dss.c) acts as a component master. Adding and
      matching the components is simple: all dss device's child devices are
      added as components.
      
      However, we do have some dependencies between the drivers. The order in
      which they should be probed is reflected by the list in core.c
      (dss_output_drv_reg_funcs). The drivers are registered in that order,
      which causes the components to be added in that order, which makes the
      components to be bound in that order. This feels a bit fragile, and we
      probably should improve the code to manage binds in random order.
      However, for now, this works fine.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      736e60dd
    • T
      OMAPDSS: remove uses of __init/__exit · ede92695
      Tomi Valkeinen 提交于
      The following patches will add component handling to omapdss, improving
      the handling of deferred probing. However, at the moment we're using
      quite a lot of __inits and __exits in the driver, which prevent normal
      dynamic probing and removal.
      
      This patch removes most of the uses of __init and __exit, so that we can
      register drivers after module init, and so that we can unregister
      drivers even if the module is built-in.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      ede92695
  6. 04 2月, 2015 1 次提交
  7. 02 12月, 2014 1 次提交
  8. 01 12月, 2014 3 次提交
  9. 26 11月, 2014 1 次提交
  10. 12 11月, 2014 5 次提交
  11. 22 10月, 2014 1 次提交
    • T
      OMAPDSS: set suppress_bind_attrs · 422ccbd5
      Tomi Valkeinen 提交于
      omapdss drivers cannot handle devices being unbound while the devices
      are part of a connected display pipeline. Module refcounts are used to
      prevent unloading the modules, but one can still manually unbind the
      devices via sysfs, causing crash.
      
      Set suppress_bind_attrs to disable the bind/unbind support via sysfs.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      422ccbd5
  12. 20 10月, 2014 1 次提交
  13. 04 7月, 2014 1 次提交
  14. 09 5月, 2014 2 次提交
    • 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
    • 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
  15. 07 5月, 2014 2 次提交
  16. 17 4月, 2014 1 次提交
  17. 04 4月, 2014 1 次提交
  18. 19 3月, 2014 2 次提交
  19. 05 3月, 2014 1 次提交
    • T
      OMAPDSS: convert pixel clock to common videomode style · d8d78941
      Tomi Valkeinen 提交于
      omapdss has its own video-timings struct, but we want to move the common
      videomode.
      
      The first step is to change the omapdss's pixelclock unit from kHz to
      Hz. Also, omapdss uses "pixel_clock" field name, whereas the common
      videomode uses "pixelclock" field name. This patch changes the field
      name also, as that makes it easy to spot any non-converted pixel_clock
      uses.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      d8d78941