[alsa-devel] [PATCH 1/3] ASoC: omap-abe-twl6040: No need to register DMIC routes seperatly

Mark Brown broonie at kernel.org
Mon Mar 10 12:05:03 CET 2014


On Mon, Mar 10, 2014 at 11:27:39AM +0100, Lars-Peter Clausen wrote:
> On 03/10/2014 11:10 AM, Mark Brown wrote:

> >The only thing that should be registering
> >things for other components is the card and the general idea was to
> >register everything in late_probe().

> What most machine drivers did before card table based setup is to
> have a per-component callback in which they did register the card
> DAPM elements associated with that component. E.g. routes from the
> CODEC output to a speaker, etc. You couldn't register the card level
> DAPM elements for one component in the init callback component of
> another one since the routes depend on the widgets being registered
> first. So those board drivers kept separate routes and widget tables
> for separate components. With table based setup for the card the

I'm sorry but this just isn't what was happening at all.  Remember that
most of the code that you're looking at only ever had one component so
it really never made any difference which callback people happened to
pick so long as it was one of the ones that ran after the CODEC was up.

The only driver that I can think of which did anything like what you
describe was smdk-wm8580 and that was still only using one component,
it's just that Jassi preferred to split the input and output paths since
the DAIs were separate on the CODEC and he felt that was clearer.  It
didn't make any practical difference, it certainly wasn't due to startup
ordering.

> routes are registered after all components have been registered,
> which means you can register all the routes via one table since all
> the dependencies are ready. Same is true if you use the card's
> late_probe callback to register the DAPM routes and widgets.

Right, anything that actually cared would be using the late_probe()
callback.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140310/23e6cf62/attachment.sig>


More information about the Alsa-devel mailing list