summaryrefslogtreecommitdiff
path: root/sound/soc/soc-pcm.c
AgeCommit message (Collapse)Author
2021-04-16ASoC: soc-pcm: ignore dummy-DAI at soc_pcm_params_symmetry()Kuninori Morimoto
soc_pcm_params_symmetry() checks CPU / Codec symmetry. Unfortunately there was bug on it (= A) which didn't check Codec. But is back by (B). A: v5.7: commit c840f7698d26 ("ASoC: soc-pcm: Merge for_each_rtd_cpu/codec_dais()") B: v5.12: commit 3a9067211122 ("ASoC: soc-pcm: cleanup soc_pcm_params_symmetry()") In total, old - v5.6 (= Generation-1): symmetric_rate : DAI_Link / CPU / Codec symmetric_channels : DAI_Link / CPU / Codec symmetric_sample_bits : DAI_Link / CPU / Codec v5.7 - v5.11 (= Generation-2): (= because of bug by (A)) symmetric_rate : DAI_Link / CPU symmetric_channels : DAI_Link / CPU / Codec symmetric_sample_bits : DAI_Link / CPU / Codec v5.12 - (= Generation-3): (= back by (B)) symmetric_rate : DAI_Link / CPU / Codec symmetric_channels : DAI_Link / CPU / Codec symmetric_sample_bits : DAI_Link / CPU / Codec OTOH, we can use DPCM which is configured by FE / BE. Both FE / BE uses dummy-DAI. FE: CPU <-> dummy-DAI BE: dummy-DAI <-> Codec One note is that we can use .be_hw_params_fixup in DPCM case. This means BE settings might be fixuped/updated by FE. This feature is used for example on MIXer case. It can be happen not only for rate, but for channels/sample_bits too. Because of these reasons, below issue happen on Generation-1 / Generation-3, if... 1) Sound Card used DPCM 2) It exchanges rate to 48kHz by using .be_hw_params_fixup() 3) Codec had symmetric_rate = 1 I didn't confirm, but maybe same things happen if it exchanged channels/sample_bits at Generation-1/2/3 too. # aplay 44100.wav # aplay 44100.wav => [kernel] be.ak4613-hifi: ASoC: unmatched rate symmetry: snd-soc-dummy-dai:44100 - soc_pcm_params_symmetry:48000 [kernel] be.ak4613-hifi: ASoC: hw_params BE failed -22 [kernel] fe.rsnd-dai.0: ASoC: hw_params BE failed -22 aplay: set_params:1407: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 44100 PERIOD_TIME: (23219 23220) PERIOD_SIZE: 1024 PERIOD_BYTES: 4096 PERIODS: 4 BUFFER_TIME: (92879 92880) BUFFER_SIZE: 4096 BUFFER_BYTES: 16384 TICK_TIME: 0 soc_pcm_params_symmetry() checks by below if (symmetry) for_each_rtd_cpu_dais(rtd, i, cpu_dai) if (cpu_dai->xxx && cpu_dai->xxx != d.xxx) { dev_err(rtd->dev, "..."); return -EINVAL; } Because of above reason 3) (= Codec had symmetric_rate = 1) BE can't ignore "if (symmetric)". At 1st aplay, soc_pcm_params_symmetry() ignores it, because dummy-DAI->rate is 0. After this check, each DAI sets/keep settings. In above sample case, BE gets 48000 and FE gets 44100, and it happen BE -> FE order. Because DPCM is sharing *same* dummy-DAI, dummy-DAI sets as 48000 by BE, and is overwrote by 44100 by FE. This settings never be cleaned (= a) after 1st aplay, because dummy-DAI is used from FE/BE, never be last user (b). static int soc_pcm_hw_clean(...) { ... for_each_rtd_dais(rtd, i, dai) { ... (b) if (snd_soc_dai_active(dai) == 1) (a) soc_pcm_set_dai_params(dai, NULL); ... } ... } At 2nd aplay, BE gets 48000 but dummy-DAI is keeping 44100, soc_pcm_params_symmetry() checks will fail. To solve this issue, this patch ignores dummy-DAI at soc_pcm_params_symmetry() Link: https://lore.kernel.org/r/87a6q0z4xt.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87y2djxa2n.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-04-16ASoC: soc-pcm: indicate DAI name if soc_pcm_params_symmetry() failedKuninori Morimoto
It indicates unmatched symmetry value, but not indicates on which DAI. This patch indicates it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/871rbbyono.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-04-16ASoC: soc-pcm: don't use "name" on __soc_pcm_params_symmetry() macroKuninori Morimoto
__soc_pcm_params_symmetry() macro is using "name" as parameter which will be exchanged to rate/channles/sample_bit, like below dai->name => dai->rate dai->name => dai->channels dai->name => dai->sample_bit But, dai itself has "name". This means 1) It is very confusable naming 2) It can't use dai->name This patch use "xxx" instead of "name" Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/8735vryoob.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-25ASoC: soc-component: Add snd_soc_pcm_component_ackShengjiu Wang
Add snd_soc_pcm_component_ack back, which can be used to get an updated buffer pointer in the platform driver. On Asymmetric multiprocessor, this pointer can be sent to Cortex-M core for audio processing. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1615516725-4975-2-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: don't indicate error message for snd_soc_[pcm_]component_xxx()Kuninori Morimoto
All snd_soc_component_xxx() and snd_soc_pcm_component_xxx() itself indicate error message if failed. Its caller doesn't need to indicate duplicated error message. This patch removes it. All snd_soc_component_xxx() indicate error message if failed. Its caller doesn't need to indicate duplicated error message. This patch removes it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/878s6puta6.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: don't indicate error message for snd_soc_[pcm_]dai_xxx()Kuninori Morimoto
All snd_soc_dai_xxx() and snd_soc_pcm_dai_xxx() itself indicate error message if failed. Its caller doesn't need to indicate duplicated error message. This patch removes it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87a6r5utaa.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: don't indicate error message for dpcm_be_dai_hw_free()Kuninori Morimoto
dpcm_be_dai_hw_free() never fail, error message is not needed. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87blblutaf.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: don't indicate error message for soc_pcm_hw_free()Kuninori Morimoto
soc_pcm_hw_free() never fail, error message is not needed. We can't use void function for it, because it is used part of struct snd_pcm_ops :: hw_free. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87czw1utaj.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at dpcm_fe/be_dai_prepare()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } This patch follow above style at dpcm_fe/be_dai_prepare() Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87eeghutap.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at dpcm_fe/be_dai_hw_params()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } This patch follow above style at dpcm_fe/be_dai_hw_params() Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87ft0xutat.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at dpcm_fe/be_dai_startup()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } This patch follow above style at dpcm_fe/be_dai_startup(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87h7ldutay.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at dpcm_run_update_startup/shutdown()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } This patch also do below to dpcm_run_update_startup() 1) remove duplicated ret = -EINVAL 2) remove blank line do below to dpcm_run_update_shutdown() 1) remove unused ret Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87im5tutb3.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at dpcm_apply_symmetry()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } This patch follow above style at dpcm_apply_symmetry(...) Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87k0q9utb9.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at dpcm_be_dai_trigger()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } Now, dpcm_be_dai_trigger() user uses it like below. err = dpcm_be_dai_trigger(...); if (err < 0) dev_err(..., "ASoC: trigger FE failed %d\n", err); But we can get more detail information if dpcm_be_dai_trigger() itself had dev_err(). And above error message is confusable, failed is *BE*, not *FE*. This patch indicates error message at dpcm_be_dai_trigger(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87lfaputbe.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at dpcm_path_get()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } Now, many place uses dpcm_path_get() like below ret = dpcm_path_get(...); if (ret < 0) goto error; (A) else if (ret == 0) dev_dbg(...) But here, (A) part can be indicated at dpcm_path_get() not caller. It is simple and readable code. This patch do it. Small detail behaviors will be exchanged by this patch. 1) indicates debug info (= path numbers) if path > 0 case only (It was *always* indicated). 2) soc_dpcm_fe_runtime_update() is indicating error message for paths < 0 case, but it is already done at dpcm_path_get(). Thus just remove it. but dev_dbg() vs dev_warn() is exchanged. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87mtv5utbj.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at soc_pcm_prepare()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } This patch follow above style at soc_pcm_prepare(). By this patch, dpcm_fe/be_dai_prepare(...) temporary lacks FE/BE error info, but it will reborn soon. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87o8flutbn.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at soc_pcm_hw_params()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } This patch follow above style at soc_pcm_hw_params(). By this patch, dpcm_fe/be_dai_hw_params(...) temporary lacks FE/BE error info, but it will reborn soon. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87pn01utbt.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-19ASoC: soc-pcm: indicate error message at soc_pcm_open()Kuninori Morimoto
Indicating error message when failed case is very useful for debuging. In many case, its style is like below. int function(...) { ... return ret; } int caller(...) { ... ret = function(...); if (ret < 0) dev_err(...) ... } This is not so bad, but in this style *each caller* needs to indicate duplicate same error message, and some caller is forgetting to do it. And caller can't indicate detail function() error information. If function() indicates error message, we can get same and detail information without forgot. int function(...) { ... if (ret < 0) dev_err(...) return ret; } int caller(...) { ... ret = function(...); ... } This patch follow above style at soc_pcm_open(). By this patch, dpcm_fe/be_dai_startup(...) temporary lacks FE/BE error info, but it will reborn soon. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87r1khutby.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-12ASoC: soc-pcm: share DPCM BE DAI stop operationKuninori Morimoto
soc-pcm has very similar but different DPCM BE DAI stop operation at 1) dpcm_be_dai_startup() error case rollback 2) dpcm_be_dai_startup_unwind() 3) dpcm_be_dai_shutdown() The differences are 1) for rollback 2) Doesn't check by snd_soc_dpcm_be_can_update() (Is this bug ?) 3) Do soc_pcm_hw_free() if it was not !OPENed and !HW_FREEed, and call soc_pcm_close(). We can share same code by 1) hw_free is not needed. Needs last dpcm as rollback. 2) hw_free is not needed. 3) hw_free is needed. This patch adds new dpcm_be_dai_stop() and share these 3. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87a6rduoam.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-12ASoC: soc-pcm: remove unneeded !rtd->dai_link checkKuninori Morimoto
rtd->dai_link is setuped at soc_new_pcm_runtime(), thus "rtd->dai_link == NULL" is never happen. This patch removes unneeded !rtd->dai_link check Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87blbtuoar.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-12ASoC: soc-pcm: fixup dpcm_be_dai_startup() user countKuninori Morimoto
At dpcm_be_dai_startup_unwind(), it indicates error message at (1) if this function was called with no users. But, it doesn't use "continue" here. Thus, users will be a negative number at (2) void dpcm_be_dai_startup_unwind(...) { ... for_each_dpcm_be(...) { ... (1) if (be->dpcm[stream].users == 0) dev_err(...); (2) if (--be->dpcm[stream].users != 0) continue; At dpcm_be_dai_startup(), it indicates error message if user reached to MAX USERS at (A). But, it doesn't use "continue" here. Thus, it will be over MAX USERS at (B). int dpcm_be_dai_startup(...) { ... for_each_dpcm_be(...) { ... (A) if (be->dpcm[stream].users == DPCM_MAX_BE_USERS) dev_err(...); (B) if (be->dpcm[stream].users++ != 0) continue; These are just bug. This patch fixup these. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87czw9uoav.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-12ASoC: soc-pcm: add soc_hw_sanity_check()Kuninori Morimoto
Current soc_pcm_open() is checking runtime->hw parameters, but having such function is very helpful for reading code. This patch adds new soc_hw_sanity_check() and checks runtime->hw parameters there. And print its debug message there, too. Debug message print out timing is exchanged after this patch, but it is not a big deal, because it is for debug. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87eegpuob1.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-12ASoC: soc-pcm: add soc_pcm_update_symmetry()Kuninori Morimoto
Current soc-pcm has soc_pcm_has_symmetry() and using it as if (soc_pcm_has_symmetry(substream)) substream->runtime->hw.info |= SNDRV_PCM_INFO_JOINT_DUPLEX; We want to share same operation as same function. This patch adds soc_pcm_update_symmetry() and pack above code in one function. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87ft15uob6.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-12ASoC: soc-pcm: direct copy at snd_soc_set_runtime_hwparams()Kuninori Morimoto
snd_soc_set_runtime_hwparams() is called from each driver to initialize hw parameters, but coping each parameters one-by-one. Current code is not copying all parameters, but no big effect if we do it. This patch copies all parameters by simple code. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87h7lluoba.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-12ASoC: soc-pcm: add soc_cpu/codec_dai_name() macroKuninori Morimoto
soc-pcm needs DAI name and it will be "multicpu/multicodec" if it has many DAIs. But current code is using very verbose for it. This patch uses macro and makes code simple. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87im61uobf.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-12ASoC: soc-pcm: check DAI activity under soc_pcm_apply_symmetry()Kuninori Morimoto
soc_pcm_apply_symmetry() is used like below in all cases. if (snd_soc_dai_active(dai)) { err = soc_pcm_apply_symmetry(fe_substream, dai); ... } Because of this style, the code is deep nested. This patch checks it under soc_pcm_apply_symmetry(), and makes code simple. static int soc_pcm_apply_symmetry(...) { ... => if (!snd_soc_dai_active(...)) return 0; ... } => ret = soc_pcm_apply_symmetry(); if (ret < 0) ... Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87k0qhuobl.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10Merge series "ASoC: core: remove cppcheck warnings" from Pierre-Louis ↵Mark Brown
Bossart <pierre-louis.bossart@linux.intel.com>: This is the first batch of cleanups to make cppcheck more usable, currently we have way too many warnings that drown real issues. Pierre-Louis Bossart (6): ASoC: soc-ops: remove useless assignment ASoC: soc-pcm: remove redundant assignment ASoC: soc-pcm: remove shadowing variable ASoC: soc-pcm: add error log ASoC: soc-topology: clarify expression ASoC: generic: simple-card-utils: remove useless assignment sound/soc/generic/simple-card-utils.c | 2 +- sound/soc/soc-ops.c | 2 +- sound/soc/soc-pcm.c | 4 ++-- sound/soc/soc-topology.c | 16 ++++++++-------- 4 files changed, 12 insertions(+), 12 deletions(-) -- 2.25.1
2021-03-10ASoC: soc-pcm: add error logPierre-Louis Bossart
cppcheck warning: sound/soc/soc-pcm.c:1907:6: style: Variable 'err' is assigned a value that is never used. [unreadVariable] err = dpcm_be_dai_hw_free(fe, stream); ^ it's not clear why dpcm_be_dai_hw_free() is sometimes called without testing the error status, and sometimes an error message is provided. When in doubt, add an error message for consistency. This may have to be revisited. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210218221921.88991-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: soc-pcm: remove shadowing variablePierre-Louis Bossart
cppcheck warning: sound/soc/soc-pcm.c:1718:7: style: Local variable 'i' shadows outer variable [shadowVariable] int i; ^ sound/soc/soc-pcm.c:1696:6: note: Shadowed declaration int i; ^ sound/soc/soc-pcm.c:1718:7: note: Shadow variable int i; ^ the second variable seems totally unnecessary. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210218221921.88991-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: soc-pcm: remove redundant assignmentPierre-Louis Bossart
cppcheck warning: sound/soc/soc-pcm.c:2398:7: style: Variable 'ret' is reassigned a value before the old one has been used. [redundantAssignment] ret = -EINVAL; ^ sound/soc/soc-pcm.c:2395:7: note: ret is assigned ret = -EINVAL; ^ sound/soc/soc-pcm.c:2398:7: note: ret is overwritten ret = -EINVAL; ^ This looks like a copy/paste or git merge issue. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210218221921.88991-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: soc-pcm: unpack dpcm_set_fe_runtime()Kuninori Morimoto
dpcm_fe_dai_startup() (= A) calls dpcm_set_fe_runtime() (= B) to setup DPCM runtime. From *naming point of view*, it sounds like setup function for FE. (A) static int dpcm_fe_dai_startup(...) { ... (B) dpcm_set_fe_runtime(...); ... } But in dpcm_set_fe_runtime() (= B), It setups FE by dpcm_runtime_setup_fe() (= X), and setups BE by dpcm_runtime_merge_xxx() (= Y). (B) static void dpcm_set_fe_runtime(...) { ... (X) dpcm_runtime_setup_fe(...); ^ dpcm_runtime_setup_be_format(...); (Y) dpcm_runtime_setup_be_chan(...); v dpcm_runtime_setup_be_rate(...); } These means that the function which is called as xxx_fe_xxx() is setups both FE and BE. This is confusable and can be hot bed for bug. Now dpcm_set_fe_runtime() (= B) is simple enough and confusable naming, let's unpack it at dpcm_fe_dai_startup(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87mtvxvsgn.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: soc-pcm: add dpcm_runtime_setup()Kuninori Morimoto
dpcm_fe_dai_startup() (= A) calls dpcm_set_fe_runtime() (= B) to setup DPCM runtime. From *naming point of view*, it sounds like setup function for FE. (A) static int dpcm_fe_dai_startup(...) { ... (B) dpcm_set_fe_runtime(...); ... } But in dpcm_set_fe_runtime() (= B), It setups FE by dpcm_runtime_setup_fe() (= X), and setups BE by dpcm_runtime_merge_xxx() (= Y). (B) static void dpcm_set_fe_runtime(...) { ... (X) dpcm_runtime_setup_fe(...); ^ dpcm_runtime_merge_format(...); (Y) dpcm_runtime_merge_chan(...); v dpcm_runtime_merge_rate(...); } These means that the function which is called as xxx_fe_xxx() is setups both FE and BE. This is confusable and can be hot bed for bug. This patch renames unclear dpcm_runtime_merge_xxx() (= Y) to more clear dpcm_runtime_setup_be_xxx(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87o8gdvsgr.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: soc-pcm: add dpcm_runtime_setup_fe()Kuninori Morimoto
dpcm_fe_dai_startup() (= A) calls dpcm_set_fe_runtime() (= B) to setup DPCM runtime. From *naming point of view*, it sounds like setup function for FE. (A) static int dpcm_fe_dai_startup(...) { ... (B) dpcm_set_fe_runtime(...); ... } But in dpcm_set_fe_runtime() (= B), It setups FE by for_each loop (= X), and setups BE by dpcm_runtime_merge_xxx() (= Y). (B) static void dpcm_set_fe_runtime(...) { ... ^ for_each_rtd_cpu_dais(...) { | ... (X) soc_pcm_hw_update_rate(...); | soc_pcm_hw_update_chan(...); | soc_pcm_hw_update_format(...); v } ^ dpcm_runtime_merge_format(...); (Y) dpcm_runtime_merge_chan(...); v dpcm_runtime_merge_rate(...); } These means that the function which is called as xxx_fe_xxx() is setups both FE and BE. This is confusable and can be hot bed for bug. To tidyup it, as 1st step, this patch adds new dpcm_runtime_setup_fe() for (X). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87pn0tvsgx.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: soc-pcm: unpack dpcm_init_runtime_hw()Kuninori Morimoto
dpcm_init_runtime_hw() is now just verbose function. This patch unpacks it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87r1l9vsh4.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: soc-pcm: remove strange format storingKuninori Morimoto
dpcm_init_runtime_hw() (= A) is used from dpcm_set_fe_runtime() (= B) with for_each_rtd_cpu_dais() loop (= C), and it checks formats (= D). (A) static void dpcm_init_runtime_hw(...) { ... ^ if (runtime->hw.formats) | (D1) runtime->hw.formats &= stream->formats; (D) else | (D2) runtime->hw.formats = stream->formats; v } (B) static void dpcm_set_fe_runtime(...) { ... (C) for_each_rtd_cpu_dais(rtd, i, cpu_dai) { ... (A) dpcm_init_runtime_hw(...); } } If this for_each_rtd_cpu_dais() loop (= C) calls dpcm_init_runtime_hw() (= A) multiple times, this means it is Multi-CPU. If we focus to format operation at (D), using mask (= D1) is understandable because it restricts unsupported format. But, enabling format when zero format case (= D2) is very strange, because it might enables unsupported format. This runtime->hw.formats is initialized by ULLONG_MAX at soc_pcm_hw_init(), thus becoming zero format means it can't use such format. And doing this strange format operation is only here. This patch removes strange format operation (= D2), and use standard soc_pcm_hw_update_format() for it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87sg5pvshq.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-17ASoC: soc-pcm: fix hw param limits calculation for multi-DAIKai Vehmanen
In case DPCM runtime has multiple CPU DAIs, dpcm_init_runtime_hw() is called multiple times, once for each CPU DAI. This will lead to ignoring hw limits of all but the last DAI. Fix this by moving soc_pcm_hw_init() up by one level to dpcm_init_runtime_hw(). Fixes: 140f553d1298 ("ASoC: soc-pcm: fix hwparams min/max init for dpcm") Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20210216172251.3023723-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-15ASoC: soc-pcm: fix hwparams min/max init for dpcmKai Vehmanen
When runtime is initialized with dpcm_init_runtime_hw(), some of the min/max calculations assume that defaults are set. For example calculation of channel min/max values may be done using zero-initialized data and soc_pcm_hw_update_chan() will always return max-channels of 0 in this case. This will result in failure to open the PCM at all. Fix the issue by calling soc_pcm_hw_init() before calling any soc_pcm_hw_update_*() functions. Remove the conditional code on runtime->hw.formats as this field is anyways set in soc_pcm_hw_init(). Fixes: 6cb56a4549e9 ("ASoC: soc-pcm: add soc_pcm_hw_update_chan()") Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20210214220414.2876690-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-12ASoC: soc-pcm: add soc_pcm_hw_update_format()Kuninori Morimoto
We have soc_pcm_hw_update_xxx() now. This patch creates same function for format. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/87pn1g90oa.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-12ASoC: soc-pcm: add soc_pcm_hw_update_chan()Kuninori Morimoto
We have soc_pcm_hw_update_rate() now. This patch creates same function for chan. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/87r1lw90oo.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-12ASoC: soc-pcm: add soc_pcm_hw_update_rate()Kuninori Morimoto
To update hw, we need to follow setting order 1) set hw->rates 2) call snd_pcm_limit_hw_rates() 3) update hw->rate_min/max To avoid random settings, this patch adds new soc_pcm_hw_update_rate() and share updating code. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/87sg6c90qv.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-10ASoC: soc-pcm: change error message to debug messageShengjiu Wang
This log message should be a debug message, because it doesn't return directly but continue next loop. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/1612771965-5776-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-03ASoC: soc-pcm: fixup snd_pcm_limit_hw_rates() timingKuninori Morimoto
soc-pcm has snd_pcm_limit_hw_rates() which determine rate_min/rate_max. It updates runtime->hw.rate_min/max (A) based on hw->rates (B). int snd_pcm_limit_hw_rates(...) { int i; for (...) { (B) if (runtime->hw.rates & (1 << i)) { (A) runtime->hw.rate_min = ... break; } } for (...) { (B) if (runtime->hw.rates & (1 << i)) { (A) runtime->hw.rate_max = ... break; } } return 0; } This means, setup order is 1) set hw->rates 2) call snd_pcm_limit_hw_rates() 3) update hw->rate_min/max soc_pcm_init_runtime_hw() is calling it in good order static void soc_pcm_init_runtime_hw(xxx) { ... 1) hw->rates = snd_pcm_rate_mask_intersect(...); 2) snd_pcm_limit_hw_rates(...); 3) hw->rate_min = max(...); hw->rate_min = max(...); hw->rate_max = min_not_zero(...); hw->rate_max = min_not_zero(...); } But, dpcm_fe_dai_startup() is not. static int dpcm_fe_dai_startup(xxx) { ... 1) 3) dpcm_set_fe_runtime(...); 2) snd_pcm_limit_hw_rates(...); ... } More detail of dpcm_set_fe_runtime() is static void dpcm_set_fe_runtime() { ... for_each_rtd_cpu_dais(rtd, i, cpu_dai) { ... 3) 1) dpcm_init_runtime_hw(...); } ... 3) 1) dpcm_runtime_merge_rate(...); } This patch fixup these into static void dpcm_set_fe_runtime() { ... for_each_rtd_cpu_dais(rtd, i, cpu_dai) { ... 1) 2) 3) dpcm_init_runtime_hw(...); } ... 1) 2) 3) dpcm_runtime_merge_rate(...); } static int dpcm_fe_dai_startup(xxx) { ... dpcm_set_fe_runtime(...); - snd_pcm_limit_hw_rates(...); ... } Link: https://lore.kernel.org/r/87k15l7ewd.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/8735ytaig8.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-03ASoC: soc-pcm: use snd_pcm_hardware at dpcm_runtime_merge_xxx()Kuninori Morimoto
soc-pcm has dpcm_runtime_merge_xxx() functions, but uses parameters are very verbose. dpcm_runtime_merge_format(..., &runtime->hw.formats); dpcm_runtime_merge_chan(..., &runtime->hw.channels_min, &runtime->hw.channels_max); dpcm_runtime_merge_rate(..., &runtime->hw.rates, &runtime->hw.rate_min, &runtime->hw.rate_max); We want to replace it into dpcm_runtime_merge_format(..., runtime); dpcm_runtime_merge_chan(..., runtime); dpcm_runtime_merge_rate(..., runtime); This patch do it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/874kj9aigd.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-03ASoC: soc-pcm: add soc_create_pcm() and simplify soc_new_pcm()Kuninori Morimoto
soc_new_pcm() implementation is very long / verbose / complex, thus, it is very difficult to read. If we read it carefully, we can notice that it is consisted by int soc_new_pcm(...) { (1) judging playback/caputre part (2) creating the PCM part (3) setup pcm/rtd part } This patch adds new soc_create_pcm() for (2) part and offload it from snd_pcm_new(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/875z3paigi.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-03ASoC: soc-pcm: add soc_get_playback_capture() and simplify soc_new_pcm()Kuninori Morimoto
soc_new_pcm() implementation is very long / verbose / complex, thus, it is very difficult to read. If we read it carefully, we can notice that it is consisted by int soc_new_pcm(...) { (1) judging playback/caputre part (2) creating the PCM part (3) setup pcm/rtd part } This patch adds new soc_get_playback_capture() for (1) part and offload it from soc_new_pcm(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/877do5aign.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-03ASoC: soc-pcm: tidyup pcm settingKuninori Morimoto
Current soc_new_pcm() setups pcm randomly. This patch tidyup it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/878s8laigt.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-21ASoC: soc-pcm: cleanup soc_pcm_params_symmetry()Kuninori Morimoto
soc_pcm_params_symmetry() checks rate/channel/sample_bits state. These are very similar but different, thus, it needs to have very verbose code. This patch use macro for it and make code more simple. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/878s8un6si.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-21ASoC: soc-pcm: cleanup soc_pcm_apply_symmetry()Kuninori Morimoto
soc_pcm_apply_symmetry() want to call snd_pcm_hw_constraint_single() for rate/channel/sample_bits, but, it needs many condition checks. These are very similar but different, thus, it needs to have very verbose code. This patch use macro for it and make code more simple. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87a6tan6sm.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-21ASoC: sync parameter naming : rate / sample_bitsKuninori Morimoto
snd_pcm_runtime / snd_soc_dai / snd_soc_dai_driver / snd_soc_dai_link have related parameter which is similar but not same naming. struct snd_pcm_runtime { ... (A) unsigned int rate; ... (B) unsigned int sample_bits; ... }; struct snd_soc_dai { ... (A) unsigned int rate; (B) unsigned int sample_bits; ... }; struct snd_soc_dai_driver { ... (A) unsigned int symmetric_rates:1; (B) unsigned int symmetric_samplebits:1; ... }; struct snd_soc_dai_link { ... (A) unsigned int symmetric_rates:1; (B) unsigned int symmetric_samplebits:1; ... }; Because it is similar but not same naming rule, code can be verbose / can't share macro. This patch sync naming rule for framework. - xxx_rates; + xxx_rate; - xxx_samplebits; + xxx_sample_bits; old name will be removed if all drivers were switched to new naming rule. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87wnweolj6.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-21ASoC: soc-pcm: revert soc_pcm_apply_symmetry()Kuninori Morimoto
commit a39748d03cbc ("ASoC: soc-pcm: cleanup soc_pcm_apply_symmetry()") was applied by miscommunication. To more cleanup code, and to be easy review, this patch reverts it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87y2guoljm.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>