[alsa-devel] [2.6.30-rc2][PATCH 0/2] Yet another DSP format fix into OMAP McBSP DAI
Hopefully this is the last fourth DSP format fix into McBSP DAI...
Tested with N810 modified to use DSP_B and with AIC33 codec. Also with Beagle by using McBSP3 routed to expansion pin header and using scope.
Luckily TLV320AIC23 and TLV320AIC33 codec drivers seems to be correct but machine driver for OSK5912 must be corrected to not use inverted FS polarity since AIC23 doesn't have support for it.
The DSP format wasn't still correct in OMAP McBSP DAI even after the commit bd25867a6cbe7a00ef7dbe8d9ddebc91b00b9b3f.
Thanks to Peter Ujfalusi peter.ujfalusi@nokia.com for noticing and being part of the fix. Now the FS length definition is more clear by defining it with FWID(0).
Signed-off-by: Jarkko Nikula jarkko.nikula@nokia.com Cc: Peter Ujfalusi peter.ujfalusi@nokia.com --- sound/soc/omap/omap-mcbsp.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 9c09b94..90f4df7 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -283,7 +283,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, break; case SND_SOC_DAIFMT_DSP_B: regs->srgr2 |= FPER(wlen * channels - 1); - regs->srgr1 |= FWID(wlen * channels - 2); + regs->srgr1 |= FWID(0); break; }
@@ -302,6 +302,7 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, { struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai->private_data); struct omap_mcbsp_reg_cfg *regs = &mcbsp_data->regs; + unsigned int temp_fmt = fmt;
if (mcbsp_data->configured) return 0; @@ -328,6 +329,8 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, /* 0-bit data delay */ regs->rcr2 |= RDATDLY(0); regs->xcr2 |= XDATDLY(0); + /* Invert FS polarity configuration */ + temp_fmt ^= SND_SOC_DAIFMT_NB_IF; break; default: /* Unsupported data format */ @@ -351,7 +354,7 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, }
/* Set bit clock (CLKX/CLKR) and FS polarities */ - switch (fmt & SND_SOC_DAIFMT_INV_MASK) { + switch (temp_fmt & SND_SOC_DAIFMT_INV_MASK) { case SND_SOC_DAIFMT_NB_NF: /* * Normal BCLK + FS.
On Wednesday 15 April 2009 13:48:16 Nikula Jarkko (Nokia-D/Helsinki) wrote:
The DSP format wasn't still correct in OMAP McBSP DAI even after the commit bd25867a6cbe7a00ef7dbe8d9ddebc91b00b9b3f.
Thanks to Peter Ujfalusi peter.ujfalusi@nokia.com for noticing and being part of the fix. Now the FS length definition is more clear by defining it with FWID(0).
Signed-off-by: Jarkko Nikula jarkko.nikula@nokia.com Cc: Peter Ujfalusi peter.ujfalusi@nokia.com
sound/soc/omap/omap-mcbsp.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
I believe this is correct.
Acked-by: Peter Ujfalusi peter.ujfalusi@nokia.com
On Wed, Apr 15, 2009 at 02:04:36PM +0300, Peter Ujfalusi wrote:
I believe this is correct.
Acked-by: Peter Ujfalusi peter.ujfalusi@nokia.com
Excellent! I'll apply both, thanks.
On Wed, Apr 15, 2009 at 5:26 PM, Mark Brown broonie@sirena.org.uk wrote:
On Wed, Apr 15, 2009 at 02:04:36PM +0300, Peter Ujfalusi wrote:
I believe this is correct.
Acked-by: Peter Ujfalusi peter.ujfalusi@nokia.com
Excellent! I'll apply both, thanks.
This patch is working(tested on osk5912), but with SND_SOC_DAIFMT_NB_IF in the machine driver. When SND_SOC_DAIFMT_NB_NF used, noise on Right channel.
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Thu, Apr 16, 2009 at 03:38:07PM +0530, Arun KS wrote:
This patch is working(tested on osk5912), but with SND_SOC_DAIFMT_NB_IF in the machine driver. When SND_SOC_DAIFMT_NB_NF used, noise on Right channel.
What sort of noise are you getting - is it just noise or is there some signal underneath the noise? Can you try playing a signal with no data on the left channel and see what effect that has?
The CODEC doesn't support inverted frame so a configuration with inverted frame clock can't be correct.
On Thu, Apr 16, 2009 at 3:42 PM, Mark Brown broonie@sirena.org.uk wrote:
On Thu, Apr 16, 2009 at 03:38:07PM +0530, Arun KS wrote:
This patch is working(tested on osk5912), but with SND_SOC_DAIFMT_NB_IF in the machine driver. When SND_SOC_DAIFMT_NB_NF used, noise on Right channel.
What sort of noise are you getting - is it just noise or is there some signal underneath the noise? Can you try playing a signal with no data on the left channel and see what effect that has?
Its not just noise, signal is there underneath.
The CODEC doesn't support inverted frame so a configuration with inverted frame clock can't be correct.
On Thu, Apr 16, 2009 at 03:47:03PM +0530, Arun KS wrote:
On Thu, Apr 16, 2009 at 3:42 PM, Mark Brown broonie@sirena.org.uk wrote:
What sort of noise are you getting - is it just noise or is there some signal underneath the noise? ?Can you try playing a signal with no data on the left channel and see what effect that has?
Its not just noise, signal is there underneath.
Could you try the test with no data on the left channel? I suspect that the LSB of the left channel may be being processed as the MSB of the right channel.
On Thu, Apr 16, 2009 at 3:49 PM, Mark Brown broonie@sirena.org.uk wrote:
On Thu, Apr 16, 2009 at 03:47:03PM +0530, Arun KS wrote:
On Thu, Apr 16, 2009 at 3:42 PM, Mark Brown broonie@sirena.org.uk wrote:
What sort of noise are you getting - is it just noise or is there some signal underneath the noise? ?Can you try playing a signal with no data on the left channel and see what effect that has?
Its not just noise, signal is there underneath.
Could you try the test with no data on the left channel? I suspect that the LSB of the left channel may be being processed as the MSB of the right channel.
I have to create one.
On Thu, 16 Apr 2009 12:19:45 +0200 ext Mark Brown broonie@sirena.org.uk wrote:
What sort of noise are you getting - is it just noise or is there some signal underneath the noise? ?Can you try playing a signal with no data on the left channel and see what effect that has?
Its not just noise, signal is there underneath.
Could you try the test with no data on the left channel? I suspect that the LSB of the left channel may be being processed as the MSB of the right channel.
I'm wondering why the left channel is still playing fine?
Jarkko
On Thu, Apr 16, 2009 at 01:31:43PM +0300, Jarkko Nikula wrote:
ext Mark Brown broonie@sirena.org.uk wrote:
Could you try the test with no data on the left channel? I suspect that the LSB of the left channel may be being processed as the MSB of the right channel.
I'm wondering why the left channel is still playing fine?
If you drop the LSB of data it will normally sound fine but the signal level will be reduced - the effects are much less obvious when testing by ear than errors in the MSB.
On Thu, 16 Apr 2009 12:33:58 +0200 ext Mark Brown broonie@sirena.org.uk wrote:
On Thu, Apr 16, 2009 at 01:31:43PM +0300, Jarkko Nikula wrote:
ext Mark Brown broonie@sirena.org.uk wrote:
Could you try the test with no data on the left channel? I suspect that the LSB of the left channel may be being processed as the MSB of the right channel.
I'm wondering why the left channel is still playing fine?
If you drop the LSB of data it will normally sound fine but the signal level will be reduced - the effects are much less obvious when testing by ear than errors in the MSB.
I meant if there is one bit difference or bit clock polarity is wrong then the both channels should be corrupted? At least the AIC33 is behaving so.
I was thinking can the codec go out-of-sync during bit transmission of left followed by right channel data and resynchronize back after next FS change but this really sounds bit too far reason to me.
Jarkko
On Thu, Apr 16, 2009 at 4:17 PM, Jarkko Nikula jarkko.nikula@nokia.com wrote:
On Thu, 16 Apr 2009 12:33:58 +0200 ext Mark Brown broonie@sirena.org.uk wrote:
On Thu, Apr 16, 2009 at 01:31:43PM +0300, Jarkko Nikula wrote:
ext Mark Brown broonie@sirena.org.uk wrote:
Could you try the test with no data on the left channel? I suspect that the LSB of the left channel may be being processed as the MSB of the right channel.
I'm wondering why the left channel is still playing fine?
If you drop the LSB of data it will normally sound fine but the signal level will be reduced - the effects are much less obvious when testing by ear than errors in the MSB.
I meant if there is one bit difference or bit clock polarity is wrong then the both channels should be corrupted? At least the AIC33 is behaving so.
I was thinking can the codec go out-of-sync during bit transmission of left followed by right channel data and resynchronize back after next FS change but this really sounds bit too far reason to me.
Hi Guys,
I had done some mistake while applying the Jarkko's patch previously. Now its working fine. Sorry for the confusion caused.
Arun
Jarkko
On Thursday 16 April 2009 14:20:36 ext Arun KS wrote:
Hi Guys,
I had done some mistake while applying the Jarkko's patch previously. Now its working fine. Sorry for the confusion caused.
:) I have digged out an old omap1510 TRM to see what is going on...
Still, while you have the setup, can you give my two patch a try on OMAP1 to see if it is working correctly?
Arun
Jarkko
On Thu, Apr 16, 2009 at 4:57 PM, Peter Ujfalusi peter.ujfalusi@nokia.com wrote:
On Thursday 16 April 2009 14:20:36 ext Arun KS wrote:
Hi Guys,
I had done some mistake while applying the Jarkko's patch previously. Now its working fine. Sorry for the confusion caused.
:) I have digged out an old omap1510 TRM to see what is going on...
Still, while you have the setup, can you give my two patch a try on OMAP1 to see if it is working correctly?
Your patches are working. I tested for DSP_A and DSP_B. Both works fine on osk5912 board.
But when I2S is used there is no audio on Right channel(left channel is working fine). Thinks something is missing on tlv320aic23 driver.
Arun
Arun
Jarkko
-- Péter
On Thursday 16 April 2009 16:05:34 ext Arun KS wrote:
Your patches are working. I tested for DSP_A and DSP_B. Both works fine on osk5912 board.
Thank you very much for testing it!
But when I2S is used there is no audio on Right channel(left channel is working fine). Thinks something is missing on tlv320aic23 driver.
I have tested the patch, which changes the way how the I2S mode is configured and it was working. Also the end result is the same in I2S mode as it was before... And an obvious question: was the I2S mode worked before my patches?
I suppose you used the SND_SOC_DAIFMT_NB_NF with the I2S mode as well (which should be the correct one)?
Arun
On Thu, Apr 16, 2009 at 7:12 PM, Peter Ujfalusi peter.ujfalusi@nokia.com wrote:
On Thursday 16 April 2009 16:05:34 ext Arun KS wrote:
Your patches are working. I tested for DSP_A and DSP_B. Both works fine on osk5912 board.
Thank you very much for testing it!
But when I2S is used there is no audio on Right channel(left channel is working fine). Thinks something is missing on tlv320aic23 driver.
I have tested the patch, which changes the way how the I2S mode is configured and it was working. Also the end result is the same in I2S mode as it was before... And an obvious question: was the I2S mode worked before my patches?
No. Have to figure it out.
I suppose you used the SND_SOC_DAIFMT_NB_NF with the I2S mode as well (which should be the correct one)?
Yes.
Arun
-- Péter
Arun KS wrote:
On Thu, Apr 16, 2009 at 4:57 PM, Peter Ujfalusi peter.ujfalusi@nokia.com wrote:
On Thursday 16 April 2009 14:20:36 ext Arun KS wrote:
Hi Guys,
I had done some mistake while applying the Jarkko's patch previously. Now its working fine. Sorry for the confusion caused.
:) I have digged out an old omap1510 TRM to see what is going on...
Still, while you have the setup, can you give my two patch a try on OMAP1 to see if it is working correctly?
Your patches are working. I tested for DSP_A and DSP_B. Both works fine on osk5912 board.
But when I2S is used there is no audio on Right channel(left channel is working fine). Thinks something is missing on tlv320aic23 driver.
Arun
Arun
Jarkko
This sounds like the same problem Davinci has. From a comment in davinci-i2s.c
case SND_SOC_DAIFMT_I2S: /* Davinci doesn't support TRUE I2S, but some codecs will have * the left and right channels contiguous. This allows * dsp_a mode to be used with an inverted normal frame clk. * If your codec is master and does not have contiguous * channels, then you will have sound on only one channel. * Try using a different mode, or codec as slave. * * The TLV320AIC33 is an example of a codec where this works. * It has a variable bit clock frequency allowing it to have * valid data on every bit clock. * * The TLV320AIC23 is an example of a codec where this does not * work. It has a fixed bit clock frequency with progressively * more empty bit clock slots between channels as the sample * rate is lowered. */ Troy
On Thu, 16 Apr 2009 23:35:20 +0200 ext Troy Kisky troy.kisky@boundarydevices.com wrote:
Arun KS wrote:
But when I2S is used there is no audio on Right channel(left channel is working fine). Thinks something is missing on tlv320aic23 driver.
This sounds like the same problem Davinci has. From a comment in davinci-i2s.c
case SND_SOC_DAIFMT_I2S: /* Davinci doesn't support TRUE I2S, but some codecs will have * the left and right channels contiguous. This allows * dsp_a mode to be used with an inverted normal frame clk. * If your codec is master and does not have contiguous * channels, then you will have sound on only one channel. * Try using a different mode, or codec as slave. * * The TLV320AIC33 is an example of a codec where this works. * It has a variable bit clock frequency allowing it to have * valid data on every bit clock. * * The TLV320AIC23 is an example of a codec where this does not * work. It has a fixed bit clock frequency with progressively * more empty bit clock slots between channels as the sample * rate is lowered. */
Interesting codec. Arun, how is the right channel working with I2S if you try to run with higher rate? E.g. aplay -r [48000 | 96000] /dev/urandom
The I2S mode setup in tlv320aic23_set_dai_fmt looks correct.
Jarkko
On Fri, Apr 17, 2009 at 12:29 PM, Jarkko Nikula jarkko.nikula@nokia.com wrote:
On Thu, 16 Apr 2009 23:35:20 +0200 ext Troy Kisky troy.kisky@boundarydevices.com wrote:
Arun KS wrote:
But when I2S is used there is no audio on Right channel(left channel is working fine). Thinks something is missing on tlv320aic23 driver.
This sounds like the same problem Davinci has. From a comment in davinci-i2s.c
case SND_SOC_DAIFMT_I2S: /* Davinci doesn't support TRUE I2S, but some codecs will have * the left and right channels contiguous. This allows * dsp_a mode to be used with an inverted normal frame clk. * If your codec is master and does not have contiguous * channels, then you will have sound on only one channel. * Try using a different mode, or codec as slave. * * The TLV320AIC33 is an example of a codec where this works. * It has a variable bit clock frequency allowing it to have * valid data on every bit clock. * * The TLV320AIC23 is an example of a codec where this does not * work. It has a fixed bit clock frequency with progressively * more empty bit clock slots between channels as the sample * rate is lowered. */
Interesting codec. Arun, how is the right channel working with I2S if you try to run with higher rate? E.g. aplay -r [48000 | 96000] /dev/urandom
Its the same. Right channel remains blank and left channel is playing.
The I2S mode setup in tlv320aic23_set_dai_fmt looks correct.
Jarkko
On Fri, 17 Apr 2009 11:16:34 +0200 ext Arun KS getarunks@gmail.com wrote:
Interesting codec. Arun, how is the right channel working with I2S if you try to run with higher rate? E.g. aplay -r [48000 | 96000] /dev/urandom
Its the same. Right channel remains blank and left channel is playing.
There is a note for the register "Digital Audio Interface Format (Address: 0000111)" but I cannot find is this true for all formats or probably only for I2S. If it's only for I2S then this would explain as MCLK is 12 MHz in OSK5912.
"2. In master mode, BCLK = MCLK/4 for all sample rates except for 88.2 kHz and 96 kHz. For 88.2 kHz and 96 kHz sample rate, BCLK = MCLK."
Do you have possibility to measure this with an oscilloscope that are there more bit clock cycles than 32?
Jarkko
On Thu, 16 Apr 2009 13:20:36 +0200 ext Arun KS getarunks@gmail.com wrote:
Hi Guys,
I had done some mistake while applying the Jarkko's patch previously. Now its working fine. Sorry for the confusion caused.
Thanks for letting us know! We were privately discussing with Peter that can there be some difference in OMAP1 causing this. Even McBSP is quite compatible across different OMAPs there are some differencies between them and those are not so easy to point out from number different TRM's...
Jarkko
On Thu, Apr 16, 2009 at 04:50:36PM +0530, Arun KS wrote:
I had done some mistake while applying the Jarkko's patch previously. Now its working fine. Sorry for the confusion caused.
Ah, that's a relief!
On Thursday 16 April 2009 13:17:03 ext Arun KS wrote:
On Thu, Apr 16, 2009 at 3:42 PM, Mark Brown broonie@sirena.org.uk wrote:
On Thu, Apr 16, 2009 at 03:38:07PM +0530, Arun KS wrote:
This patch is working(tested on osk5912), but with SND_SOC_DAIFMT_NB_IF in the machine driver. When SND_SOC_DAIFMT_NB_NF used, noise on Right channel.
What sort of noise are you getting - is it just noise or is there some signal underneath the noise? Can you try playing a signal with no data on the left channel and see what effect that has?
Its not just noise, signal is there underneath.
Do you have Jarkko's two patches only? Can you give a try to my two patches on top of that? Can be the problem in the dual/single phase mode?
The CODEC doesn't support inverted frame so a configuration with inverted frame clock can't be correct.
Using inverted FS polarity in OSK5912 must be an error since TLV320AIC23 do not have support for inverted polarities. This is mostly due the hassle with the DSP formats in OMAP McBSP DAI and inversion on OMAP side probably just made this configuration working at some point.
Signed-off-by: Jarkko Nikula jarkko.nikula@nokia.com Cc: Arun KS arunks@mistralsolutions.com --- sound/soc/omap/osk5912.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/osk5912.c b/sound/soc/omap/osk5912.c index a952a4e..a4e149b 100644 --- a/sound/soc/omap/osk5912.c +++ b/sound/soc/omap/osk5912.c @@ -62,7 +62,7 @@ static int osk_hw_params(struct snd_pcm_substream *substream, /* Set codec DAI configuration */ err = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_DSP_B | - SND_SOC_DAIFMT_NB_IF | + SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM); if (err < 0) { printk(KERN_ERR "can't set codec DAI configuration\n"); @@ -72,7 +72,7 @@ static int osk_hw_params(struct snd_pcm_substream *substream, /* Set cpu DAI configuration */ err = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B | - SND_SOC_DAIFMT_NB_IF | + SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM); if (err < 0) { printk(KERN_ERR "can't set cpu DAI configuration\n");
On Wed, Apr 15, 2009 at 4:18 PM, Jarkko Nikula jarkko.nikula@nokia.com wrote:
Using inverted FS polarity in OSK5912 must be an error since TLV320AIC23 do not have support for inverted polarities. This is mostly due the hassle with the DSP formats in OMAP McBSP DAI and inversion on OMAP side probably just made this configuration working at some point.
Signed-off-by: Jarkko Nikula jarkko.nikula@nokia.com Cc: Arun KS arunks@mistralsolutions.com
sound/soc/omap/osk5912.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/osk5912.c b/sound/soc/omap/osk5912.c index a952a4e..a4e149b 100644 --- a/sound/soc/omap/osk5912.c +++ b/sound/soc/omap/osk5912.c @@ -62,7 +62,7 @@ static int osk_hw_params(struct snd_pcm_substream *substream, /* Set codec DAI configuration */ err = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_DSP_B |
- SND_SOC_DAIFMT_NB_IF |
- SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBM_CFM); if (err < 0) { printk(KERN_ERR "can't set codec DAI configuration\n"); @@ -72,7 +72,7 @@ static int osk_hw_params(struct snd_pcm_substream *substream, /* Set cpu DAI configuration */ err = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B |
- SND_SOC_DAIFMT_NB_IF |
- SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBM_CFM); if (err < 0) { printk(KERN_ERR "can't set cpu DAI configuration\n"); -- 1.6.2.1
Tested on osk5912.
Acked-by: Arun KS arunks@mistralsolutions.com
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (6)
-
Arun KS -
Arun KS -
Jarkko Nikula -
Mark Brown -
Peter Ujfalusi -
Troy Kisky