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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
