Jarkko Nikula wrote:
On Mon, 15 Jun 2009 15:22:34 +0200
Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> 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 linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
