[alsa-devel] Please help in adding ams-delta support to ASoC

[Janusz Krzysztofik]

Hi Jarkko,

Thank you for still trying to support my efforts.

Friday 05 June 2009 15:55:31 Jarkko Nikula napisał(a):
> Optimize out one needless clock :-)

:-)

> Ok, so looks that McBSP settings have nothing to do.

That was what I was suggesting before as well, but now I'm back not so sure.

> 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... That should make the
> DMA setup same than older implementation.
>
> Hopefully these speculations would help you to find out at least one DMA
> interrupt.

Tried this all, and guess what? Still no signle dma interrupt :(.


I disassembled my device and got with osscilloscope probe inside. 
Unfortunatelly, it was not possible to check what was going on on omap pins, 
as those were hidden. However, I was able to look at codec and modem pins.

The codec master clock input has ~2MHz square wave applied. The same waveform 
can be found on the modem master clock output, so I think we can be sure that 
the codec gets its master clock from the modem. I am not able to verify If 
the same signal is applied on mcbsp1 master clock input.

There is ~330kHz square wave on the codec bit clock output. I was not able to 
verify if this signal appears on modem or mcbsp1 pins, as it should.

On the codec frame sync output, I can see ~10kHz symmetric square wave (filled 
by 50%), the same on modem frame sync input, mcbsp1 status unknown. This 
shape suggests I2S protocol, not DSP_B as we deduced from the original driver 
code.


Reviewing the code of different asoc omap drivers and mcbsp documentation 
again and again, several questions comes on mind, like:

1. What is the default setting for mcbsp master clock source? Assuming that 
default register bit values are 0, OMAP_MCBSP_SYSCLK_CLKS_EXT would be 
default for omap1, and there would be no default for others. Sources other 
than OMAP_MCBSP_SYSCLK_CLKS_EXT or OMAP_MCBSP_SYSCLK_CLKS_FCLK require 
setting of CLKSM and/or SCLKME to 1, and both OMAP_MCBSP_SYSCLK_CLKS_EXT and 
OMAP_MCBSP_SYSCLK_CLKS_FCLK require additional omap_ctrl_writel() calls on 
omap2 and higher. Am I missing anything?

2. Why omap asoc drivers, except for omap3pandora, do not call 
snd_soc_dai_set_sysclk(cpu_dai, ...)? Does it mean that osk9512 uses default 
OMAP_MCBSP_SYSCLK_CLKS_EXT? What does it mean for others without default?

and more.


Anyway, we still have at least two potential reasons for my driver not 
working: wrong mcbsp clocks setup or broken mcbsp dma handling. My last idea 
was to create a generic test driver that would not use any external clocks, 
ie configured with OMAP_MCBSP_SYSCLK_CLK and SND_SOC_DAIFMT_CBS_CFS, right? 
That way, it should just work without any hardware support except for mcbsp 
and maybe we could then definitelly verify if current mcbsp and dma code 
works on omap1510 or not. Trying to select a template driver to base the test 
driver on, I felt into these troubles with more and more questions coming on 
mind. If you think my idea is worth of trying, could you please look at this 
and give me some hints?

Cheers,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe alsa-devel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html