[alsa-devel] Please help in adding ams-delta support to ASoC

Commit Message

Peter Ujfalusi June 10, 2009, 10:53 a.m. UTC

On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote:
> Not only this. AFAICS, there is no way of specifying single phase stereo
> (with XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)).
> Isn't this required for correct DSP_A/DSP_B support?

Sure it is possible:
	format = mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK;
	wpf = channels = params_channels(params);
	switch (channels) {
	case 2:
		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:
	case 4:
		/* Set word per (McBSP) frame for phase1 */
		regs->rcr1	|= RFRLEN1(wpf - 1);
		regs->xcr1	|= XFRLEN1(wpf - 1);
		break;
	default:
		/* Unsupported number of channels */
		return -EINVAL;
	}

wpf = channels == 2, format is not I2S --> RFRLEN1(wpf - 1), XFRLEN1(wpf - 1), 
RFRLEN1(2 - 1), XFRLEN1(2 - 1)

>
> > But you should be able to use the playback with the current ASoC.
>
> Definitelly yes. I am aware that the above limitations have nothing to do
> with the main problem, as with current mcbsp code I should always be able
> to get some kind of noise at least using one of supported formats, as far
> as clocking is set up correctly.
>
> > --- a/arch/arm/plat-omap/dma.c
> > +++ b/arch/arm/plat-omap/dma.c
> > @@ -266,6 +266,8 @@ void omap_set_dma_transfer_params(int lch, int
> > data_type, int elem_count,
> >                 ccr &= ~(1 << 5);
> >                 if (sync_mode == OMAP_DMA_SYNC_FRAME)
> >                         ccr |= 1 << 5;
> > +               if (dma_trigger)
> > +                       ccr |= dma_trigger & 0x1f;
> >                 dma_write(ccr, CCR(lch));
> >
> >                 ccr = dma_read(CCR2(lch));
>
> Applied, sorry, did not help (with capture, unlike playback, set up for
> internal clocking for as much device isolation as possible).

I would have guessed this, since even when the DMA was not HW synced, it did 
not sent a single bit to the McBSP DXR1 register...

Just out of curiosity, can you try this one as well:

basically write 0xdb55 to the DXR1 register (0xdb55 is 1101101101010101)
With this, if McBSP is operating correctly you should be seeing this pattern 
going to the codec. If it does, than we have some problems with the McBSP/DMA 
cooperation, if this pattern is not seen on the bus, than the McBSP is not 
shifting data out for some reason.

>
> > I would expected that by just copying (I know that there are other things
> > involved) the old ALSA arm directory to the latest kernel and compiling
> > it should be working... It seams I was wrong.
>
> Anyway, if you find porting one or another framework, back or forward,
> helpfull in any way, just let me know, I can try.

I'm not sure if it could prove anything at the end. There are - I think - 
other moving parts, which can break things.

>
> Thanks,
> Janusz

Comments

Janusz Krzysztofik June 10, 2009, 12:20 p.m. UTC | #1

Peter Ujfalusi wrote:
> On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote:
>> Not only this. AFAICS, there is no way of specifying single phase stereo
>> (with XPHASE/RPHASE unset), 2 words per frame (XFRLEN1/RFRLEN1(2 - 1)).
>> Isn't this required for correct DSP_A/DSP_B support?
> 
> Sure it is possible:
> 	format = mcbsp_data->fmt & SND_SOC_DAIFMT_FORMAT_MASK;
> 	wpf = channels = params_channels(params);
> 	switch (channels) {
> 	case 2:
> 		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:
> 	case 4:
> 		/* Set word per (McBSP) frame for phase1 */
> 		regs->rcr1	|= RFRLEN1(wpf - 1);
> 		regs->xcr1	|= XFRLEN1(wpf - 1);
> 		break;
> 	default:
> 		/* Unsupported number of channels */
> 		return -EINVAL;
> 	}
> 
> wpf = channels == 2, format is not I2S --> RFRLEN1(wpf - 1), XFRLEN1(wpf - 1), 
> RFRLEN1(2 - 1), XFRLEN1(2 - 1)

OK, I see I have to update my base before commenting the code ;).

Thanks,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Janusz Krzysztofik June 10, 2009, 6:05 p.m. UTC | #2

Wednesday 10 June 2009 12:53:42 Peter Ujfalusi napisał(a):
> On Wednesday 10 June 2009 13:27:38 ext Janusz Krzysztofik wrote:
> Just out of curiosity, can you try this one as well:
>
> --- a/sound/soc/omap/omap-mcbsp.c
> +++ b/sound/soc/omap/omap-mcbsp.c
> @@ -191,6 +191,7 @@ static int omap_mcbsp_dai_trigger(struct
> snd_pcm_substream *substream, int cmd,
>         case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>                 if (!mcbsp_data->active++)
>                         omap_mcbsp_start(mcbsp_data->bus_id);
> +               omap_mcbsp_pollwrite(mcbsp_data->bus_id, 0xdb55);
>                 break;
>
> basically write 0xdb55 to the DXR1 register (0xdb55 is 1101101101010101)
> With this, if McBSP is operating correctly you should be seeing this
> pattern going to the codec.

Peter,

I am not sure how did you expect me to see this pattern. On a scope screen? 
Unforunatelly I had to return the scope this morning.

I have further modified the code like this:

@@ -25,6 +25,7 @@
 #include <linux/init.h>
 #include <linux/module.h>
 #include <linux/device.h>
+#include <linux/random.h>
 #include <sound/core.h>
 #include <sound/pcm.h>
 #include <sound/pcm_params.h>
@@ -186,7 +186,7 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream 
*substream, int cmd,
        struct snd_soc_pcm_runtime *rtd = substream->private_data;
        struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
        struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai->private_data);
-       int err = 0;
+       int i, err = 0;

        switch (cmd) {
        case SNDRV_PCM_TRIGGER_START:
@@ -191,6 +191,8 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream 
*substream, int cmd,
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
                if (!mcbsp_data->active++)
                        omap_mcbsp_start(mcbsp_data->bus_id);
+               for (i = 8000; i > 0; i--)
+                       omap_mcbsp_pollwrite(mcbsp_data->bus_id, (u16)random32
());
                break;

        case SNDRV_PCM_TRIGGER_STOP:

in hope I should be able to hear a noise for one second, shouldn't I.

> If it does, than we have some problems with the 
> McBSP/DMA cooperation, if this pattern is not seen on the bus, than the
> McBSP is not shifting data out for some reason.

Now aplay returns 1 second later than before, so I conclude the loop is 
processed correctly. However, I am not able to hear a single ripple nor see 
any error messages from omap_mcbsp_pollwrite() :(, so it looks like the 
latter is more probable.

Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -191,6 +191,7 @@  static int omap_mcbsp_dai_trigger(struct snd_pcm_substream 
*substream, int cmd,
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
                if (!mcbsp_data->active++)
                        omap_mcbsp_start(mcbsp_data->bus_id);
+               omap_mcbsp_pollwrite(mcbsp_data->bus_id, 0xdb55);
                break;