Hi, Tired with hopeless looking for the correct mcbsp dai format, I took the oposite direciton, trying to break what Mark Underwood had managed to get working. Step by step, I got to exactly the same mcbsp register configuration as used in the reference osk board, reverting all changes that Mark could introduce, and the driver still worked as before. So it looks like playing with mcbsp dai format is not the way to solve the problem. Wednesday 27 May 2009 07:57:27 Peter Ujfalusi wrote: > This means that the McBSP module is not transmitting/receiving any data. > Which suggests that the clocking is not working in your setup. Check the > slave master mode for the codec. Now I think I understand better what you mean. However, I don't know any way of configuring the codec except for switching its pin connections from msbcp to modem chip and back. I can find nothing relevant in the original patch that could help. > Also worth checking the PIN configuration for the McBSP1 module, just in > case it is correct. Wednesday 27 May 2009 08:59:49 Jarkko Nikula wrote: > 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. So I am going to restart with checking if the original patch still works with the latest kernel version supporting omap-alsa. Thanks for your help so far. Any hints are still welcome. Cheers, Janusz -- 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
