[alsa-devel] [RFC 0/5] ASoC multi-component support : core

[Ryan Mallon]

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