[alsa-devel] [Uclinux-dist-devel] [PATCH 1/4] extend ad1938 codec driver to ad193x supporting ad1936/7/8/9
Mike Frysinger
vapier.adi at gmail.com
Thu Mar 18 19:08:14 CET 2010
On Thu, Mar 18, 2010 at 14:05, Mark Brown wrote:
> On Thu, Mar 18, 2010 at 01:17:11PM -0400, Mike Frysinger wrote:
>> > The subsystem dependency here come from the fact that ASoC has machine
>> > drivers and relies on them selecting the CODEC drivers to get them built
>> > in the first place so if you're trying to change something like this
>> > you'll most likely not only have to rebuild your kernel but also have to
>> > write code. This isn't something that the input layer has (input layer
>> > drivers are pretty much standalone, usually only need platform data
>> > for any per machine hookup and for I2C and SPI can even be registered
>> > from user space IIRC) and it changes the considerations noticably.
>
>> the machine driver selects the codec, it doesnt select the bus. the
>> codec worries about that. so i dont quite follow the logic here.
>
> That's not the case, CODEC drivers do absolutely nothing to ensure that
> they have the buses they need. Multi bus CODECs should all be perfectly
> happy to build with no bus at all, though sparse and/or GCC will warn.
>
> Kconfig will cheerfully ignore any dependencies of things that are
> selected - unless it's been updated recently all a select does is force
> the selected symbol on, it doesn't recurse through dependencies and
> selects of that symbol. Besides, multi bus CODEC drivers can't know
> which of their possible buses are actually needed on a given system -
> they just build support for any bus types that are configured and let
> something else worry about the resulting configuration actually being
> useful.
sure, on the Kconfig side, i can see that. i was thinking the pure C
drivers though. thanks for the clarification.
-mike
More information about the Alsa-devel
mailing list