On 12/10/2015 04:38 AM, Mark Brown wrote:
On Wed, Dec 09, 2015 at 05:09:31PM +0800, Mengdong Lin wrote:
I have no intention to replace the existing aux_devs with aux_components. The aux_components is not for codecs and has no rtd like aux_dev.
OK, but I do think that's something we *should* be doing as part of the overall move of CODECs to components and it's something that having this change implies we should be doing as an immediate thing since it's the more obvious direct use of the code (as Lars said in reply to the early draft you posted IIRC).
My early draft didn't use the aux components, so I'm not sure where to find Lars's comments on this idea.
Please check if my understanding is right?
I guess you want me to replace the "aux_dev" array from the struct snd_soc_card, by an "aux_components" array. And we may replace soc_bind_aux_dev() by soc_find_components(), replace soc_probe/remove_aux_dev() by soc_probe/remove_components. Probably soc_find/prove/remove_components need some adjustment for the the aux devices (DAIless codecs).
And device driver of the these aux_dev need to use snd_soc_register_component() to make it as a component.
The purpose to introduce aux_components here is to let a soc card to load topology info easier:
E.g. The machine driver may not define any FE DAI links explicitly but specify an aux component. And the platform driver can implement the aux component and let its probe ops to load the topology info. When the ASoC core is instantiating the soc card, it must to find the aux component and probe it (the platform component). Thus the topology info for the platform is loaded and topology core will create widgets/controls/routes/DAIs/DAI links. So after probing the aux components, the ASoC need to check if any new links are created, bind them and create pcm runtimes for them.
I think I'd need to see the code you're proposing here to really comment but I think it sounds like it comes back to the same thing as the above case where we're overall trying to move everything towards uniformly being components.
In my test cases, the Broadwell machine driver (sound/soc/intel/boards/broadwell.c) specifies the name an aux component for the soc card:
+static struct snd_soc_aux_component broadwell_topology_components[] = { + /* Platform topology component */ + { + .name = "haswell-pcm-audio", + }, +};
/* broadwell audio machine driver for WPT + RT286S */ static struct snd_soc_card broadwell_rt286 = { .name = "broadwell-rt286", .owner = THIS_MODULE, + .aux_components = broadwell_topology_components, + .num_aux_components = ARRAY_SIZE(broadwell_topology_components), .dai_link = broadwell_rt286_dais, .num_links = ARRAY_SIZE(broadwell_rt286_dais), .controls = broadwell_controls,
Actually, the component "haswell-pcm-audio" is the component name for the platform (sound/soc/intel/haswell/sst-haswell-pcm.c).
When the ASoC core instantiates the soc card, it will find the aux component at first, which is available only after the platform is registered. Then the ASoC will probe the aux component which triggers the platform probe ops and this ops loads the topology info.
Thanks Mengdong
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel