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

[Peter Ujfalusi]

Hello Janusz,

On Saturday 06 June 2009 20:42:12 ext Janusz Krzysztofik wrote:
> I'm not sure how that could happen, but I was wrong with some of those
> figures. After looking at the scope several more times I can only confirm
> that master clock really runs at 2MHz (0,5µs period). Frame sync is rather
> closer to 8kHz (~125µs period) than previously estimated 10kHz, with the
> same symmetric (50% fill) shape as before. But bit clock is very different
> from what I have seen before. It runs at 2MHz in 9µs long packets (18
> periods), those are repeated every half period of frame sync (~62µs /
> 16kHz), ie every frame sync edge, both rising and falling. There is also a
> signal present on codec data output: 4µs long packets (8 bits each?) every
> ~62µs (16 kHz).

I'm kind of bad at visualizing things, is it possible to put somewhere the 
screenshoot of the scope showing at least one sample?

>
> Is it possible that the codec speeks I2S, with 8-bit word, 1 word per
> frame, 2 channels at 8kHz each? Or 1 channel at 16 kHz? From what I can
> read in modem documentation, this should rather be one 8-bit channel at
> 8kHz. Anyway, can the transmission format I have seen ont the oscilloscope
> be matched against any format that mcbsp can be set with current code?

I have been looking for clues around the net, and it seams that the codec in 
question has stereo 16 bit format.

>
> I'm still far from understanding mcbsp, but I wonder what happens if the
> bit clock stops ater 18th bit while maybe mcbsp expects more. Perhaps this
> is the cause of dma interrupts not being generated?
>

Without actual OMAP1510 HW it is really hard to tell what can be the problem.
What I would do, if I had a HW:
1) See if the DMA actually was running and it is 'just' about the missing 
interrupt:
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -193,11 +193,15 @@ static int omap_pcm_trigger(struct snd_pcm_substream 
*substream, int cmd)
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
                prtd->period_index = 0;
                omap_start_dma(prtd->dma_ch);
+               printk("omap_pcm_trigger START: DMA pointer at 0x%08x\n",
+                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
                break;

        case SNDRV_PCM_TRIGGER_STOP:
        case SNDRV_PCM_TRIGGER_SUSPEND:
        case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+               printk("omap_pcm_trigger STOP: DMA pointer at 0x%08x\n",
+                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
                prtd->period_index = -1;
                omap_stop_dma(prtd->dma_ch);
                break;


Than start a playback, and stop it with CTRL+C, see if the two pointers are 
different...

2) I would I think try to port the 2.6.28 pure ALSA version to the head of l-
o, with minimal (only the needed) changes and see if it is still working.
I know, this is a long shot, but at least we can be sure, that the problem is 
in the ASoC McBSP/DMA integration or it is something else.

Meanwhile I'll try to locate one OMAP1510 based board to try to help with this 
issue.

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