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 11:57:43 -0400 [thread overview]
Message-ID: <8bd0f97a1003180857vdd155e0o29684b50cbd5e34e@mail.gmail.com> (raw)
In-Reply-To: <20100318111848.GB3080@opensource.wolfsonmicro.com>
On Thu, Mar 18, 2010 at 07:18, Mark Brown wrote:
> On Thu, Mar 18, 2010 at 05:08:01PM +0800, Barry Song wrote:
>> On Thu, Mar 18, 2010 at 4:48 PM, Liam Girdwood wrote:
>> > Btw, have a look at wm8731.c. This driver supports both I2C and SPI and
>> > is less churn than splitting out the code into three files.
>
>> We have many discussion about a driver to support both spi and i2c in
>> another device(ad714x). At the beginning, the way in wm8731.c is used,
>> then after many comments, people agree splitting the driver to three
>> modules is the best way. If you are interested in it, you may take a
>> look at "input/misc: add Analog Devices AD714x captouch input driver"
>> in linux-input maillist.
>
> This was a discussion for the input subsystem and what makes sense here.
> For ASoC we've been using the approach that WM8731 and other similar
> drivers are using, please follow that approach with ASoC drivers.
> Adding files per driver per bus type isn't helpful here.
that isnt really true. the tact taken in the input subsystem wrt
multiple busses had nothing to do with the input subsystem. it was
designed to provide flexibility -- the core is not tied to the busses,
and any of the pieces could be loaded/unloaded on the fly instead of
forcing the core to be rebuilt just because of bus changes.
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.
-mike
next prev parent reply other threads:[~2010-03-18 15:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 8:16 [PATCH 0/4] extend ad1938 codec/machine driver to ad193x supporting ad1936/7/8/9 Barry Song
[not found] ` <1268900221-6833-1-git-send-email-21cnbao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-03-18 8:16 ` [PATCH 1/4] extend ad1938 codec " Barry Song
[not found] ` <1268900221-6833-2-git-send-email-21cnbao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-03-18 8:16 ` [PATCH 2/4] change bf5xx-ad1938 machine driver to bf5xx-ad193x machine driver Barry Song
[not found] ` <1268900221-6833-3-git-send-email-21cnbao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2010-03-18 8:17 ` [PATCH 3/4] soc-cache: add i2c read entry for 8_8 mode Barry Song
2010-03-18 8:17 ` [PATCH 4/4] soc-cache: let reg be AND'ed by 0xff instead of data buffer " Barry Song
2010-03-18 9:00 ` Liam Girdwood
2010-03-18 11:30 ` Mark Brown
2010-03-18 8:51 ` [PATCH 3/4] soc-cache: add i2c read entry " Liam Girdwood
2010-03-18 11:29 ` Mark Brown
2010-03-18 11:22 ` [PATCH 2/4] change bf5xx-ad1938 machine driver to bf5xx-ad193x machine driver Mark Brown
2010-03-18 8:48 ` [PATCH 1/4] extend ad1938 codec driver to ad193x supporting ad1936/7/8/9 Liam Girdwood
2010-03-18 9:08 ` Barry Song
2010-03-18 11:18 ` Mark Brown
2010-03-18 15:57 ` Mike Frysinger [this message]
2010-03-18 16:20 ` [Uclinux-dist-devel] " Mark Brown
2010-03-18 17:17 ` Mike Frysinger
2010-03-18 18:05 ` Mark Brown
2010-03-18 18:08 ` Mike Frysinger
2010-03-19 3:30 ` Barry Song
2010-03-19 7:07 ` Barry Song
2010-03-19 9:03 ` Liam Girdwood
2010-03-19 12:24 ` Mark Brown
2010-03-22 5:50 ` Barry Song
2010-03-22 12:52 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8bd0f97a1003180857vdd155e0o29684b50cbd5e34e@mail.gmail.com \
--to=vapier.adi@gmail.com \
--cc=21cnbao@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=barry.song@analog.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=lrg@slimlogic.co.uk \
--cc=uclinux-dist-devel@blackfin.uclinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).