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@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
