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_______________________________________________Alsa-devel mailing listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
