All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH 0/7] ASoC: Merge CPU/Codec DAIs
Date: Wed, 11 Mar 2020 09:36:17 -0500	[thread overview]
Message-ID: <8e92f00a-6fb4-84e6-8e48-28b9913791c0@linux.intel.com> (raw)
In-Reply-To: <87k13rvd5g.wl-kuninori.morimoto.gx@renesas.com>



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



  reply	other threads:[~2020-03-11 14:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11  1:06 [PATCH 0/7] ASoC: Merge CPU/Codec DAIs Kuninori Morimoto
2020-03-11  1:07 ` [PATCH 1/7] ASoC: soc-core: " Kuninori Morimoto
2020-03-11  1:07 ` [PATCH 2/7] ASoC: soc-core: Merge for_each_rtd_cpu/codec_dais() Kuninori Morimoto
2020-03-11  1:07 ` [PATCH 3/7] ASoC: soc-dapm: " Kuninori Morimoto
2020-03-11  1:27   ` Sridharan, Ranjani
2020-03-11  1:30     ` Kuninori Morimoto
2020-03-11  1:07 ` [PATCH 4/7] ASoC: soc-pcm: " Kuninori Morimoto
2020-03-11  1:30   ` Sridharan, Ranjani
2020-03-11  2:06     ` Kuninori Morimoto
2020-03-11  1:07 ` [PATCH 5/7] ASoC: soc-core: Merge CPU/Codec for soc_dai_pcm_new() Kuninori Morimoto
2020-03-11  1:07 ` [PATCH 6/7] ASoC: soc-pcm: Merge CPU/Codec MSB at soc_pcm_apply_msb() Kuninori Morimoto
2020-03-11  1:07 ` [PATCH 7/7] ASoC: soc-pcm: Merge CPU/Codec at soc_pcm_pointer() Kuninori Morimoto
2020-03-11  2:00   ` Pierre-Louis Bossart
2020-03-11  2:39     ` Kuninori Morimoto
2020-03-11  1:51 ` [PATCH 0/7] ASoC: Merge CPU/Codec DAIs Pierre-Louis Bossart
2020-03-11  2:27   ` Kuninori Morimoto
2020-03-11 14:36     ` Pierre-Louis Bossart [this message]
2020-03-11 17:10       ` Mark Brown
2020-03-12  1:17         ` Kuninori Morimoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8e92f00a-6fb4-84e6-8e48-28b9913791c0@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.