Jarkko Nikula wrote:
On Mon, 15 Jun 2009 15:22:34 +0200 Janusz Krzysztofik jkrzyszt@tis.icnet.pl wrote:
- original patch ported to the last l-o commit supporting omap-alsa:
- playback: works as before,
- capture: both </dev/dsp and arecord give null output, but DMA interrupts still work.
Not that I would see it as a real progress, but to clarify things: I have managed to solve this particular problem with capture by patching sound/arm/omap/omap-alsa.c (call omap_get_dma_dst_pos() instead of omap_get_dma_src_pos() from audio_get_dma_pos() in case of (stream_id == SNDRV_PCM_STREAM_CAPTURE)). The original code stopped working after changes introduced to omap_get_dma_src_pos() with this patch: http://marc.info/?l=linux-omap&m=121280267705523.
Nice step forward. From quick look of the patch I see that patch is changing how the source and destination positions are read for omap1.
While I don't have idea can this explain the ceased DMA in 1510 but will the playback in original code work again if you change line "offset = dma_read (CPC(lch));" to "offset = dma_read(CSSA_L(lch));" in omap_get_dma_src_pos? Or read both CSSA_L and CSSA_U at once like code before?
Yes, it will, and even better than before, without undesirable scraps repeated at the end. But that does not help in getting the new driver handle mcbsp/dma correctly :(.
I can confirm that the old driver can set up mcbsp in a way that keeps it shifting the contents of its input register, loaded with a pattern using omap_mcbsp_pollwrite() as Peter suggested, even if I break dma by commenting out all omap_start_dma() invocations. I have verified this by detecting averaged voltage level changes on the codec input pin with a simple multimeter (I still have not get access to a scope back).
Using the new driver, I am not able to detect similiar voltage changes, whatever I do to get the mcbsp sending data to the codec over its serial output. I have modified omap-mcbsp code with a hacked in probe hook that initializes mcbsp at boot time exactly as the old driver does it - no results.
After all, it is more and more likely that the problem is not dma, but mcbsp just not shifting any data for some mysterious reason.
Thanks, Janusz -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html