Re: Please help in adding ams-delta support to ASoC

[Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>]

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