On Tue, 13 Jan 2009 10:41:20 +0200 Eero Nurkkala <ext-eero.nurkkala@xxxxxxxxx> wrote: > On Tue, 2009-01-13 at 10:28 +0200, Jarkko Nikula wrote: > > This doesn't fix problem on 2420. I assume when it works on 2420, the > > same fix will fix the 34xx as well. I fear the mcbsp initialization > > procedure in omap_mcbsp_start is not correct somewhat for 2420-34xx. > > I somewhat disagree. I think this works OK, just fine. > The "feature" appears, especially if codec (aic) is a master. > For me, the omap_mcbsp_xmit_enable and omap_mcbsp_recv_enable looks null op for 2420 so how it can fix problem on N810 (it has AIC33 as a master)? > One cannot say in which state the WCLK (provided by aic) is. > Aic is started prior to McBSP, right? > So when the DMA transfer starts, the WCLK may be about > (depending on CPU load etc) to transition down, and then the L > data goes into R data. As the BCLK clocks in the data. Right? > Channel switching is easy to measure just by looking when playing L or R data only, that data transfer is started at random WCLK polarity. If it works, then e.g. left channel data should visible only in low-level of WCLK when using I2S (+1 bit delay). IMO, it's task of McBSP block to synhronize properly independently is the McBSP master or slave for WCLK and to not start DMA transfer at random edge like it's doing now sometimes. But something is clearly wrong why DMA transfer now sometimes starts at random edge? And why it seems to affect only playback, not capture? Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
