All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Mark Brown <broonie@kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	linux-sound@vger.kernel.org
Subject: Re: About component->card
Date: Wed, 17 Dec 2025 09:30:32 +0100	[thread overview]
Message-ID: <874ippecif.wl-tiwai@suse.de> (raw)
In-Reply-To: <87v7i5esrk.wl-kuninori.morimoto.gx@renesas.com>

On Wed, 17 Dec 2025 03:39:27 +0100,
Kuninori Morimoto wrote:
> 
> 
> Hi Mark, Lars-Peter
> 
> I would like to confirm/suggest about restriction of component->card.
> See also this commit
> 
> 	45655ec69cb954d7fa594054bec33d6d5b99f8d5
> 	("ASoC: soc-core.c: enable multi Component")
> 
> We might have complex system, like this
> 
> 	+-- Basic Board ---------+
> 	|+--------+      +------+|
> 	|| CPU ch0| <--> |CodecA||
> 	||     ch1| <-+  +------+|
> 	|+--------+   |          |
> 	+-------------|----------+
> 	+-- expansion board -----+
> 	|             |  +------+|
> 	|             +->|CodecB||
> 	|                +------+|
> 	+------------------------+
> 
> We would like to implement it as below, it is intuitive.
> This means 1 Component connects to multi Cards.
> 
> 	 +-driver------+
> 	 |+-component-+|
> 	+-card0-------------------------+
> 	|||           || +-driver------+|
> 	|||           || |+-component-+||
> 	|||    ch0 dai|<=>|dai        |||
> 	|||           || |+-----------+||
> 	|||           || +-------------+|
> 	+-------------------------------+
> 	 ||           ||
> 	+-card1-------------------------+
> 	|||           || +-driver------+|
> 	|||           || |+-component-+||
> 	|||    ch1 dai|<=>|dai        |||
> 	|||           || |+-----------+||
> 	|||           || +-------------+|
> 	+-------------------------------+
> 	 |+-----------+|
> 	 +-------------+
> 
> But, we can't this today, beucase we have restriction (A) that 1 Component
> can't connect to multi Cards, because of component->card.
> 
> 	static int soc_probe_component(...)
> 	{
> 		...
> 		if (component->card) {
> (A)			if (component->card != card) {
> 				dev_err(...);
> 				return -ENODEV;
> 			}
> 			return 0;
> 		}
> 		...
> 	}
> 
> I haven't fully analyzed it, but I guess this restriction came from
> each driver want to access to card, but FW doesn't hand over card pointer ?
> 
> 	-- ASoC FW --
> 
> 	/* ASoC hand over component pointer only */
> 	ops->callback(component);
> 
> 	-- driver --
> 
> 	/*
> 	 * It gets component pointer only, but want to access
> 	 * to card, too. component->card is added for it.
> 	 */
> 	callback(component)
> 	{
> 		struct snd_soc_card *card = component->card;
> 		...
> 	}
> 
> If this is the reason why restriction was created, do you think we can
> remove it if ASoC FW hand over both card and component pointer ?
> 
> 	-- ASoC FW --
> 
> 	/* ASoC hand over both card and component pointer */
> 	ops->callback(card, component);
> 	              ^^^^
> 	-- driver --
> 
> 	/*
> 	 * It gets both card and component pointer.
> 	 * component->card is no longer needed ?
> 	 */
> 	callback(card, component)
> 	{        ^^^^
> 		 ...
> 	}
> 
> But are there any other reasons ?
> 
> I think it is not strange that DAI has Component pointer.
> It is fixed.
> 
> 	dai->component;
> 
> But, Component might be connected to multi Cards, we shouldn't fix it
> 
> 	component->card;
> 
> If above was sane, I would like to cleanup it.
> I think ASoC need to hand over Card and DAI pointer (instead of Component) ?
> But what do you think ?

Well, managing multiple cards would lead to a complete mess of
locking, I'm afraid.  And, conceptually the card is the top-level
abstraction, so it'd be unnatural to go beyond that in the ASoC
component.

Of course, we may use multiple cards, but its handling needs really a
careful manner, so it won't be that trivial, especially if DPCM plays
a role.


thanks,

Takashi

  reply	other threads:[~2025-12-17  8:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-17  2:39 About component->card Kuninori Morimoto
2025-12-17  8:30 ` Takashi Iwai [this message]
2025-12-19  0:49   ` Kuninori Morimoto
2025-12-19  9:10     ` Mark Brown
2025-12-22  1:26       ` 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=874ippecif.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=broonie@kernel.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lars@metafoo.de \
    --cc=linux-sound@vger.kernel.org \
    /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.