[alsa-devel] Please help in adding ams-delta support to ASoC

[Janusz Krzysztofik]

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
--
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