1. 05 4月, 2017 2 次提交
  2. 07 1月, 2017 1 次提交
    • C
      ASoC: wm_adsp: Add mechanism to preload firmware on a core · af813a6f
      Charles Keepax 提交于
      As requirements to bring up audio paths are continuous getting tighter
      and the DSP download to most ADSP devices happens over an external bus
      it can become an important factor in the path bring up time. As such
      sometimes it is a reasonable trade off to download the firmware ahead of
      when it will be required and take a small hit on power consumption for
      keeping the core powered up.
      
      This "preloading" adds an additional control for each DSP core "DSPx
      Preload Switch" that when set to true will power up the DSP core and
      download the firmware currently selected in the "DSPx Firmware" control.
      Whilst the core is preloaded the current firmware can not be changed and
      the CODEC will be kept powered up and SYSCLK held on. Although future
      improvements may allow the SYSCLK to be powered down as well because
      the hardware only requires SYSCLK whilst the download is actually taking
      place, but this is not covered in this series.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      af813a6f
  3. 29 11月, 2016 1 次提交
  4. 23 11月, 2016 1 次提交
    • R
      ASoC: wm_adsp: Firmware controls should be added as codec controls · 685f51a5
      Richard Fitzgerald 提交于
      We were adding firmware controls as card controls (using
      snd_soc_add_codec_controls). The DSP is part of a specific codec so
      we should be adding them as codec controls. Adding as codec controls
      also means that if the codec has a name_prefix it will be added to
      the control name, which won't happen when adding as a card control.
      
      As that was the only use of the card pointer in struct wm_adsp it can
      be removed.
      
      For ADSP2 codecs a wm_adsp2_codec_probe() was added since the original
      control handling was written, and that's the logical place to store a
      pointer to the codec rather than delaying it until the codec is
      powered-up.
      
      For ADSP1 we don't use a codec_probe() stage so the codec pointer
      initialization replaces the original card pointer initialization in
      wm_adsp1_event().
      Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      685f51a5
  5. 27 9月, 2016 1 次提交
  6. 25 9月, 2016 2 次提交
    • C
      ASoC: wm_adsp: Make DSP preloader a supply widget · 5ca7e170
      Charles Keepax 提交于
      Currently the DSP loading is split into two widgets, the preloader that
      is a snd_soc_dapm_dai_link widget which starts a thread to download
      the firmware, and the DSP itself which is a snd_soc_dapm_out_drv and
      synchronises the thread back in to the DAPM sequence. This allows the
      firmware download to be overlapped with the rest of the path bring up.
      
      The use of a snd_soc_dapm_dai_link widget requires the preloader to be part
      of the audio path in DAPM, really a supply widget is a better fit for the
      preloader. The preloader is something that needs to be done for the DSP to
      function, not a part of the audio path itself.
      
      This change makes the DSP preloader widget a supply widget, which as well
      as probably being a better fit will also make it much simpler to power up
      the preloader widget to trigger firmware download to the core independently
      of the audio path coming up.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      5ca7e170
    • C
      ASoC: wm_adsp: Separate concept of booted and running · 28823eba
      Charles Keepax 提交于
      Currently the wm_adsp driver has a flag that indicates the DSP is
      "running", this flag is used to gate access to the hardware.  However this
      flag is actually set in the firmware download thread after the firmware has
      been downloaded, but this is before the core is actually started running,
      so really it currently indicates that the core has been booted and is
      perhaps running.
      
      This patch clearly separates out the concepts of booted (firmware is
      downloaded) and running (code is executing on the DSP) within the wm_adsp
      driver.
      Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      28823eba
  7. 30 5月, 2016 1 次提交
  8. 27 4月, 2016 1 次提交
  9. 29 1月, 2016 1 次提交
  10. 07 1月, 2016 2 次提交
  11. 23 12月, 2015 3 次提交
  12. 13 12月, 2015 2 次提交
  13. 04 10月, 2015 1 次提交
  14. 19 6月, 2015 1 次提交
    • R
      ASoC: wm_adsp: Move DSP Rate controls into the codec · 336d0442
      Richard Fitzgerald 提交于
      The rate controls are codec-specific, it's not possible to
      generically say what the range or the meaning of each control
      is (or even if they exist at all) - that depends on the
      particular codec.
      
      This is currently being handled for Arizona codecs by putting
      an Arizona-specific table of controls inside the wm_adsp driver.
      This creates a dependency between wm_adsp and arizona.c, and is an
      awkward solution if the ADSP is used in another family of codecs
      
      Fix this by moving the Arizona-specific rate controls into the
      Arizona codec drivers.
      Signed-off-by: NRichard Fitzgerald <rf@opensource.wolfsonmicro.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      336d0442
  15. 11 6月, 2015 3 次提交
  16. 03 6月, 2015 1 次提交
  17. 27 4月, 2015 3 次提交
  18. 09 1月, 2014 2 次提交
  19. 01 8月, 2013 1 次提交
  20. 29 7月, 2013 1 次提交
  21. 20 6月, 2013 1 次提交
  22. 13 5月, 2013 1 次提交
  23. 30 3月, 2013 1 次提交
  24. 13 3月, 2013 1 次提交
  25. 18 1月, 2013 1 次提交
  26. 16 1月, 2013 1 次提交
  27. 13 1月, 2013 1 次提交
  28. 09 1月, 2013 1 次提交
  29. 29 11月, 2012 1 次提交