[alsa-devel] ALSA issue on DA850/OMAP-L138/AM18x
Resending with proper $SUBJECT...
Hi,
I was testing Audio with 2.6.37 on DA850 from Kevin Hilman Linux tree at [1] and found that audio is broken. Below patch fixes the issue.
--- From: Rajashekhara, Sudhakar sudhakar.raj@ti.com
davinci: fixes for audio on da850/omap-l138/am18x
On DA850/OMAP-L138/AM18x, AIC3x codec is at 0x18 slave address. But in sound/soc/davinci/davinci-evm.c file, "struct snd_soc_dai_link" has the wrong AIC3x codec slave address. This patch fixes this issue.
Also, this patch registers the platform device for davinci-pcm-audio.
Signed-off-by: Rajashekhara, Sudhakar sudhakar.raj@ti.com --- arch/arm/mach-davinci/devices-da8xx.c | 12 ++++++++++++ sound/soc/davinci/davinci-evm.c | 2 +- 2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index 9eec630..17c0dbc 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -473,6 +473,11 @@ static struct resource da850_mcasp_resources[] = { }, };
+struct platform_device davinci_pcm_device = { + .name = "davinci-pcm-audio", + .id = -1, +}; + static struct platform_device da850_mcasp_device = { .name = "davinci-mcasp", .id = 0, @@ -480,8 +485,15 @@ static struct platform_device da850_mcasp_device = { .resource = da850_mcasp_resources, };
+static void davinci_init_pcm(void) +{ + platform_device_register(&davinci_pcm_device); +} + void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata) { + davinci_init_pcm(); + /* DA830/OMAP-L137 has 3 instances of McASP */ if (cpu_is_davinci_da830() && id == 1) { da830_mcasp1_device.dev.platform_data = pdata; diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c index bc9e6b0..07db881 100644 --- a/sound/soc/davinci/davinci-evm.c +++ b/sound/soc/davinci/davinci-evm.c @@ -224,7 +224,7 @@ static struct snd_soc_dai_link da8xx_evm_dai = { .stream_name = "AIC3X", .cpu_dai_name= "davinci-mcasp.0", .codec_dai_name = "tlv320aic3x-hifi", - .codec_name = "tlv320aic3x-codec.0-001a", + .codec_name = "tlv320aic3x-codec.1-0018", .platform_name = "davinci-pcm-audio", .init = evm_aic3x_init, .ops = &evm_ops, ---
Also, I found that either CONFIG_REGULATOR should not be defined or if CONFIG_REGULATOR is defined then CONFIG_REGULATOR_DUMMY should also be defined. Without this menuconfig fix, Soundcard does not get detected.
With the above fixes, arecord and aplay does not work for the first time. Couple of times I get the below error:
root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat arecord: main:608: audio open error: Invalid argument aplay: playback:2297: read error root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat aplay: main:608: audio open error: Invalid argument Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Third time arecord and aplay work normally.
Has anyone seen such issues on DA850 or any other platform?
I am currently debugging this issue. I'll submit the above patch to community once the issue of fixed.
[1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summar...
Regards, Sudhakar _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
"Rajashekhara, Sudhakar" sudhakar.raj@ti.com writes:
Resending with proper $SUBJECT... Hi,
I was testing Audio with 2.6.37 on DA850 from Kevin Hilman Linux tree at [1] and found that audio is broken. Below patch fixes the issue.
From: Rajashekhara, Sudhakar sudhakar.raj@ti.com
davinci: fixes for audio on da850/omap-l138/am18x
On DA850/OMAP-L138/AM18x, AIC3x codec is at 0x18 slave address. But in sound/soc/davinci/davinci-evm.c file, "struct snd_soc_dai_link" has the wrong AIC3x codec slave address. This patch fixes this issue.
As suggested by Sergei...
This part should be one patch, and merged by Liam via ASoC tree for 2.6.38-rc cycle.
Also, this patch registers the platform device for davinci-pcm-audio.
This should be a separate patch as well, and I will merge it via davinci tree for the .38-rc cycle.
Signed-off-by: Rajashekhara, Sudhakar sudhakar.raj@ti.com
arch/arm/mach-davinci/devices-da8xx.c | 12 ++++++++++++ sound/soc/davinci/davinci-evm.c | 2 +- 2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index 9eec630..17c0dbc 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -473,6 +473,11 @@ static struct resource da850_mcasp_resources[] = { }, };
+struct platform_device davinci_pcm_device = {
- .name = "davinci-pcm-audio",
- .id = -1,
+};
static struct platform_device da850_mcasp_device = { .name = "davinci-mcasp", .id = 0, @@ -480,8 +485,15 @@ static struct platform_device da850_mcasp_device = { .resource = da850_mcasp_resources, };
+static void davinci_init_pcm(void) +{
- platform_device_register(&davinci_pcm_device);
+}
void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata) {
- davinci_init_pcm();
- /* DA830/OMAP-L137 has 3 instances of McASP */ if (cpu_is_davinci_da830() && id == 1) { da830_mcasp1_device.dev.platform_data = pdata;
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c index bc9e6b0..07db881 100644 --- a/sound/soc/davinci/davinci-evm.c +++ b/sound/soc/davinci/davinci-evm.c @@ -224,7 +224,7 @@ static struct snd_soc_dai_link da8xx_evm_dai = { .stream_name = "AIC3X", .cpu_dai_name= "davinci-mcasp.0", .codec_dai_name = "tlv320aic3x-hifi",
- .codec_name = "tlv320aic3x-codec.0-001a",
- .codec_name = "tlv320aic3x-codec.1-0018", .platform_name = "davinci-pcm-audio", .init = evm_aic3x_init, .ops = &evm_ops,
Also, I found that either CONFIG_REGULATOR should not be defined or if CONFIG_REGULATOR is defined then CONFIG_REGULATOR_DUMMY should also be defined. Without this menuconfig fix, Soundcard does not get detected.
When you send final version, care to include a patch for da8xx_omapl_defconfig?
Kevin
With the above fixes, arecord and aplay does not work for the first time. Couple of times I get the below error:
root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat arecord: main:608: audio open error: Invalid argument aplay: playback:2297: read error root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat aplay: main:608: audio open error: Invalid argument Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Third time arecord and aplay work normally.
Has anyone seen such issues on DA850 or any other platform?
I am currently debugging this issue. I'll submit the above patch to community once the issue of fixed.
[1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summar...
Regards, Sudhakar _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
On Tue, Jan 18, 2011 at 10:04:08AM -0800, Kevin Hilman wrote:
"Rajashekhara, Sudhakar" sudhakar.raj@ti.com writes:
On DA850/OMAP-L138/AM18x, AIC3x codec is at 0x18 slave address. But in sound/soc/davinci/davinci-evm.c file, "struct snd_soc_dai_link" has the wrong AIC3x codec slave address. This patch fixes this issue.
As suggested by Sergei...
This part should be one patch, and merged by Liam via ASoC tree for 2.6.38-rc cycle.
When reposting remember to CC the maintainers for the subsystem on the patch (as always when posting patches).
Hi Sudhakar,
On 18.01.2011 05:43, Rajashekhara, Sudhakar wrote:
[...]
With the above fixes, arecord and aplay does not work for the first time. Couple of times I get the below error:
root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat arecord: main:608: audio open error: Invalid argument aplay: playback:2297: read error root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat aplay: main:608: audio open error: Invalid argument Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Third time arecord and aplay work normally.
Has anyone seen such issues on DA850 or any other platform?
I am currently debugging this issue. I'll submit the above patch to
community
once the issue of fixed.
I'm facing the same issue here.
Did you make any progress on that one ?
Regards, Sudhakar
Regards,
Christophe
Hi Christophe,
On Wed, Feb 16, 2011 at 19:37:57, Christophe Aeschlimann wrote:
Hi Sudhakar,
On 18.01.2011 05:43, Rajashekhara, Sudhakar wrote:
[...]
With the above fixes, arecord and aplay does not work for the first time. Couple of times I get the below error:
root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat arecord: main:608: audio open error: Invalid argument aplay: playback:2297: read error root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat aplay: main:608: audio open error: Invalid argument Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz,
Stereo
Third time arecord and aplay work normally.
Has anyone seen such issues on DA850 or any other platform?
I am currently debugging this issue. I'll submit the above patch to
community
once the issue of fixed.
I'm facing the same issue here.
Did you make any progress on that one ?
Reverting the commit 140176159597ea1f23dcccb47b5c38fdf7c7faa8 (ASoC: Configure symmetric rates for tlv320aic3x) resolves the issue. We are still working on the proper fix.
Thanks, Sudhakar
Hi Sudhakar,
On 17.02.2011 05:23, Rajashekhara, Sudhakar wrote:
Reverting the commit 140176159597ea1f23dcccb47b5c38fdf7c7faa8 (ASoC: Configure symmetric rates for tlv320aic3x) resolves the issue. We are still working on the proper fix.
Thanks, Sudhakar
Did you find a proper solution to that issue ?
Kind Regards,
Christophe
Hi Christophe,
On Mon, Mar 07, 2011 at 14:10:41, Christophe Aeschlimann wrote:
Hi Sudhakar,
On 17.02.2011 05:23, Rajashekhara, Sudhakar wrote:
Reverting the commit 140176159597ea1f23dcccb47b5c38fdf7c7faa8 (ASoC: Configure symmetric rates for tlv320aic3x) resolves the issue. We are still working on the proper fix.
Thanks, Sudhakar
Did you find a proper solution to that issue ?
Did the workaround work for you?
Because of other engagements we have not spent time on finding the proper fix.
Regards, Sudhakar
On 08.03.2011 05:40, Rajashekhara, Sudhakar wrote:
Hi Christophe,
On Mon, Mar 07, 2011 at 14:10:41, Christophe Aeschlimann wrote:
Hi Sudhakar,
On 17.02.2011 05:23, Rajashekhara, Sudhakar wrote:
Reverting the commit 140176159597ea1f23dcccb47b5c38fdf7c7faa8 (ASoC: Configure symmetric rates for tlv320aic3x) resolves the issue. We are still working on the proper fix.
Thanks, Sudhakar
Did you find a proper solution to that issue ?
Did the workaround work for you?
I'm using the kernel at the following address :
http://arago-project.org/git/projects/?p=linux-omapl1.git
And this kernel doesn't have the symmetric rate patch so it must come from somewhere else.
Best regards,
Christophe
Hi Sudhakar,
On 08.03.2011 14:32, Christophe Aeschlimann wrote:
On 08.03.2011 05:40, Rajashekhara, Sudhakar wrote:
Hi Christophe,
On Mon, Mar 07, 2011 at 14:10:41, Christophe Aeschlimann wrote:
Hi Sudhakar,
On 17.02.2011 05:23, Rajashekhara, Sudhakar wrote:
Reverting the commit 140176159597ea1f23dcccb47b5c38fdf7c7faa8 (ASoC: Configure symmetric rates for tlv320aic3x) resolves the issue. We are still working on the proper fix.
Thanks, Sudhakar
Did you find a proper solution to that issue ?
Did the workaround work for you?
I'm using the kernel at the following address :
http://arago-project.org/git/projects/?p=linux-omapl1.git
And this kernel doesn't have the symmetric rate patch so it must come from somewhere else.
Best regards,
Christophe
Sorry to have bothered you with this.
In this end it was a HW issue.
Problem solved.
Best Regards,
Christophe
On 21.03.2011 12:24, Bedia, Vaibhav wrote:
On Monday, March 21, 2011 1:51 PM, Christophe Aeschlimann wrote: [...]
In this end it was a HW issue.
Problem solved.
If you don't mind, can you please elaborate on what the h/w issue was and how you fixed it?
Regards, Vaibhav
The symptoms were slightly different on our custom board which uses a TLV320AIC3107 codec :
After every cold boot the system would take ~7 seconds to start recording. Recording a second time just after the first time would behave normally (without delay).
This delay was because the ADC (audio input) starts working when the volts reach 1.35V (common mode) on the ADC. But a 10uF series capacitor was delaying the ramp-up by 7 seconds. Reducing the capacitor size changed the delay to something more reasonable (ms range).
This "issue" is described in the TLV320AIC3107 codec under "INPUT IMPEDANCE AND VCM CONTROL" the 2nd paragraph. (they also offer a workaround but this was not of a practical use in our case).
Hope this helps.
Regards,
On Monday, March 21, 2011 5:46 PM, Christophe Aeschlimann wrote: [...]
The symptoms were slightly different on our custom board which uses a TLV320AIC3107 codec :
After every cold boot the system would take ~7 seconds to start recording. Recording a second time just after the first time would behave normally (without delay).
This delay was because the ADC (audio input) starts working when the volts reach 1.35V (common mode) on the ADC. But a 10uF series capacitor was delaying the ramp-up by 7 seconds. Reducing the capacitor size changed the delay to something more reasonable (ms range).
This "issue" is described in the TLV320AIC3107 codec under "INPUT IMPEDANCE AND VCM CONTROL" the 2nd paragraph. (they also offer a workaround but this was not of a practical use in our case).
Thanks for the info.
Regards, Vaibhav
participants (5)
-
Bedia, Vaibhav -
Christophe Aeschlimann -
Kevin Hilman -
Mark Brown -
Rajashekhara, Sudhakar