[alsa-devel] [PATCH 0/2] ASoC: OMAP: Finalizing the DSP mode support
Hello,
This series should finally got both DSP_A and DSP_B modes working correctly on OMAP platforms. Big thanks goes to Jarkko to get (and test) the DSP_B mode in a good shape.
But, the DSP modes should use single-phase mode instead of the dual-phase mode, which is intended to be used with I2S, Left-justified, Right-justified modes.
The second patch adds DSP_A mode support to omap-mcbsp.
--- Peter Ujfalusi (2): ASoC: OMAP: Use single-phase for DSP mode ASoC: OMAP: Add DSP_A mode support for mcbsp
sound/soc/omap/omap-mcbsp.c | 38 ++++++++++++++++++++++++++------------ 1 files changed, 26 insertions(+), 12 deletions(-)
Use single-phase mode for the DSP mode and keep the dual phase mode for the I2S mode.
The mono (1 channel) mode already used single phase mode, now it is more cleaner. There is no need to configure the second phase, when the single phase is used.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- sound/soc/omap/omap-mcbsp.c | 30 ++++++++++++++++++------------ 1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 90f4df7..5857c3c 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -214,8 +214,9 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai->private_data); struct omap_mcbsp_reg_cfg *regs = &mcbsp_data->regs; int dma, bus_id = mcbsp_data->bus_id, id = cpu_dai->id; - int wlen, channels; + int wlen, channels, wpf; unsigned long port; + unsigned int format;
if (cpu_class_is_omap1()) { dma = omap1_dma_reqs[bus_id][substream->stream]; @@ -243,18 +244,23 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, return 0; }
- channels = params_channels(params); + format = mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK; + wpf = channels = params_channels(params); switch (channels) { case 2: - /* Use dual-phase frames */ - regs->rcr2 |= RPHASE; - regs->xcr2 |= XPHASE; + if (format == SND_SOC_DAIFMT_I2S) { + /* Use dual-phase frames */ + regs->rcr2 |= RPHASE; + regs->xcr2 |= XPHASE; + /* Set 1 word per (McBSP) frame for phase1 and phase2 */ + wpf--; + regs->rcr2 |= RFRLEN2(wpf - 1); + regs->xcr2 |= XFRLEN2(wpf - 1); + } case 1: - /* Set 1 word per (McBSP) frame */ - regs->rcr2 |= RFRLEN2(1 - 1); - regs->rcr1 |= RFRLEN1(1 - 1); - regs->xcr2 |= XFRLEN2(1 - 1); - regs->xcr1 |= XFRLEN1(1 - 1); + /* Set word per (McBSP) frame for phase1 */ + regs->rcr1 |= RFRLEN1(wpf - 1); + regs->xcr1 |= XFRLEN1(wpf - 1); break; default: /* Unsupported number of channels */ @@ -276,9 +282,9 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, }
/* Set FS period and length in terms of bit clock periods */ - switch (mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK) { + switch (format) { case SND_SOC_DAIFMT_I2S: - regs->srgr2 |= FPER(wlen * 2 - 1); + regs->srgr2 |= FPER(wlen * channels - 1); regs->srgr1 |= FWID(wlen - 1); break; case SND_SOC_DAIFMT_DSP_B:
DSP_A mode is similar to the DSP_B, but the MSB is delayed with one bclk (appears after the FS pulse and not under it).
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- sound/soc/omap/omap-mcbsp.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 5857c3c..4d6ef0b 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -287,6 +287,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, regs->srgr2 |= FPER(wlen * channels - 1); regs->srgr1 |= FWID(wlen - 1); break; + case SND_SOC_DAIFMT_DSP_A: case SND_SOC_DAIFMT_DSP_B: regs->srgr2 |= FPER(wlen * channels - 1); regs->srgr1 |= FWID(0); @@ -331,6 +332,13 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, regs->rcr2 |= RDATDLY(1); regs->xcr2 |= XDATDLY(1); break; + case SND_SOC_DAIFMT_DSP_A: + /* 1-bit data delay */ + regs->rcr2 |= RDATDLY(1); + regs->xcr2 |= XDATDLY(1); + /* Invert FS polarity configuration */ + temp_fmt ^= SND_SOC_DAIFMT_NB_IF; + break; case SND_SOC_DAIFMT_DSP_B: /* 0-bit data delay */ regs->rcr2 |= RDATDLY(0);
On Wed, 15 Apr 2009 14:38:56 +0200 "Ujfalusi Peter (Nokia-D/Tampere)" peter.ujfalusi@nokia.com wrote:
DSP_A mode is similar to the DSP_B, but the MSB is delayed with one bclk (appears after the FS pulse and not under it).
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com
Tested with Beagle and oscilloscope and with N810 where codec were used both as a master and slave. All worked and with correct bit polarities.
Acked-by: Jarkko Nikula jarkko.nikula@nokia.com
On Wed, 15 Apr 2009 14:38:55 +0200 "Ujfalusi Peter (Nokia-D/Tampere)" peter.ujfalusi@nokia.com wrote:
Use single-phase mode for the DSP mode and keep the dual phase mode for the I2S mode.
The mono (1 channel) mode already used single phase mode, now it is more cleaner. There is no need to configure the second phase, when the single phase is used.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com
I did a little bit of hacking and testing with this to see are can this even be a fix on top of my DSP_B fix for 2.6.30 but looks like there is no currently any difference or potential bug fix are we using single or dual phase mode for stereo samples. For testing I hacked to use word length of 20-bits (only the interface, not samples) and both phase modes produced the same bit stream.
But as this is more generic case and only option for multichannel configuration let's start to use it and let only I2S to continue use the dual-phase mode.
Acked-by: Jarkko Nikula jarkko.nikula@nokia.com
On Thu, Apr 16, 2009 at 12:07:50PM +0300, Jarkko Nikula wrote:
I did a little bit of hacking and testing with this to see are can this even be a fix on top of my DSP_B fix for 2.6.30 but looks like there is
Hrm. I'd merged your DSP_B fix for 2.6.31 not 2.6.30 since it seemed to be needed for new things like the TWL4030 4 channel mode and the existing boards were apparently OK in 2.6.29. Do you think it's urgent enough to pull over to 2.6.30 (I've not pushed to Takashi yet)?
I've applied both Peter's patches - thanks.
On Thursday 16 April 2009 12:31:21 ext Mark Brown wrote:
On Thu, Apr 16, 2009 at 12:07:50PM +0300, Jarkko Nikula wrote:
I did a little bit of hacking and testing with this to see are can this even be a fix on top of my DSP_B fix for 2.6.30 but looks like there is
Hrm. I'd merged your DSP_B fix for 2.6.31 not 2.6.30 since it seemed to be needed for new things like the TWL4030 4 channel mode and the existing boards were apparently OK in 2.6.29. Do you think it's urgent enough to pull over to 2.6.30 (I've not pushed to Takashi yet)?
Well, the DSP_B mode was broken for OMAP, the osk5912 with DSP_B mode was also broken in 2.6.29. I think the reason that we have not heard any screams regarding to broken DSP_B mode, that no one actually used osk5912 with 2.6.29?
I've applied both Peter's patches - thanks.
On Thu, Apr 16, 2009 at 12:43:00PM +0300, Peter Ujfalusi wrote:
Well, the DSP_B mode was broken for OMAP, the osk5912 with DSP_B mode was also broken in 2.6.29. I think the reason that we have not heard any screams regarding to broken DSP_B mode, that no one actually used osk5912 with 2.6.29?
Presumably OSK5912 has been broken since it was merged? Either that or the incorrectly inverted FS polarity happened to result in a setup which gives functional audio.
On Thursday 16 April 2009 12:48:47 ext Mark Brown wrote:
Presumably OSK5912 has been broken since it was merged? Either that or the incorrectly inverted FS polarity happened to result in a setup which gives functional audio.
I would not say that, I guess it was working at the time when it was merged - I also got the DSP_A mode working with 'incorrect' mcbsp code and configuration... But it does not really matter, how and when this DSP_B mode got into the wrong track. Now it is correct for both DSP_A and DSP_B modes, we need to keep it that way for the time being ;)
I would say that at least Jarkko's two patches should go as soon as possible to avoid further confusions regarding to DSP_B mode.
On Thu, 16 Apr 2009 11:31:21 +0200 ext Mark Brown broonie@sirena.org.uk wrote:
On Thu, Apr 16, 2009 at 12:07:50PM +0300, Jarkko Nikula wrote:
I did a little bit of hacking and testing with this to see are can this even be a fix on top of my DSP_B fix for 2.6.30 but looks like there is
Hrm. I'd merged your DSP_B fix for 2.6.31 not 2.6.30 since it seemed to be needed for new things like the TWL4030 4 channel mode and the existing boards were apparently OK in 2.6.29. Do you think it's urgent enough to pull over to 2.6.30 (I've not pushed to Takashi yet)?
I would say my two 2.6.30-rc2 patches are for 2.6.30 since DSP_B is broken there and at least OSK5912 is using it.
I also believe that quite many developers may be using linux-omap tree only for developing e.g. new machine or codec driver and there is a risk that then error might populate into those drivers as well and we don't catch it when patches are based on topic/asoc and sent here for review.
Jarkko
On Thu, Apr 16, 2009 at 12:56:42PM +0300, Jarkko Nikula wrote:
I also believe that quite many developers may be using linux-omap tree only for developing e.g. new machine or codec driver and there is a risk that then error might populate into those drivers as well and we don't catch it when patches are based on topic/asoc and sent here for review.
*sigh*, that's true - a lot of the OMAP folks don't seem to want to move outside of linux-omap so I'd expect a lot of stuff wouldn't get pushed here at all. I've pulled the changes over.
On Thu, 16 Apr 2009 12:07:01 +0200 ext Mark Brown broonie@sirena.org.uk wrote:
I also believe that quite many developers may be using linux-omap tree only for developing e.g. new machine or codec driver and there is a risk that then error might populate into those drivers as well and we don't catch it when patches are based on topic/asoc and sent here for review.
*sigh*, that's true - a lot of the OMAP folks don't seem to want to move outside of linux-omap so I'd expect a lot of stuff wouldn't get pushed here at all. I've pulled the changes over.
Yes true, it has been previously junkyard for all kind of code but luckily this is changing and linux-omap is gradually moving towards queue for mainline since Tony is not accepting code anymore outside of OMAP core :-)
Jarkko
On Wed, 15 Apr 2009 14:38:54 +0200 "Ujfalusi Peter (Nokia-D/Tampere)" peter.ujfalusi@nokia.com wrote:
But, the DSP modes should use single-phase mode instead of the dual-phase mode, which is intended to be used with I2S, Left-justified, Right-justified modes.
At quick testing seems correct with Beagle but I'll give some more testing tomorrow and let you know.
The second patch adds DSP_A mode support to omap-mcbsp.
This looks ok.
Jarkko
On Wed, Apr 15, 2009 at 6:37 PM, Jarkko Nikula jarkko.nikula@nokia.com wrote:
On Wed, 15 Apr 2009 14:38:54 +0200 "Ujfalusi Peter (Nokia-D/Tampere)" peter.ujfalusi@nokia.com wrote:
But, the DSP modes should use single-phase mode instead of the dual-phase mode, which is intended to be used with I2S, Left-justified, Right-justified modes.
At quick testing seems correct with Beagle but I'll give some more testing tomorrow and let you know.
I'll also try to test it on osk5912, i m trying to get a proper commit to test on l-o tree.
The second patch adds DSP_A mode support to omap-mcbsp.
This looks ok.
Jarkko _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Wed, Apr 15, 2009 at 04:07:59PM +0300, Jarkko Nikula wrote:
At quick testing seems correct with Beagle but I'll give some more testing tomorrow and let you know.
The second patch adds DSP_A mode support to omap-mcbsp.
This looks ok.
I'll apply the second patch and hold off on the first until Jarkko has a chance to test - thanks.
On Wed, Apr 15, 2009 at 04:22:59PM +0100, Mark Brown wrote:
I'll apply the second patch and hold off on the first until Jarkko has a chance to test - thanks.
Actually, the two depend on each other so I'll hold off on the second one too for now.
participants (4)
-
Arun KS -
Jarkko Nikula -
Mark Brown -
Peter Ujfalusi