Hi Mark,
Saturday 06 June 2009 00:45:34 Mark Brown napisał(a):
On Sat, Jun 06, 2009 at 12:28:00AM +0200, Janusz Krzysztofik wrote:
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.
Not that this seems like an unreasonable conclusion but it's worth pointing out that the DSP modes only require the leading edge of the frame clock and that the falling edge can occur at any point before the next rising edge is due.
Right, thanks.
I'm not sure how that could happen, but I was wrong with some of those figures. After looking at the scope several more times I can only confirm that master clock really runs at 2MHz (0,5µs period). Frame sync is rather closer to 8kHz (~125µs period) than previously estimated 10kHz, with the same symmetric (50% fill) shape as before. But bit clock is very different from what I have seen before. It runs at 2MHz in 9µs long packets (18 periods), those are repeated every half period of frame sync (~62µs / 16kHz), ie every frame sync edge, both rising and falling. There is also a signal present on codec data output: 4µs long packets (8 bits each?) every ~62µs (16 kHz).
Is it possible that the codec speeks I2S, with 8-bit word, 1 word per frame, 2 channels at 8kHz each? Or 1 channel at 16 kHz? From what I can read in modem documentation, this should rather be one 8-bit channel at 8kHz. Anyway, can the transmission format I have seen ont the oscilloscope be matched against any format that mcbsp can be set with current code?
I'm still far from understanding mcbsp, but I wonder what happens if the bit clock stops ater 18th bit while maybe mcbsp expects more. Perhaps this is the cause of dma interrupts not being generated?
... 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...
That approach is one I use all the time in driver development - isolate the device as much as possible and confirm that it can at least interoperate with itself.
Thanks, I'll follow that way as soon as I get a hint from mcbsp experts.
Cheers, Janusz