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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html