Hi On Tue, 26 May 2009 15:17:23 +0200 Janusz Krzysztofik <jkrzyszt@xxxxxxxxxxxx> wrote: Grr, these McBSP bits are always almost un-readable :-) > 4. the following McBSP register settings changes: > > - .xcr2 = XPHASE | XFRLEN2(OMAP_MCBSP_WORD_8) | > - XWDLEN2(OMAP_MCBSP_WORD_16) | XDATDLY(0) | XFIG, > + .xcr2 = XPHASE | XWDLEN2(OMAP_MCBSP_WORD_16) | XFRLEN2(0), > XFIG is only difference (OMAP_MCBSP_WORD_8 = 0) -> transfer is aborted in case of unexpected frame sync. > - .srgr1 = FWID(DEFAULT_BITPERSAMPLE - 1), > + .srgr1 = CLKGDV(0), > Width of frame sync signal set to 1 here -> DSP_B format because no data delay set. > - .srgr2 = GSYNC | CLKSP | FSGM | FPER(DEFAULT_BITPERSAMPLE * > 2 - 1), > + .srgr2 = GSYNC, > > - .pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ > No CLKXM, CLKRM and FSGM set -> codec is providing the frame sync and bit-clock signals -> SND_SOC_DAIFMT_CBM_CFM. CLKXP and CLKRP not set -> rising edge of bit clock drives the transitions. This with DSP_B indicates inverted bit clock so SND_SOC_DAIFMT_IB_NF. I wonder why the frame sync period (FWID) wasn't set in that original patch but probably McBSP is able to work without :-) > safely access the device, however it does not work as expected. aplay > and arecord wait forever, cat to/from /dev/dsp breaks with hardware > error messgae. DMA interrput counters stay at 0. However, codec Looks like McBSP is not getting bit-clock and frame-sync signals from the codec. Do you have any way to measure is the codec sending those? Another possibility are the OMAP pins muxed for McBSP? I assume they are if the bootloader is still the same but worth to find check was previous kernel doing any runtime remuxing for those pins with omap_cfg_reg calls. > First of all, I'd like to make sure if my problem is related to my > code only. As I am new in these areas, I would like to ask you if the > omap asoc framework is stable enough to relay on. If yes, could you > please look at my dirty code (attached) an give me some hints? I can > provide you with more information if necessary. > I hope it's stable enough for you to get going. It would be nice to get this working since it would be the first OMAP5910 == OMAP1510 based machine driver. OMAP1510 doesn't support DMA chaining so there are few cpu_is_omap1510() code snippets in sound/soc/omap/omap-pcm.c which I think I have only simulated using OMAP2420. -- 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
