Re: ASoC and a codec that can't be controlled

[Timur Tabi <timur@freescale.com>]

Liam Girdwood wrote:

> Yes, although my feeling is that a codec "driver" would still be needed
> to define the capabilities of your codec within the audio subsystem.

Another question:

Why is it the codec driver that calls snd_soc_new_pcms()?  Shouldn't the PCM driver be 
doing that?

Looking in snd_soc_new_pcms() itself, I see this:

	codec->card = snd_card_new(idx, xid, codec->owner, 0);

Here we create a new "sound card", and we assign it to the

I guess I just don't understand why the codec driver is acting like the "master" driver of 
ASOC.  IMHO, the codec driver should be doing two things:

1) Specifying the capabilities of the codec hardware itself, without any assumption that 
these capabilities dictate the capabilities of the system as a whole (e.g. the codec 
shouldn't assume that the system supports every sampling rate that the codec does).
2) Providing APIs for controlling the codec.

ASOC and the machine driver should then work in tandem to decide which driver will do what 
and which capabilities are *actually* supported.  *Something* needs to look at the entire 
system and say to each device, "Well, yes, I know about this little feature of yours, but 
we're just not going to support that today."

-- 
Timur Tabi
Linux Kernel Developer @ Freescale