All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
To: Mark Brown <broonie@kernel.org>
Cc: Cezary Rojewski <cezary.rojewski@intel.com>,
	Linux-ALSA <alsa-devel@alsa-project.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: About Cleanup ASoC
Date: Tue, 24 May 2022 04:40:24 +0000	[thread overview]
Message-ID: <87fskz5yrr.wl-kuninori.morimoto.gx@renesas.com> (raw)


Hi ASoC
Cc Mark, Pierre-Louis, Cezary

I have very interesting to clean up ASoC.
I think it is still very complex, thus, non flexible.
I'm thinking that we want to cleanup...

	- Component with multi Card connection
	- fixed playback vs capture
	- fixed CPU vs Codec
	- DPCM connection vs normal connection

About first topic,
I guess the biggest reason why we have limitation is
its connections. Text based image is a little bit difficult,
but if my understanding was correct, current connections are...


	card <-> rtd <-> rtd <-> rtd <-> ...
	 |        |
	 +--------|-----+---------------+-----------+ (A)
	          |     |               |           |
	          +-> component ->  component -> component -> ...
		  |    (CPU)         (Codec)     (Platform)
		  |    |      |      |      |
	          +-> dai -> dai -> dai -> dai -> ...

Card has "component list", and Component has pointer to Card (A).
This makes the limitation which blocking multiple Card connections, I think.

One note here is that "Platform" doesn't have "DAI".

So if rtd have something other connector list, let's say "ep" list here for now,
instead of "dai", and remove Card <-> Component connection,
I think the connection can be simple, and the issue can be gone,
but what do you think ?

	card <-> rtd <-> rtd <-> rtd <-> ...
	          |
		  |   dai    dai    dai    dai
		  |    |      |      |      |
	          +--> ep --> ep --> ep -> ep -> ep -> ...
	               |      |      |      |     |
	              component     component   component
		       (CPU)         (Codec)    (Platform)

Here, ep is like this

	struct rtd_entry_point {
		struct list_head list;  // list for rtd
		struct struct snd_soc_pcm_runtime *rtd;
		struct snd_soc_component *component;
		struct snd_soc_dai *dai;
	};

Current for_each_xxx() can be like this

	for_each_rtd_components()  = for_each_rtd_ep() + ep_to_component()
	for_each_rtd_dais()        = for_each_rtd_ep() + ep_to_dai()
	for_each_card_components() = for_each_card_rtds() + for_each_rtd_components()

I guess Component can have multiple Card connection on this idea,
but what do you think ?

Maybe I'm misunderstanding and/or missing something, because ASoC
is complex enough :)
Please let me know if I was misunderstanding or missing.

Thank you for your help !!

Best regards
---
Kuninori Morimoto

             reply	other threads:[~2022-05-24  4:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-24  4:40 Kuninori Morimoto [this message]
2022-05-24 11:17 ` About Cleanup ASoC Amadeusz Sławiński
2022-05-24 14:53   ` Cezary Rojewski
2022-05-25  2:54     ` Kuninori Morimoto
2022-05-25 16:11       ` Pierre-Louis Bossart
2022-05-26  2:13         ` Kuninori Morimoto
2022-05-26  9:57           ` Amadeusz Sławiński
2022-05-26 13:48             ` Pierre-Louis Bossart
2022-05-26 13:58               ` Mark Brown
2022-05-26 14:17               ` Cezary Rojewski
2022-05-26 14:45                 ` Pierre-Louis Bossart
2022-05-27  6:50                   ` Kuninori Morimoto
2022-05-31 12:25                     ` Mark Brown
2022-06-01  6:13                       ` Kuninori Morimoto
2022-06-02  9:26                     ` Cezary Rojewski
2022-06-02 23:57                       ` Kuninori Morimoto
2022-06-07  7:46                         ` Cezary Rojewski
2022-06-09  0:07                           ` Kuninori Morimoto
2022-05-27  8:38                   ` Cezary Rojewski
2022-05-31 14:37                     ` Pierre-Louis Bossart
2022-05-24 13:24 ` Mark Brown
2022-05-24 15:06   ` Cezary Rojewski
2022-05-24 16:11     ` Pierre-Louis Bossart
2022-05-25  3:02       ` 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=87fskz5yrr.wl-kuninori.morimoto.gx@renesas.com \
    --to=kuninori.morimoto.gx@renesas.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=pierre-louis.bossart@linux.intel.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.