On 12/09/2015 02:58 AM, Mark Brown wrote:
On Wed, Dec 02, 2015 at 02:11:56PM +0800, mengdong.lin@xxxxxxxxxxxxxxx wrote:
From: Mengdong Lin <mengdong.lin@xxxxxxxxxxxxxxx>
Machine drivers can set the name of one or more auxiliary components.
And the ASoC core will find and probe the auxiliary components.
Machine drivers can use this to specify the components with topology.
Then when the components are probed, topology info will be loaded to
the core.
This makes sense as a replacement for the existing aux_devs but this
doesn't feel terribly strongly related to the rest of the series and
we're not actually doing the transition yet. What's the relationship
with dynamic links and what's the plan for transition? There's CODECs
that could be transitioned relatively straightforwardly since they have
no DAIs and can only be used as aux_devs, it's them I'm mainly thinking
of here - the rest will need to wait I fear.
Thanks for your comments!
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.
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.
Regards
Mengdong
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
