[alsa-devel] Please help in adding ams-delta support to ASoC
jkrzyszt at tis.icnet.pl
Sat Jun 6 19:42:12 CEST 2009
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.
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.
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