Re: ASoC component/card relationship

From: Curtis Malainey <cujomalainey@google.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: "ALSA Development Mailing List" <alsa-devel@alsa-project.org>,
	"Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
	"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
	"Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>,
	"Cezary Rojewski" <cezary.rojewski@intel.com>,
	"Takashi Iwai" <tiwai@suse.com>,
	"Liam Girdwood" <liam.r.girdwood@linux.intel.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
	"Bard Liao" <yung-chuan.liao@linux.intel.com>
Subject: Re: ASoC component/card relationship
Date: Fri, 29 Apr 2022 15:32:09 -0700	[thread overview]
Message-ID: <CAOReqxg9Y0_S5jqati4O+GT0C_yR7agBZYK79O996MQAk3HmDQ@mail.gmail.com> (raw)
In-Reply-To: <d9c3fed4-de6a-2cd8-acb6-7f3d2ad46b70@linux.intel.com>

On Fri, Apr 29, 2022 at 2:55 PM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
> Hi,
> In the existing ASoC code, there is a fixed mapping between ASoC card and component. A component relies on a ->card pointer that is set during the probe. A component cannot be used by or "bound to" more than one card [1]
>
> This has interesting impacts on how a codec or DSP driver need to be implemented.
>
> In the AVS series posted this week, multiple components are registered by the DSP driver, following an interface-based split. There's in addition a second-level split, where the logic is pushed further: the DSP driver partitions the SSP DAIs in different set of 'dai_driver's used by different components, which are in turn used by different cards. What is done in these patches is not wrong, and is probably the only solution to support a real-world platform with the existing ASoC code, but are the framework assumptions correct? In this example, the board-level information on which interface is used for what functionality trickles down to the lowest level of the DSP driver implementation.
>
> I believe this breaks to some extent the 'clean' split between platform and machine driver(s), and it's not quite aligned with the usual notion of register/probe used across frameworks, be it for drivers/clocks/you name it.
>
> A similar case could happen in a codec driver, if independent functionality such as headset and amplifier support was exposed by separate cards, that would in turn mandate that the codec driver exposed N components, each handling different functionality but the same type of DAI.
>
> An alternative approach would be that the DSP driver exposes all the possible DAIs that can be used, and the binding is refined to allow for more flexibility. I think it's really the individual DAI that cannot be used by more than one card.

Would it also be logical to expose the DAIs on the codecs
independently or should this be validated on a case by case basis?

>
> I figured I would ask on this mailing list if
>
> a) I am not mistaken on the component/card relationship and
>

Just trying to think of a reason why this would not be true. Are we
aware of platforms that have configuration relationships across DAIs?
E.g. they use a single clock and must be configured together, so
splitting them might cause them to be in sync? Otherwise I agree, if
DAIs can be handled independently then I don't see why we should tie
them together.

Curtis

> b) if this is by design, or if we want to clarify what a component is and what its restrictions might be.
>
> Thanks for your feedback/comments
> -Pierre
>
> [1] https://elixir.bootlin.com/linux/latest/source/sound/soc/soc-core.c#L1364