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