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

From: Mike Frysinger <vapier.adi@gmail.com>
To: 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 <21cnbao@gmail.com>,
	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: Thu, 18 Mar 2010 13:17:11 -0400	[thread overview]
Message-ID: <8bd0f97a1003181017xba8e1a9oce2d40bf56818956@mail.gmail.com> (raw)
In-Reply-To: <20100318162017.GA6142@rakim.wolfsonmicro.main>

On Thu, Mar 18, 2010 at 12:20, Mark Brown wrote:
> On Thu, Mar 18, 2010 at 11:57:43AM -0400, Mike Frysinger wrote:
>> i'm not suggesting the ASoC codecs shouldnt use the same style across
>> the board (and thus we shouldnt change the AD193x driver), just
>> pointing out your basic premise here is invalid and that there are
>> pros/cons to each method and that they're independent of the
>> subsystem.  you simply selected a different solution.
>
> My point is that the fact that the input subsystem has made a choice is
> pretty much irrelevant for ASoC, which has different considerations and
> therefore made a different choice.  Barry had simply said there had been
> a big discussion and this is what had been agreed, but that discussion
> was held for the input subsystem and when the equivalent discussion was
> held for ASoC a different conclusion was reached.

i dont think that's entirely true ... one of the major points of
getting drivers into mainline is so that when common paradigms are
observed, they can be unified across everyone.  subsystems rarely are
special ... most of the time, people just think they're special and so
can ignore the common behavior.

as devices get more complicated and hook up to more arbitrary busses,
i'm sure something will arise in the future to address this.

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