From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Mallon Subject: Re: [RFC 0/5] ASoC multi-component support : core Date: Sat, 26 Jun 2010 10:38:39 +1200 Message-ID: <4C252FEF.5060302@bluewatersys.com> References: <1277407467.3100.579.camel@odin> <4C23CFC0.6080700@bluewatersys.com> (sfid-20100624_223607_408551_609C17DE) <661928F7-0509-4E84-A296-0949E2D76EE3@opensource.wolfsonmicro.com> <4C23EC65.9080601@bluewatersys.com> <4C2435DC.5080509@bluewatersys.com> <1277455066.3123.10.camel@odin> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from hayes.bluewaternz.com (mail.bluewatersys.com [202.124.120.130]) by alsa0.perex.cz (Postfix) with ESMTP id DDE18103820 for ; Sat, 26 Jun 2010 00:38:47 +0200 (CEST) In-Reply-To: <1277455066.3123.10.camel@odin> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Liam Girdwood Cc: vbarinov , alsa-devel , Lars-Peter Clausen , "timur.tabi@gmail.com" , Wan ZongShun , Sascha Hauer , Mark Brown , Peter Ujfalusi , jassisinghbrar , Haojian Zhuang , Sedji Gaouaou , Cliff Cai , "Candelaria Villareal, Jorge" , "vaibhav.bedia" , Kuninori Morimoto List-Id: alsa-devel@alsa-project.org Liam Girdwood wrote: > On Fri, 2010-06-25 at 16:51 +1200, Ryan Mallon wrote: >> On 06/25/2010 11:38 AM, Ryan Mallon wrote: >>> On 06/25/2010 11:12 AM, Mark Brown wrote: >>> >>>> Do you actually see sound cards appearing? The log message at boot >>>> is purely informational, cards can probe at any time. >>>> >>>> Define DEBUG at the top of soc-audio.c if the card never appears at all >>>> then look at the log messages - they will say why the card is not being >>>> instantiated. >>>> >>>> >>> Hmm. If I define DEBUG at the top of sound/soc/soc-core.c I get this >>> (boots fine without DEBUG, but have no sound cards): >>> >> The crash was caused because I wasn't setting codec_drv in the >> snd_soc_dai_link for the Snapper CL15 (updated patch below). I still >> have no sound cards. I get the following in dmesg: >> >> tlv320aic23 0-001a: probe >> tlv320aic23 0-001a: codec register tlv320aic23 26 >> tlv320aic23 0-001a: dai register tlv320aic23 0 >> Registered DAI 'tlv320aic23.0' >> Registered codec 'tlv320aic23.26' >> i2c-core: driver [tlv320aic23] registered >> ep93xx-pcm-audio ep93xx-pcm-audio: platform register ep93xx-audio -1 >> Registered platform 'ep93xx-audio' >> ep93xx-i2s ep93xx-i2s: dai register ep93xx-i2s -1 >> Registered DAI 'ep93xx-i2s.-1' >> soc-audio soc-audio: CODEC tlv320aic23 not registered >> soc-audio soc-audio: Registered card 'Snapper CL15' >> ALSA device list: >> No soundcards found. >> >> >> 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? If not, can you change the patch to 0x1a rather than 26, since i2c addresses tend to be written in hex. ~Ryan