Hi Jarkko,
Jarkko Nikula wrote:
On Mon, 1 Jun 2009 21:04:13 +0300 Jarkko Nikula jhnikula@gmail.com wrote:
Hmm, I forgot one major difference. Older implementation was transferring the buffer by transferring periods by own DMA transfers while ASoC implementation is transferring the whole buffer by single transfer but letting DMA to generate interrupts at period boundaries but this should be supported by the 1510 as well.
I am not sure if this is of any importance, but with the old working code, playing /dev/urandom to /dev/dsp I get only 3-4 DMA interrupts per second, while doing the same on a x86_64 via82cxxx results in 40-50 device interrupts per second.
I just tried non-chained transfer, i.e. restarting DMA after buffer is transferred in omap-pcm.c by using N810 and 2420 and it worked as I was recalling. This was simulating 1510 by adding (1 || cpu_is_omap1510) or (0 && !cpu_is_omap1510()) where 1510 was tested.
But there is no DMA stop workaround before restarting like the original ams delta patch has.
The original patch had no extra omap_dma_stop(), but extra unconditional (form ams-delta point of view) omap_dma_start() inside omap_start_alsa_sound_dma(). Later on, there was an extra omap_stop_alsa_sound_dma() call introduced in audio_process_dma() as a workaround for a similiar problem found on other omap1510 machines, that cleared the flag preventing omap_start_alsa_sound_dma() from calling omap_dma_start(). I found that with the latter, the old driver happened to stop working after a while or two.
Could you try to add following line in omap-pcm.c does it help? However this doesn't explain why you are not getting any interrupts.
@@ -68,6 +68,7 @@ static void omap_pcm_dma_irq(int ch, u16 stat, void *data) if (prtd->period_index >= 0) { if (++prtd->period_index == runtime->periods) { prtd->period_index = 0;
omap_stop_dma(prtd->dma_ch); omap_start_dma(prtd->dma_ch); }
OK, I will.
the only reason of my driver not working I can imagine is that I have put these two lines of hardware related code in wrong places.
I don't think there is anything in a wrong place. It would help a lot if we would know for sure is the MCLK from OMAP to codec and McBSP FS and bit clocks from the codec really working since that is the first requirement for working transfer. Luckily we know that the HW is working :-)
And we know mcbsp settings that make it working.
I did not find any documentation on the codec itself, only on its "master" modem chip cx81801. Regarding modem<->codec interface, there were only pins with breif description specified for both chips, nothing more, as this interface was probably not intended for access from outside. From the codec side, it looks like this:
- Sleep (SLEEP); input - Master Clock (M_CLKIN); input - Serial Clock (M_SCK); output - Control (M_CNTRLSIN); input - Serial Frame Sync (M_STROBE); output - Serial Transmit Data (M_TXSIN); input - Serial Receive Data (M_RXOUT); output - Reset (POR); input
However, I can't tell which lines are switched from modem to mcbsp and which are kept connected to the modem chip all the time. Anyway, it looks like we can be sure that both bit clock and frame sync should come from codec to mcbsp. It is not clear for me if MCLK is really used by the codec, or it is possible that it gets its master clock from an other, modem related source, and if this does really matter.
At least one difference is that omap-mcbsp.c is constructing McBSP register bits itself while older implementation was passing raw register configuration from the board files. Probably you could try to hack omap_mcbsp_dai_hw_params and pass the same register settings there to see are there some missing bit in omap-mcbsp.c.
OK, I'll see if I know how to do this.
Cheers, 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