1. 17 7月, 2017 1 次提交
    • J
      ASoC: fix pcm-creation regression · c641e5b2
      Johan Hovold 提交于
      This reverts commit 99b04f4c ("ASoC: add Component level
      pcm_new/pcm_free"), which started calling the pcm_new callback for every
      component in a *card* when creating a new pcm, something which does not
      seem to make any sense.
      
      This specifically led to memory leaks in systems with more than one
      platform component and where DMA memory is allocated in the
      platform-driver callback. For example, when both mcasp devices are being
      used on an am335x board, DMA memory would be allocated twice for every
      DAI link during probe.
      
      When CONFIG_SND_VERBOSE_PROCFS was set this fortunately also led to
      warnings such as:
      
      WARNING: CPU: 0 PID: 565 at ../fs/proc/generic.c:346 proc_register+0x110/0x154
      proc_dir_entry 'sub0/prealloc' already registered
      
      Since there seems to be no users of the new component callbacks, and the
      current implementation introduced a regression, let's revert the
      offending commit for now.
      
      Fixes: 99b04f4c ("ASoC: add Component level pcm_new/pcm_free")
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Tested-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: stable <stable@vger.kernel.org>	# 4.10
      c641e5b2
  2. 03 6月, 2017 2 次提交
    • T
      ALSA: pcm: Drop the old copy and silence ops · 2ae48354
      Takashi Iwai 提交于
      Now that all users of old copy and silence ops have been converted to
      the new PCM ops, the old stuff can be retired and go away.
      Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      2ae48354
    • T
      ALSA: pcm: Introduce copy_user, copy_kernel and fill_silence ops · 29d1a873
      Takashi Iwai 提交于
      For supporting the explicit in-kernel copy of PCM buffer data, and
      also for further code refactoring, three new PCM ops, copy_user,
      copy_kernel and fill_silence, are introduced.  The old copy and
      silence ops will be deprecated and removed later once when all callers
      are converted.
      
      The copy_kernel ops is the new one, and it's supposed to transfer the
      PCM data from the given kernel buffer to the hardware ring-buffer (or
      vice-versa depending on the stream direction), while the copy_user ops
      is equivalent with the former copy ops, to transfer the data from the
      user-space buffer.
      
      The major difference of the new copy_* and fill_silence ops from the
      previous ops is that the new ops take bytes instead of frames for size
      and position arguments.  It has two merits: first, it allows the
      callback implementation often simpler (just call directly memcpy() &
      co), and second, it may unify the implementations of both interleaved
      and non-interleaved cases, as we'll see in the later patch.
      
      As of this stage, copy_kernel ops isn't referred yet, but only
      copy_user is used.
      Reviewed-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Acked-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      29d1a873
  3. 10 1月, 2017 3 次提交
  4. 07 1月, 2017 1 次提交
  5. 16 12月, 2016 1 次提交
  6. 23 11月, 2016 1 次提交
  7. 27 9月, 2016 1 次提交
  8. 14 9月, 2016 1 次提交
  9. 30 5月, 2016 2 次提交
    • P
      ASoC: dpcm: play nice with CODEC<->CODEC links · 5fdd022c
      Piotr Stankiewicz 提交于
      Currently in situations where a normal CODEC to CODEC link follows a
      DPCM DAI, an error in the following form will be logged:
      
      ASoC: can't get [playback|capture] BE for <widget name>
      ASoC: no BE found for <widget name>
      
      This happens because all widgets in a path containing a DPCM DAI will
      be passed to dpcm_add_paths, which will try to interpret the CODEC<->CODEC
      as if it were a DPCM DAI, in turn causing the error.
      
      This patch aims to resolve the described issue by stopping the DPCM graph
      walk, initiated from dpcm_path_get, at the first widget associated with
      a DPCM BE.
      Signed-off-by: NPiotr Stankiewicz <piotrs@opensource.wolfsonmicro.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      5fdd022c
    • P
      ASoC: dapm: support user-defined stop condition in dai_get_connected_widgets · 6742064a
      Piotr Stankiewicz 提交于
      Certain situations may warrant examining DAPM paths only to a certain
      arbitrary point, as opposed to always following them to the end. For
      instance, when establishing a connection between a front-end DAI link
      and a back-end DAI link in a DPCM path, it does not make sense to walk
      the DAPM graph beyond the first widget associated with a back-end link.
      
      This patch introduces a mechanism which lets a user of
      dai_get_connected_widgets supply a function which will be called for
      every node during the graph walk. When invoked, this function can
      execute arbitrary logic to decide whether the walk, given a DAPM widget
      and walk direction, should be terminated at that point or continued
      as normal.
      Signed-off-by: NPiotr Stankiewicz <piotrs@opensource.wolfsonmicro.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      6742064a
  10. 03 2月, 2016 1 次提交
  11. 29 1月, 2016 1 次提交
  12. 06 1月, 2016 1 次提交
  13. 13 12月, 2015 1 次提交
  14. 19 11月, 2015 1 次提交
    • M
      ASoC: Change the PCM runtime array to a list · 1a497983
      Mengdong Lin 提交于
      Currently the number of DAI links is statically defined by the machine
      driver at build time using an array. This makes it difficult to shrink/
      grow the number of DAI links at runtime in order to reflect any changes
      in topology.
      
      We can change the DAI link array in the core to a list so that PCMs and
      FE DAI links can be added and deleted at runtime to reflect changes in
      use case and DSP topology. The machine driver can still register DAI links
      as an array.
      
      As the 1st step, this patch change the PCM runtime array to a list. A new
      PCM runtime is added to the list when a DAI link is bound successfully.
      
      Later patches will further implement the DAI link list.
      
      More:
      - define snd_soc_new/free_pcm_runtime() to create/free a runtime.
      - define soc_add_pcm_runtime() to add a runtime to the rtd list.
      - define soc_remove_pcm_runtimes() to clean up the runtime list.
      
      - traverse the rtd list to probe the link components and dais.
      
      - Add a field "num" to PCM runtime struct, used to specify the device
        number when creating the pcm device, and for a soc card to access
        its dai_props array.
      
      - The following 3rd party machine/platform drivers iterate the rtd list
        to check the runtimes:
        sound/soc/intel/atom/sst-mfld-platform-pcm.c
        sound/soc/intel/boards/cht_bsw_rt5645.c
        sound/soc/intel/boards/cht_bsw_rt5672.c
        sound/soc/intel/boards/cht_bsw_max98090_ti.c
      Signed-off-by: NMengdong Lin <mengdong.lin@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      1a497983
  15. 16 11月, 2015 1 次提交
    • K
      ASoC: dpcm: Make BE prepare possible in suspend state · 95f444dc
      Koro Chen 提交于
      During suspend/resume, there is a flow that if a driver does not support
      SNDRV_PCM_INFO_RESUME, it will fail at snd_pcm_resume(), and user space
      can then issue SNDRV_PCM_IOCTL_PREPARE to let audio continue to play.
      
      However, in dpcm_be_dai_prepare() it only allows BEs to be prepared
      in state SND_SOC_DPCM_STATE_HW_PARAMS or SND_SOC_DPCM_STATE_STOP.
      The BE state will then stay in SND_SOC_DPCM_STATE_SUSPEND, consequently
      dpcm_be_dai_shutdown() is skipped in the end of playback and
      be_substream->runtime is not cleared while this runtime is actually freed
      by snd_pcm_detach_substream(). If another suspend comes, a NULL pointer
      dereference will happen in snd_pcm_suspend() when accessing
      BE substream's runtime.
      Signed-off-by: NKoro Chen <koro.chen@mediatek.com>
      Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      95f444dc
  16. 21 10月, 2015 1 次提交
  17. 20 9月, 2015 1 次提交
  18. 29 7月, 2015 1 次提交
    • L
      ASoC: dapm: Simplify list creation in dapm_dai_get_connected_widgets() · 1ce43acf
      Lars-Peter Clausen 提交于
      When running dapm_dai_get_connected_widgets() currently in
      is_connected_{input,output}_ep() for each widget that gets added the array
      is resized and the code also loops over all existing entries to avoid
      adding a widget multiple times.
      
      The former can be avoided by collecting the widgets in a linked list and
      only once we have all widgets allocate the array.
      
      The later can be avoided by changing when the widget is added. Currently it
      is added when walking the neighbor lists of a widget. Since a widget can be
      neighbors with multiple other widgets it could get added twice and hence
      the check is necessary. But the main body of is_connected_{input,output}_ep
      is guaranteed to be only executed at most once per widget. So adding the
      widget to the list at the beginning of the function automatically makes
      sure that each widget gets only added once. The only difference is that
      using this method the starting point itself will also end up on the list,
      but it can easily be skipped when creating the array.
      
      Overall this reduces the code size and speeds things slightly up.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      1ce43acf
  19. 07 7月, 2015 1 次提交
    • K
      ASoC: dpcm: Add checks of playback/capture before dpcm_get_be · c5b8540d
      Koro Chen 提交于
      In dpcm_get_be(), it looks for a BE rtd that has the DAI widget
      according to current stream type. Only playback_widgets are searched
      in the case of playback stream and vice versa. However, the DAI widget
      itself can be playback or capture.
      
      If the DAI widget is capture, but current stream type is playback,
      dpcm_get_be() will always fail to find a rtd, print error messages,
      and continue to the next DAI widget in list. We can just skip this
      DAI widget to further suppress error messages. This happens in a
      special case when 2 codecs are inter-connected, and the 1st codec's
      "capture" widget is used to send data to the 2nd codec during "playback":
      
      mtk-rt5650-rt5676 sound: ASoC: can't get playback BE for Sub AIF2 Capture
      rt5650_rt5676 Playback: ASoC: no BE found for Sub AIF2 Capture
      
      Add checks to continue to next DAI widget if current DAI widget's
      direction does not match the stream type.
      Signed-off-by: NKoro Chen <koro.chen@mediatek.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      c5b8540d
  20. 22 5月, 2015 1 次提交
  21. 09 4月, 2015 2 次提交
  22. 23 2月, 2015 1 次提交
  23. 01 1月, 2015 1 次提交
  24. 30 12月, 2014 1 次提交
  25. 24 12月, 2014 1 次提交
  26. 05 12月, 2014 1 次提交
  27. 22 11月, 2014 1 次提交
  28. 05 11月, 2014 1 次提交
    • T
      ASoC: dpcm: Fix race between FE/BE updates and trigger · ea9d0d77
      Takashi Iwai 提交于
      DPCM can update the FE/BE connection states totally asynchronously
      from the FE's PCM state.  Most of FE/BE state changes are protected by
      mutex, so that they won't race, but there are still some actions that
      are uncovered.  For example, suppose to switch a BE while a FE's
      stream is running.  This would call soc_dpcm_runtime_update(), which
      sets FE's runtime_update flag, then sets up and starts BEs, and clears
      FE's runtime_update flag again.
      
      When a device emits XRUN during this operation, the PCM core triggers
      snd_pcm_stop(XRUN).  Since the trigger action is an atomic ops, this
      isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
      It eventually updates and clears FE's runtime_update flag while
      soc_dpcm_runtime_update() is running concurrently, and it results in
      confusion.
      
      Usually, for avoiding such a race, we take a lock.  There is a PCM
      stream lock for that purpose.  However, as already mentioned, the
      trigger action is atomic, and we can't take the lock for the whole
      soc_dpcm_runtime_update() or other operations that include the lengthy
      jobs like hw_params or prepare.
      
      This patch provides an alternative solution.  This adds a way to defer
      the conflicting trigger callback to be executed at the end of FE/BE
      state changes.  For doing it, two things are introduced:
      
      - Each runtime_update state change of FEs is protected via PCM stream
        lock.
      - The FE's trigger callback checks the runtime_update flag.  If it's
        not set, the trigger action is executed there.  If set, mark the
        pending trigger action and returns immediately.
      - At the exit of runtime_update state change, it checks whether the
        pending trigger is present.  If yes, it executes the trigger action
        at this point.
      Reported-and-tested-by: NQiao Zhou <zhouqiao@marvell.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      ea9d0d77
  29. 20 10月, 2014 1 次提交
  30. 08 10月, 2014 1 次提交
  31. 10 9月, 2014 1 次提交
  32. 17 7月, 2014 2 次提交
  33. 02 7月, 2014 1 次提交
  34. 22 6月, 2014 1 次提交