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

Lars-Peter Clausen lars at metafoo.de
Mon Mar 10 12:29:33 CET 2014


On 03/10/2014 12:05 PM, Mark Brown wrote:
> 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.

Take a look at e.g. omap/rx51.c it's doing what I'm describing and I presume 
it does this for the reasons I described.

But it doesn't really matter. The important thing about this series is that 
card level DAPM elements and controls should be registered with the card not 
the CODEC and I think we can agree on that one.

- Lars


More information about the Alsa-devel mailing list