Re: [Uclinux-dist-devel] [PATCH 1/4] extend ad1938 codec driver to ad193x supporting ad1936/7/8/9

From: Barry Song <21cnbao@gmail.com>
To: Mike Frysinger <vapier.adi@gmail.com>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: uclinux-dist-devel@blackfin.uclinux.org,
	alsa-devel@alsa-project.org, Liam Girdwood <lrg@slimlogic.co.uk>,
	Barry Song <barry.song@analog.com>
Subject: Re: [Uclinux-dist-devel] [PATCH 1/4] extend ad1938 codec driver to ad193x supporting ad1936/7/8/9
Date: Fri, 19 Mar 2010 11:30:01 +0800	[thread overview]
Message-ID: <3c17e3571003182030mc8ea095u2298f008fbcbee8e@mail.gmail.com> (raw)
In-Reply-To: <8bd0f97a1003181108y3f7f5871t81c5cd5ba0c6312d@mail.gmail.com>

I think this issue has nothing to do with subsystems, anyway, both are
acceptable to me. Since there has been an example in ASoC, I will
follow it and send v2.
thanks
-barry

On Fri, Mar 19, 2010 at 2:08 AM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> 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
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel