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 alsa-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
