All of lore.kernel.org
 help / color / mirror / Atom feed
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 14:08:14 -0400	[thread overview]
Message-ID: <8bd0f97a1003181108y3f7f5871t81c5cd5ba0c6312d@mail.gmail.com> (raw)
In-Reply-To: <20100318180516.GF6142@rakim.wolfsonmicro.main>

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

  reply	other threads:[~2010-03-18 18:08 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           ` [Uclinux-dist-devel] " Mike Frysinger
2010-03-18 16:20             ` Mark Brown
2010-03-18 17:17               ` Mike Frysinger
2010-03-18 18:05                 ` Mark Brown
2010-03-18 18:08                   ` Mike Frysinger [this message]
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=8bd0f97a1003181108y3f7f5871t81c5cd5ba0c6312d@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.