> >>>DAPM handles DAIs during soc_dapm_stream_event() and during addition
> >>>and creation of DAI widgets i.e., dapm_add_valid_dai_widget() and
> >>>dapm_connect_dai_link_widgets().
> >>can you split this patch in two, one where you add
> >>dapm_add_valid_dai_widget() and the second one where you add the multi-cpu
> >>stuff? the current diff format is really hard to read with the two changes
> >>lumped together.
> >
> >As I had replied earlier, the change is really moving the same code from one
> >function to a new one. So, a patch split would mean we would have the same
> >duplicated code in one patch which surely is not desirable.
>
> I don't understand your answer. It's fine to have a small preparation patch
> that just moves one piece of code to another function, and they change how
> that function is called.
>
Ok, I will give it a try :)
> >I just realized that in my earlier reply I had excluded the list and replied
> >only to you :)
> >
> >>
> >>>+ for (i = 0; i < rtd->num_codecs; i++) {
> >>>+ struct snd_soc_dai *codec_dai = rtd->codec_dais[i];
> >>>+
> >>>+ for (j = 0; j < rtd->num_cpu_dai; j++) {
> >>>+ cpu_dai = rtd->cpu_dais[j];
> >>>+
> >>>+ dapm_add_valid_dai_widget(card, rtd,
> >>>+ codec_dai, cpu_dai);
> >>
> >>I didn't click on this earlier, but what makes you think all codec_dais are
> >>connected to all cpu_dais?
> >
> >Yes, there need not be a M:N connectivity. But, how do you find that out ?
> >
> >>That doesn't seem quite right.
> >>For the multi-codec case, all the codec_dais hang from a single cpu_dai.
> >>it's a stretch for me to have a full M:N connectivity. And that's clearly
> >>not the case for SoundWire stream in the multi-link case.
> >
> >I mostly do not disagree with you here..
> >
> >>Can't we use the dai_link information here to only connect cpu_ and
> >>codec_dais that are related?
> >
> >Which DAI Link information are you referring to here ?
> >Other than the machine driver which sets the audio route, I am unable to
> >figure out how we will find out the connected cpu_dai and codec_dais at
> >ASoC core level.
> >
> >May be I am missing something :(
>
> How is it different from the multi-codec support? You must have a
> description somewhere that tells you how the cpu_dai is connected to various
> codec_dais.
>
No, there is no such description that I could find.
My reference was skl_nau88l25_ssm4567.c machine driver:
/* Back End DAI links */
{
/* SSP0 - Codec */
.name = "SSP0-Codec",
.id = 0,
.cpu_dai_name = "SSP0 Pin",
.platform_name = "0000:00:1f.3",
.no_pcm = 1,
.codecs = ssm4567_codec_components,
.num_codecs = ARRAY_SIZE(ssm4567_codec_components),
..
},
The only way I could infer the connection was from DAPM route:
{
/* CODEC BE connections */
{ "Left Playback", NULL, "ssp0 Tx"},
{ "Right Playback", NULL, "ssp0 Tx"},
{ "ssp0 Tx", NULL, "codec0_out"},
}
> Maybe we should start with the examples you provided for Soundwire and
> describe how the dailinks would be represented.
>
Ok , sure. Let me describe a case where we would want to play a 2 ch stream
and we have two Masters "int-sdw.1" and "int-sdw.2"
So, DAI Link would look this way:
Here I specify the multi CPU DAIs
static struct snd_soc_dai_link_component sdw_multi_cpu_comp[] = {
{ /* Left */
.name = "int-sdw.1",
.dai_name = "SDW1 Pin0",
},
{ /* Right */
.name = "int-sdw.2",
.dai_name = "SDW2 Pin0",
},
};
static struct snd_soc_codec_conf rt700_codec_conf[] = {
{
.dev_name = "sdw:1:25d:700:0:0",
.name_prefix = "Left",
},
{
.dev_name = "sdw:2:25d:701:0:0",
.name_prefix = "Right",
},
};
And the DAI Link as:
struct snd_soc_dai_link cnl_rt700_msic_dailink[] = {
{
...
{
.name = "SDW0-Codec",
.cpu_dai = sdw_multi_cpu_comp,
.num_cpu_dai = ARRAY_SIZE(sdw_multi_cpu_comp),
.platform_name = "0000:00:1f.3",
.codecs = sdw_multi_codec_comp,
.num_codecs = ARRAY_SIZE(sdw_multi_codec_comp),
..
},
}
And it is in the DAPM route that I would specify :
{
...
{ "Left DP1 Playback", NULL, "SDW1 Tx0"},
{ "SDW1 Tx0", NULL, "codec0_out"},
{ "Right DP1 Playback", NULL, "SDW2 Tx0"},
{ "SDW2 Tx0", NULL, "codec0_out"},
...
}
> With the M:N connectivity you'd end-up having spurious events with
> non-existent connections, it's not necessarily fatal but certainly not
> elegant and may or may not work depending on state management in codec
> drivers.
>
What are the events that you are referring to here?
The reason I ask that is because my understanding is that we will get these
events only for those widgets marked connected by DAPM after parsing the DAPM
route map.
I will check further if you can let me know of the events you are suspecting
:)
Sorry for the longish mail. I thought it would be better to put in the
details rather than go back and forth over them :)
--Shreyas
>
--
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
