Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 30 12月, 2014 1 次提交
  3. 05 12月, 2014 1 次提交
  5. 22 11月, 2014 1 次提交
  7. 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
  9. 20 10月, 2014 1 次提交
  11. 08 10月, 2014 1 次提交
  13. 10 9月, 2014 1 次提交
  15. 17 7月, 2014 2 次提交
  17. 02 7月, 2014 1 次提交
  19. 22 6月, 2014 1 次提交
  21. 21 6月, 2014 1 次提交
  23. 13 5月, 2014 2 次提交
  25. 30 4月, 2014 1 次提交
  27. 24 4月, 2014 1 次提交
  29. 23 3月, 2014 1 次提交
  31. 06 3月, 2014 5 次提交
  33. 05 3月, 2014 1 次提交
  35. 18 1月, 2014 1 次提交
  37. 15 1月, 2014 2 次提交
  39. 09 1月, 2014 1 次提交
  41. 08 1月, 2014 2 次提交
  43. 07 1月, 2014 2 次提交
  45. 04 12月, 2013 2 次提交
  47. 02 12月, 2013 1 次提交
  49. 28 11月, 2013 2 次提交
    • L
      ASoC: pcm: Always honor DAI min and max sample rate constraints · 78e45c99
      由 Lars-Peter Clausen 提交于 
      snd_pcm_limit_hw_rates() will initialize the minimum and maximum sample rate for
the PCM stream based on the rates specified in the rates field. Since we call
snd_pcm_limit_hw_rates() after soc_pcm_init_runtime_hw() it will essentially
overwrite the min and max rate set in soc_pcm_init_runtime_hw(). This may cause
the minimum or maximum rate to be set to a value outside the range of one of the
components if one of the components sets either SNDRV_PCM_RATE_CONTINUOUS or
SNDRV_PCM_RATE_KNOT and the other component specified a discrete rate via
SNDRV_PCM_RATE_[0-9]* that is outside of the first component's rate range. To
fix this first calculate the minimum and maximum rates using
snd_pcm_limit_hw_rates() and then on top of that apply the contraints specified
in the snd_soc_pcm_stream structs.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NTakashi iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>
      78e45c99
    • L
      ASoC: pcm: Fix rate_max calculation · 17b6c19b
      由 Lars-Peter Clausen 提交于 
      In order to make sure that the sample rate is in the supported range of both
components the maximum rate of the card should be the minimum of the maximum
rate of each components. There is one special case to consider though, if
max_rate is set to 0 this means there is no maximum specified, so use
min_not_zero() macro which will give use the desired result.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NTakashi iwai <tiwai@suse.de>
Signed-off-by: NMark Brown <broonie@linaro.org>
      17b6c19b
  51. 24 11月, 2013 2 次提交
    • N
      ASoC: soc-pcm: move DAIs parameters cleaning into hw_free() · d3383420
      由 Nicolin Chen 提交于 
      We're now applying soc_hw_params_symmetry() to reject unmatched parameters
while we clear parameters in soc_pcm_close(). So here's a use case might be
broken by this mechanism: aplay -Dhw:0 44100.wav 48000.wav 32000.wav

In this case, we call soc_pcm_open()->soc_pcm_hw_params()->soc_pcm_hw_free()
->soc_pcm_hw_params()->soc_pcm_hw_free()->soc_pcm_close() in order. As we
only clear parameters in soc_pcm_close(). The parameters would be remained
in the system even if the playback of 44100.wav is finished.

Thus, this patch is trying to move parameters cleaning into hw_free() so that
the system can continue to serve this kind of use case.

Also, since we set them in hw_params(), it should be better to clear them in
hw_free() for symmetry.
Signed-off-by: NNicolin Chen <b42378@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
      d3383420
    • N
      ASoC: soc-pcm: add symmetry for channels and sample bits · 3635bf09
      由 Nicolin Chen 提交于 
      Some SoCs can only work in mono or stereo mode at one time. So if
we let them capture a mono stream while playing a stereo stream,
there might be a problem occur to one of these two streams: double
paced or slowed down.

In soc-pcm.c, we have soc_pcm_apply_symmetry() to apply the rate
symmetry. But we don't have one for channels.

Likewise, we can treat symmetric_rate as a solution for those SoCs
or CODECs which can not handle asymmetrical LRCLK. But it's also
impossible for them to handle asymmetrical BCLK. And accodring to
BCLK = LRCLK * channel number * slot size(fixed or sample bits),
sample bits might also be a problem if they are not using a fixed
slot size.

Thus, this patch applys symmetry for channels and sample bits.

Meanwhile, there might be a race between two substreams if starting
simultaneously. Previously, we only added warning to compalin but
still using conservative way to let it carry on. However, this patch
rejects the second stream with any unmatched parameter to make sure
the first existing stream won't be broken.
Signed-off-by: NNicolin Chen <b42378@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
      3635bf09
  53. 05 11月, 2013 1 次提交
    • N
      ASoC: Add pinctrl PM to components of active DAIs · 988e8cc4
      由 Nicolin Chen 提交于 
      It's quite popular that more drivers are using pinctrl PM, for example:
(Documentation/devicetree/bindings/arm/primecell.txt). Just like what
runtime PM does, it would deactivate and activate pin group depending
on whether it's being used or not.

And this pinctrl PM might be also beneficial to cpu dai drivers because
they might have actual pinctrl so as to sleep their pins and wake them
up as needed.

To achieve this goal, this patch sets pins to the default state during
resume or startup; While during suspend and shutdown, it would set pins
to the sleep state.

As pinctrl PM would return zero if there is no such pinctrl sleep state
settings, this patch would not break current ASoC subsystem directly.

[ However, there is still an exception that the patch can not handle,
that is, when cpu dai driver does not have pinctrl property but another
device has it. (The AUDMUX <-> SSI on Freescale i.MX6 series for example.
SSI as a cpu dai doesn't contain pinctrl property while AUDMUX, an Audio
Multiplexer, has it). In this case, this kind of cpu dai driver needs to
find a way to obtain the pinctrl property as its own, by moving property
from AUDMUX to SSI, or creating a pins link/dependency between these two
devices, or using a more decent way after we figure it out. ]
Signed-off-by: NNicolin Chen <b42378@freescale.com>
Signed-off-by: NMark Brown <broonie@linaro.org>
      988e8cc4
  55. 01 11月, 2013 1 次提交