[alsa-devel] Please help in adding ams-delta support to ASoC
jkrzyszt at tis.icnet.pl
Sat Jun 6 00:28:00 CEST 2009
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
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
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?
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?
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
More information about the Alsa-devel