One note of clarification: As mentioned in the email above, the only "non-standard" piece to this signaling is likely the "long frame sync". As shown on the modem's timing diagram (posted on the E2E forums here: http://e2e.ti.com/resized-image.ashx/__size/550x0/__key/CommunityServer-Discussions-Components-Files/447/2476.clk_5F00_fs_5F00_timing.jpg), the FS pulse is active (high) for 16 bits and then low for another 16 bits. At 8kHz, that makes the frame period 125us. All TX and RX happens simultaneously while FS is active (high), and _nothing_ happens while it is low. We have interpretted this as requiring a frame width (FWID) of 16 [well, 15+1 in the McBSP] and a frame period (FPER) of 32 [or, 31+1 in the McBSP]. Since the AM3517 is a slave, however, we do not expect to need the SRG. So we're not sure how important these variables are to the McBSP config. Should other settings be used? We have studied the /sound/soc/omap/omap-mcbsp.c file in great detail, and the only place we can see a possible misconfiguration for us is in the calculation of framesize, which Linux uses to setup FWID and FPER. In the existing code, framesize is calculated as "wlen * channels". So, for a mono signal like ours, our frame ends up only 16 bits wide, not 32. We're not sure how big of deal this is, as if the code is simply looking for the rising edge of the FS pulse, then it should not matter how long the FS is down for before going high again. Regardless, for testing, we forced the framesize calculation on line 373 of omap-mcbsp.c to be: framesize = wlen * 2; // 32 We have tried our setup with both the modified and unmodified versions of omap-mcbsp.c, and in both cases TX works great and RX returns only silence (0x00 samples). Any help would greatly be appreciated. Thanks in advance. -- 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
