Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 21 10月, 2015 1 次提交
  3. 20 9月, 2015 1 次提交
  5. 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
  7. 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
  9. 22 5月, 2015 1 次提交
  11. 09 4月, 2015 2 次提交
  13. 23 2月, 2015 1 次提交
  15. 01 1月, 2015 1 次提交
  17. 30 12月, 2014 1 次提交
  19. 24 12月, 2014 1 次提交
  21. 05 12月, 2014 1 次提交
  23. 22 11月, 2014 1 次提交
  25. 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
  27. 20 10月, 2014 1 次提交
  29. 08 10月, 2014 1 次提交
  31. 10 9月, 2014 1 次提交
  33. 17 7月, 2014 2 次提交
  35. 02 7月, 2014 1 次提交
  37. 22 6月, 2014 1 次提交
  39. 21 6月, 2014 1 次提交
  41. 13 5月, 2014 2 次提交
  43. 30 4月, 2014 1 次提交
  45. 24 4月, 2014 1 次提交
  47. 23 3月, 2014 1 次提交
  49. 06 3月, 2014 5 次提交
  51. 05 3月, 2014 1 次提交
  53. 18 1月, 2014 1 次提交
  55. 15 1月, 2014 2 次提交
  57. 09 1月, 2014 1 次提交
  59. 08 1月, 2014 2 次提交
  61. 07 1月, 2014 1 次提交