| Message ID | 20200114175152.3291-1-yung-chuan.liao@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: Add Multi CPU DAI support | expand |
Hi Bard > As discussed in [1], ASoC core supports multi codec DAIs > on a DAI link. However it does not do so for CPU DAIs. > > So, add support for multi CPU DAIs on a DAI Link by adding > multi CPU DAI in Card instantiation, suspend and resume > functions, PCM ops, stream handling functions and DAPM. > > [1]: https://www.spinics.net/lists/alsa-devel/msg71369.html > > changes in v2: > - rebase on asoc-next > - fix some typo > - compare and merge Kuninori Morimoto's version > - add warning if the function is not support multi cpu yet > > Bard liao (1): > ASoC: add warning if the function is not support multi cpu yet. > > Shreyas NC (3): > ASoC: Add initial support for multiple CPU DAIs > ASoC: Add multiple CPU DAI support for PCM ops > ASoC: Add multiple CPU DAI support in DAPM > > include/sound/soc.h | 15 + > sound/soc/soc-compress.c | 7 +- > sound/soc/soc-core.c | 222 ++++++----- > sound/soc/soc-dapm.c | 131 +++--- > sound/soc/soc-generic-dmaengine-pcm.c | 12 + > sound/soc/soc-pcm.c | 547 +++++++++++++++++--------- > 6 files changed, 599 insertions(+), 335 deletions(-) Thank you for merging my version !! Thank you for your help !! Best regards --- Kuninori Morimoto
On 1/14/20 11:51 AM, Bard liao wrote: > As discussed in [1], ASoC core supports multi codec DAIs > on a DAI link. However it does not do so for CPU DAIs. > > So, add support for multi CPU DAIs on a DAI Link by adding > multi CPU DAI in Card instantiation, suspend and resume > functions, PCM ops, stream handling functions and DAPM. Maybe a tangential question, but I am a bit confused on the code cleanups. After this series of patches is applied, we have this in soc.h: struct snd_soc_dai *codec_dai; struct snd_soc_dai *cpu_dai; struct snd_soc_dai **codec_dais; unsigned int num_codecs; struct snd_soc_dai **cpu_dais; unsigned int num_cpus; What is the intent behind keeping the two fields codec_dai and cpu_dai? Shouldn't we use the multi-dai structures in all cases, possible degraded to a single element rather than maintaining what looks like duplicate ways of accessing the same element? If removing these fields across all drivers is just too invasive for now, shouldn't we start defining access macros so that those fields can be deprecated and removed at a later time, platform-by-platform? Thanks -Pierre
Hi Pierre-Louis > After this series of patches is applied, we have this in soc.h: > > struct snd_soc_dai *codec_dai; > struct snd_soc_dai *cpu_dai; > > struct snd_soc_dai **codec_dais; > unsigned int num_codecs; > > struct snd_soc_dai **cpu_dais; > unsigned int num_cpus; > > What is the intent behind keeping the two fields codec_dai and cpu_dai? > > Shouldn't we use the multi-dai structures in all cases, possible > degraded to a single element rather than maintaining what looks like > duplicate ways of accessing the same element? > > If removing these fields across all drivers is just too invasive for > now, shouldn't we start defining access macros so that those fields > can be deprecated and removed at a later time, platform-by-platform? Actually, I have this patch (= remove cpu_dai/codec_dai from all drivers, and use macro for it), and have plan to post it. But, I have many extra cleanup patches in my tree, and I want to post it before that (to avoid extra re-ordering dpendency break). Thank you for your help !! Best regards --- Kuninori Morimoto
>> After this series of patches is applied, we have this in soc.h: >> >> struct snd_soc_dai *codec_dai; >> struct snd_soc_dai *cpu_dai; >> >> struct snd_soc_dai **codec_dais; >> unsigned int num_codecs; >> >> struct snd_soc_dai **cpu_dais; >> unsigned int num_cpus; >> >> What is the intent behind keeping the two fields codec_dai and cpu_dai? >> >> Shouldn't we use the multi-dai structures in all cases, possible >> degraded to a single element rather than maintaining what looks like >> duplicate ways of accessing the same element? >> >> If removing these fields across all drivers is just too invasive for >> now, shouldn't we start defining access macros so that those fields >> can be deprecated and removed at a later time, platform-by-platform? > > Actually, I have this patch (= remove cpu_dai/codec_dai from all drivers, > and use macro for it), and have plan to post it. > > But, I have many extra cleanup patches in my tree, > and I want to post it before that > (to avoid extra re-ordering dpendency break). ok, thanks for the precisions!
On 1/14/20 11:51 AM, Bard liao wrote: > As discussed in [1], ASoC core supports multi codec DAIs > on a DAI link. However it does not do so for CPU DAIs. > > So, add support for multi CPU DAIs on a DAI Link by adding > multi CPU DAI in Card instantiation, suspend and resume > functions, PCM ops, stream handling functions and DAPM. > > [1]: https://www.spinics.net/lists/alsa-devel/msg71369.html > > changes in v2: > - rebase on asoc-next > - fix some typo > - compare and merge Kuninori Morimoto's version > - add warning if the function is not support multi cpu yet I checked the code and didn't find blatant issues, except for inconsistent errors/warnings for the multi-cpu case, see other emails. Looks really good to me otherwise, thanks Bard and Morimoto-san, nice work! > > Bard liao (1): > ASoC: add warning if the function is not support multi cpu yet. > > Shreyas NC (3): > ASoC: Add initial support for multiple CPU DAIs > ASoC: Add multiple CPU DAI support for PCM ops > ASoC: Add multiple CPU DAI support in DAPM > > include/sound/soc.h | 15 + > sound/soc/soc-compress.c | 7 +- > sound/soc/soc-core.c | 222 ++++++----- > sound/soc/soc-dapm.c | 131 +++--- > sound/soc/soc-generic-dmaengine-pcm.c | 12 + > sound/soc/soc-pcm.c | 547 +++++++++++++++++--------- > 6 files changed, 599 insertions(+), 335 deletions(-) >