On Tue, 2009-01-13 at 11:02 +0200, Jarkko Nikula wrote: > 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)? I was talking about the initilization procedure only. Sorry for the open door for misinformation. > 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. > That would be definitely a nice feature. Possibly something that cannot be fixed in 2420? (Maybe the XCCR and RCCR come to save the case). > But something is clearly wrong why DMA transfer now sometimes starts at > random edge? And why it seems to affect only playback, not capture? I've tried also to use 32bit DMA transfers unsuccessfully. (as TRM has a note that no less than 32 bit transfers should be used for McBSP). Unsuccessfully meaning it still gets out of L/R sync. Hmm. Interesting, if it doesn't affect the capture; but it's somewhat different in the McBSP, possibly behaving differently. Something to be discussed with TI I guess... -- 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
