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

[Peter Ujfalusi <peter.ujfalusi@nokia.com>]

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:

--- 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. 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

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html