All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liam Girdwood <lrg@slimlogic.co.uk>
To: Ryan Mallon <ryan@bluewatersys.com>
Cc: vbarinov <vbarinov@embeddedalley.com>,
	alsa-devel <alsa-devel@alsa-project.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	"timur.tabi@gmail.com" <timur.tabi@gmail.com>,
	Wan ZongShun <mcuos.com@gmail.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Peter Ujfalusi <peter.ujfalusi@nokia.com>,
	jassisinghbrar <jassisinghbrar@gmail.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Sedji Gaouaou <sedji.gaouaou@atmel.com>,
	Cliff Cai <cliff.cai@analog.com>,
	"Candelaria Villareal, Jorge" <jorge.candelaria@ti.com>,
	"vaibhav.bedia" <vaibhav.bedia@ti.com>,
	Kuninori Morimoto <morimoto.kuninori@renesas.com>
Subject: Re: [RFC 0/5] ASoC multi-component support : core
Date: Sat, 26 Jun 2010 18:52:26 +0100	[thread overview]
Message-ID: <1277574746.3110.35.camel@odin> (raw)
In-Reply-To: <4C252FEF.5060302@bluewatersys.com>

On Sat, 2010-06-26 at 10:38 +1200, Ryan Mallon wrote:
> Liam Girdwood wrote:
> > On Fri, 2010-06-25 at 16:51 +1200, Ryan Mallon wrote:

> >> I don't understand why the tlv320 codec is not being registered. Any ideas?
> >>
> > 
> > Since we now support N codecs, some codecs will now require an ID field
> > to distinguish them from others. e.g. a board with two WM8750 codecs
> > would have codecs at I2C addresses 0x1a and 0x1b, hence will require
> > each codec to be identified on the DAI link.
> > 
> > Can you try this patch below. From the output it looks like your
> > tlv320aic23 is at I2C address 26. 
> > 
> > 
> > diff --git a/sound/soc/ep93xx/snappercl15.c b/sound/soc/ep93xx/snappercl15.c
> > index aeb822d..72b7913 100644
> > --- a/sound/soc/ep93xx/snappercl15.c
> > +++ b/sound/soc/ep93xx/snappercl15.c
> > @@ -94,6 +94,7 @@ static struct snd_soc_dai_link snappercl15_dai = {
> >         .cpu_dai_drv    = &ep93xx_i2s_dai,
> >         .codec_dai_drv  = &tlv320aic23_dai,
> >         .codec_drv      = &soc_codec_dev_tlv320aic23,
> > +       .codec_id       = 26,
> >         .platform_drv   = &ep93xx_soc_platform,
> >         .init           = snappercl15_tlv320aic23_init,
> >         .ops            = &snappercl15_ops,
> > 
> 
> Ah, that makes sense. I will try the patch on Monday. One thing to note
> is that in arch/arm/mach-ep93xx/snappercl15.c there is  already:
> 
> static struct i2c_board_info __initdata snappercl15_i2c_data[] = {
>         {
>                 /* Audio codec */
>                 I2C_BOARD_INFO("tlv320aic23", 0x1a),
>         },
> };
> 
> Is there a clean way to avoid hard-coding the i2c address of the tlv320
> codec twice? Can I pass -1 to find any available codec? 

Yes, -1 should find any available codec. 

> If not, can you
> change the patch to 0x1a rather than 26, since i2c addresses tend to be
> written in hex.

I've changed to hex and pushed. My preference here is that we keep the
hard coded value atm, as planned changes later on will depend on it. The
future intention for dai_link is to remove the *_drv pointers and just
have the dai_link created from unique IDs. e.g. we will eventually have
something like :-

struct snd_soc_dai_link snappercl15_dai = {
	.cpu_dai_id    = SND_SOC_CPU_DAI(EP93XX, I2S, 0),
	.codec_dai_id  = SND_SOC_CODEC_DAI(TLV320AIC23, 0),
	.codec_id      = SND_SOC_I2C_CODEC(TLV320AIC23, 0, 0x1a),
	.platform_id   = SND_SOC_PLATFORM(EP93XX, 0),
	.init           = snappercl15_tlv320aic23_init,
	.ops            = &snappercl15_ops,
};

Note: this format has not been decided on yet.

Thanks

Liam
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

  reply	other threads:[~2010-06-26 17:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-24 19:24 [RFC 0/5] ASoC multi-component support : core Liam Girdwood
2010-06-24 21:36 ` Ryan Mallon
2010-06-24 23:12   ` Mark Brown
2010-06-24 23:38     ` Ryan Mallon
2010-06-25  4:51       ` Ryan Mallon
2010-06-25  8:37         ` Liam Girdwood
2010-06-25 22:38           ` Ryan Mallon
2010-06-26 17:52             ` Liam Girdwood [this message]
2010-06-26  2:25 ` Wan ZongShun
2010-06-26 17:29   ` Liam Girdwood
2010-06-28  7:16 ` Jarkko Nikula
2010-07-01 19:35   ` Mark Brown
2010-07-01 19:55 ` [PATCH] ASoC: Use bool rather than 1 bit bitfield in multi-component Mark Brown
2010-07-05 21:10   ` Liam Girdwood
2010-07-01 20:01 ` [RFC 0/5] ASoC multi-component support : core 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=1277574746.3110.35.camel@odin \
    --to=lrg@slimlogic.co.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=cliff.cai@analog.com \
    --cc=haojian.zhuang@gmail.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=jorge.candelaria@ti.com \
    --cc=lars@metafoo.de \
    --cc=mcuos.com@gmail.com \
    --cc=morimoto.kuninori@renesas.com \
    --cc=peter.ujfalusi@nokia.com \
    --cc=ryan@bluewatersys.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sedji.gaouaou@atmel.com \
    --cc=timur.tabi@gmail.com \
    --cc=vaibhav.bedia@ti.com \
    --cc=vbarinov@embeddedalley.com \
    /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.