* [alsa-devel] simple-card: DAI link creation
@ 2020-01-16 21:34 Daniel Baluta
2020-01-17 1:14 ` Kuninori Morimoto
0 siblings, 1 reply; 2+ messages in thread
From: Daniel Baluta @ 2020-01-16 21:34 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Linux-ALSA, Pierre-Louis Bossart
Hello Morimoto-san,
I want to know your opinion on enhancing simple-card in order to be
able to create
more flexible links.
So far, simple-card allows the following cases:
1) normal sound
all DAIs are detected as CPU - Codec (+optional platform).
2) DPCM sound
2a) all CPUs are detected CPU - <dummy_codec> [FE]
2b) all codecs are detected <dummy_cpu> - codec [BE]
I will need to have a third case where I need to create
a back end link like this:
link->cpus->of_node = <&my_dai>;
link->codecs->of_node = <&my_codec>;
link->platforms->of_node = <&my_platform>;
link->no_pcm = 1;
Somehow, similar with qcom_snd_parse_of from
sound/soc/qcom/common.c.
Do you think it would be OK to create another file to handle this case
in sound/soc/generic?
Also, I would really like one day to really understand the role
of cpu/platform/codec for a FE/BE.
In the case of the FE:
- cpu dai
- platform
- codec, here it makes sense to be dummy codec.
In the case of BE:
- cpu_dai
- platform
- codec, here it make sense to be reference to a real codec
In the case of normal link:
- cpu_dai, here it makes sense is a physical DAI
- platform
- codec, here it makes sense it is a physical codec.
thanks,
Daniel.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [alsa-devel] simple-card: DAI link creation
2020-01-16 21:34 [alsa-devel] simple-card: DAI link creation Daniel Baluta
@ 2020-01-17 1:14 ` Kuninori Morimoto
0 siblings, 0 replies; 2+ messages in thread
From: Kuninori Morimoto @ 2020-01-17 1:14 UTC (permalink / raw)
To: Daniel Baluta; +Cc: Linux-ALSA, Pierre-Louis Bossart
Hi Daniel
Thank you for contacting me
> link->cpus->of_node = <&my_dai>;
> link->codecs->of_node = <&my_codec>;
> link->platforms->of_node = <&my_platform>;
> link->no_pcm = 1;
>
> Somehow, similar with qcom_snd_parse_of from
> sound/soc/qcom/common.c.
>
> Do you think it would be OK to create another file to handle this case
> in sound/soc/generic?
Or having extra flag for it ?
static const struct of_device_id simple_of_match[] = {
{ .compatible = "simple-audio-card", },
{ .compatible = "simple-scu-audio-card",
.data = (void *)DPCM_SELECTABLE },
+ { .compatible = "simple-xxx-audio-card",
+ .data = (void *)DPCM_WITH_PLATFORM },
{},
};
This idea is adding new feature on simple-card.
But, in sound card case, many patterns exist,
thus, adding new feature into simple-card will be difficult.
So having new file is not bad idea.
But, I'm thinking some Card driver want to create new driver,
but want to share simple-card code.
Actually, simple-card-utils.c is for it.
But, maybe someone want to share simple-card.c code itself ?
Some overwrite technic can be nice idea.
# Now I'm focusing cleanup ALSA SoC
# Current framework has "normal sound" and "DPCM sound",
# and it makes code/DT difficult.
# But if all cleanup could be done, these can be merged,
# and can have more flexible connection.
# Then, I want to create new simple-card with *really* simple code :)
Thank you for your help !!
Best regards
---
Kuninori Morimoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-01-17 1:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-16 21:34 [alsa-devel] simple-card: DAI link creation Daniel Baluta
2020-01-17 1:14 ` Kuninori Morimoto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).