[alsa-devel] Please help in adding ams-delta support to ASoC
jkrzyszt at tis.icnet.pl
Tue Jun 16 16:43:53 CEST 2009
Jarkko Nikula wrote:
> On Mon, 15 Jun 2009 15:22:34 +0200
> Janusz Krzysztofik <jkrzyszt at 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
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
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.
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
More information about the Alsa-devel