1. 16 8月, 2017 2 次提交
  2. 15 8月, 2017 1 次提交
  3. 02 6月, 2017 1 次提交
  4. 07 4月, 2017 1 次提交
    • R
      drm: omap: use common OF graph helpers · 09bffa6e
      Rob Herring 提交于
      The OMAP driver has its own OF graph helpers that are similar to the
      common helpers. This commit replaces most of the calls with the common
      helpers. There's still a couple of custom helpers left, but the driver
      needs more extensive changes to get rid of them.
      
      In dss_init_ports, we invert the loop, looping through the known ports
      and matching them to DT nodes rather than looping thru DT nodes and
      matching them to the ports.
      Signed-off-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NSean Paul <seanpaul@chromium.org>
      09bffa6e
  5. 02 11月, 2016 5 次提交
  6. 07 6月, 2016 1 次提交
    • J
      drm/omapdrm: Add gamma table support to DSS dispc · acc3a231
      Jyri Sarha 提交于
      Add gamma table support to DSS dispc.
      
      DSS driver initializes the default gamma table at component bind time
      and holds a copy of all gamma tables in its internal data structure.
      
      Each call to dispc_mgr_set_gamma() updates the internal table and
      triggers write to the HW, if it is enabled. The tables are restored to
      HW in PM resume callback. The drivers internal data structure match
      the HW tables in size and in number of significant bits per color
      component. The dispc_mgr_set_gamma() converts the size of any given
      table for the internal data structure using linear interpolation.
      Default gamma table is restored if NULL is given in place of gamma
      lut.
      
      dispc_mgr_gamma_size() gives HW gamma table size for the channel and
      returns 0 if gamma table is not supported by the HW or the DSS driver.
      Signed-off-by: NJyri Sarha <jsarha@ti.com>
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      acc3a231
  7. 03 6月, 2016 2 次提交
  8. 31 5月, 2016 2 次提交
  9. 20 5月, 2016 2 次提交
  10. 03 3月, 2016 10 次提交
  11. 29 12月, 2015 2 次提交
  12. 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
  13. 17 6月, 2015 3 次提交
    • T
      OMAPDSS: HDMI4: fix error handling · 9bba13f0
      Tomi Valkeinen 提交于
      Error handling in hdmi_power_on_full() is not correct, and could leave
      resources unfreed.
      
      Fix this by arranging the error labels correctly.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      9bba13f0
    • 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
  14. 02 12月, 2014 1 次提交
  15. 01 12月, 2014 2 次提交
  16. 26 11月, 2014 1 次提交
  17. 12 11月, 2014 3 次提交
    • T
      OMAPDSS: HDMI: use common DSS PLL support · c84c3a5b
      Tomi Valkeinen 提交于
      Now that we have the common DSS PLL support, change HDMI to use it. This
      results in quite a lot of changes, but almost all of them are trivial
      name changes.
      
      The function to program the PLL settings can be removed from hdmi_pll.c,
      as the common PLL API contains the same functionality.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c84c3a5b
    • T
      OMAPDSS: HDMI: split PLL enable & config · c2fbd061
      Tomi Valkeinen 提交于
      At the moment we have one function, hdmi_pll_enable, which enables the
      PLL and writes the PLL configuration to registers.
      
      To make the HDMI PLL ahere to the DSS PLL API, split the hdmi_pll_enable
      into two parts: hdmi_pll_enable which enables the PLL HW, and
      hdmi_pll_set_config which writes the config.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      c2fbd061
    • T
      OMAPDSS: HDMI: store WP pointer to hdmi_pll_data · 03aafa2c
      Tomi Valkeinen 提交于
      HDMI PLL code needs the pointer to the WP block so that it can manage
      its power. Currently this is passed as a function parameter to
      hdmi_pll_enable and hdmi_pll_disable. To make the PLL function adhere to
      the DSS PLL API, we need to remove the WP parameter.
      
      This patch stores the WP pointer to hdmi_pll_data in hdmi_pll_init, so
      that it's available when needed.
      Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
      03aafa2c