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

[Jarkko Nikula <jhnikula@gmail.com>]

On Wed, 3 Jun 2009 09:24:12 +0200
Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> wrote:

> Thanks! The origial driver with commented out clk_enable(vc_clk) and 
> clk_disable(vc_clk) still works for me, so MCLK is not required! If I
> only knew what to do with this finding...
> 
Optimize out one needless clock :-)

> > Just hack the same "static struct omap_mcbsp_reg_cfg mcbsp_regs =
> > { ..." in omap-mcbsp.c and pass that structure instead of
> > &mcbsp_data->regs to omap_mcbsp_config in omap_mcbsp_dai_hw_params.
> 
> Done. Did not help. Again, I really don't know how to make use of
> this finding except for looking in a different place.
> 
Ok, so looks that McBSP settings have nothing to do.

I got one another idea, quite far also, but omap_set_dma_params helper
function calls omap_set_dma_xxx_params functions in different order
than older sound/arm/omap/omap-alsa-dma.c: audio_set_dma_params_play.

While I don't believe that call order has something to do on 1510
versus other omaps, it's easy to try by changing call order in
arch/arm/plat-omap/dma.c: omap_set_dma_params.

Of course you could try to also copy transfer setup from
audio_set_dma_params_play into omap_pcm_prepare. Use prtd->dma_ch as
channel, runtime->dma_addr as a dma_ptr and
snd_pcm_lib_period_bytes(substream) as a dma_size. That should make the
DMA setup same than older implementation.

Hopefully these speculations would help you to find out at least one DMA
interrupt.


-- 
Jarkko