On 3/10/20 9:27 PM, Kuninori Morimoto wrote:
Hi Pierre-Louis
rtd->cpu_dais = [][][][][][][][][]
rtd->codec_dais = [][][][][][][][][]
(snip)
rtd->dais = [][][][][][][][][][][][][][][][][][]
^cpu_dais ^codec_dais
|--- num_cpus ---|--- num_codecs --|
(snip)
Is the end-goal to remove the cpu_dais and codec_dais, and fold them
as non-descript 'dais'? This is what I understand by "it will be no
longer good much for modern device"
Yes. We want to have non-descript DAIs in the future.
I think this was indicated by Lars-Peter before at ELCE.
But, I think we *can't* do it right now.
Because many drivers are considering CPU and Codec separately.
Or is this 'merge' a simple data handling change to avoid using two
"for" loops instead of one, and we are going to keep the distinction
between dais?
Yes.
There are some functions which is doing something only for CPU or Codec.
This patch-set do nothing to such functions.
Maybe it can be updated in the future, maybe not (can't).
I hope this patch-set can be 1st step for non-descript DAIs.
But the main purpose of this patch so far is that
keeping current CPU / Codec DAIs method,
but, simply merge such code *if possible*.
more specifically I am concerned about the tons of code we have,
e.g. a random machine driver:
struct snd_soc_dai *codec_dai = rtd->codec_dai;
struct snd_soc_jack *jack;
int ret;
/* Configure sysclk for codec */
ret = snd_soc_dai_set_sysclk(codec_dai, DA7219_CLKSRC_MCLK,
If the rtd structure only has an array of dais, how would the codecs
be configured then?
The image is like this.
It still can use rtd->cpu_dais, rtd->codec_dais.
Of course for_each_rtd_cpu/codec_dais() macro too.
rtd->dais = [][][][][][][][][][][][][][][][][][]
^cpu_dais ^codec_dais
|--- num_cpus ---|--- num_codecs --|
rtd->cpu_dais = &rtd->dais[0];
rtd->codec_dais = &rtd->dais[dai_link->num_cpus];
So we can use/keep existing code/method same as before.
Is this good answer for you ?
Thanks for the precisions.
I have no objections to the addition of the rtd->dais, it can indeed
simplify the code by just processing all dais in the same loop.
I would still like to make sure we have an broadbrush idea of what the
2nd step might be. It seems to me it's not possible to avoid having a
notion of source/sink inside of a dailink (the wording is probably not
right e.g. for full duplex, maybe domain1/domain2 component1/component2
are more accurate). The dais are exposed by different components and are
really the hook by which the components can be configured with
compatible settings.
Thanks
-Pierre
