About component->card

About component->card

[Kuninori Morimoto]

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 ?

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: About component->card

[Takashi Iwai]

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

Re: About component->card

[Kuninori Morimoto]

Hi Takashi-san, all

Thank you for your feedback

> > 	+-- Basic Board ---------+
> > 	|+--------+      +------+|
> > 	|| CPU ch0| <--> |CodecA||
> > 	||     ch1| <-+  +------+|
> > 	|+--------+   |          |
> > 	+-------------|----------+
> > 	+-- expansion board -----+
> > 	|             |  +------+|
> > 	|             +->|CodecB||
> > 	|                +------+|
> > 	+------------------------+
(snip)
> > 	 +-driver------+
> > 	 |+-component-+|
> > 	+-card0-------------------------+
> > 	|||           || +-driver------+|
> > 	|||           || |+-component-+||
> > 	|||    ch0 dai|<=>|dai        |||
> > 	|||           || |+-----------+||
> > 	|||           || +-------------+|
> > 	+-------------------------------+
> > 	 ||           ||
> > 	+-card1-------------------------+
> > 	|||           || +-driver------+|
> > 	|||           || |+-component-+||
> > 	|||    ch1 dai|<=>|dai        |||
> > 	|||           || |+-----------+||
> > 	|||           || +-------------+|
> > 	+-------------------------------+
> > 	 |+-----------+|
> > 	 +-------------+
(snip)
> 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.

Thank you for your opinion, I don't want to do something without agreement.
Indeed ASoC locking is very complicated. I can agree about your concern.

One question. I can agree about "the card is the top-level abstraction",
but what does "it'd be unnatural to go beyond that in the ASoC component"
mean ?

Indeed there are practical concerns (= complicate locking), but apart from
that, above image itself is not so strange, but am I misunderstanding ?
(= It is one of the gap between "ideals" and "reality" of ASoC ?)

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: About component->card

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Fri, Dec 19, 2025 at 12:49:49AM +0000, Kuninori Morimoto wrote:

> One question. I can agree about "the card is the top-level abstraction",
> but what does "it'd be unnatural to go beyond that in the ASoC component"
> mean ?

> Indeed there are practical concerns (= complicate locking), but apart from
> that, above image itself is not so strange, but am I misunderstanding ?
> (= It is one of the gap between "ideals" and "reality" of ASoC ?)

ASoC really wants to glue a bunch of components together into a card, it
doesn't have the concept of a component being in multiple cards.  There
are more assumptions than just the locking issue, for example DAPM
really wants to have a single graph for the whole card.  If there's any
overlap at all in hardware the natural thing in ASoC would be to have a
card with many PCMs and ouputs rather than have several cards.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: About component->card

[Kuninori Morimoto]

Hi Mark

> > Indeed there are practical concerns (= complicate locking), but apart from
> > that, above image itself is not so strange, but am I misunderstanding ?
> > (= It is one of the gap between "ideals" and "reality" of ASoC ?)
> 
> ASoC really wants to glue a bunch of components together into a card, it
> doesn't have the concept of a component being in multiple cards.  There
> are more assumptions than just the locking issue, for example DAPM
> really wants to have a single graph for the whole card.  If there's any
> overlap at all in hardware the natural thing in ASoC would be to have a
> card with many PCMs and ouputs rather than have several cards.

OK, thank you for clarify the situation

Thank you for your help !!

Best regards
---
Kuninori Morimoto