[alsa-devel] davinci-mcasp - external MCLK, CPU generates WCLK and BCLK, slave codec(s), full duplex issues

[Jérôme Carretero]

Hi,

Note: I opened a thread on TI's E2E forums too, the thread is at:
   http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/185810.aspx
Linux is v3.3.

Repeating what I have put there:

- As we will be using multiple codecs on McASP, we have put the codecs as slaves.
  We are also using a 8.192MHz external master clock.
- We have patched davinci-mcasp.c to handle this mode ("SND_SOC_DAIFMT_EM_CBS_CFS"),
  and refer to it for the CPU DAI configuration in the machine driver.
- Our setup currently has an AIC3X codec, connected to the TX clocks of McASP.
  The RX clocks are not used, they are left hanging, so we need to enable the TX clocks even when recording.
- We only plan to support 32kHz, so currently we have left an ugly hack in the code.
- It almost works, but we have a nasty problem:

  - When performing a capture alone, the sound is recorded as expected
  - When performing a playback alone, no problem
  - When starting a playback then a capture, no problem
  - When starting a capture then a playback, the playback will hang,
    the stream won't accept more data; no perturbation on the recording side.

A review of the McASP code WRT/ SPRUH77A (OMAP-L138 Technical Reference Manual)
does not really help.

Now, I performed some tracing:

- patched the davinci-mcasp.c code, to trace register accesses
  See attached file.
  The patch also contains the differences explained on the e2e forum post.
- produced the "yes" file by running the "playback then capture" scenario:
   dmesg -c
   cat /dev/urandom | pv -B 3200 | aplay -f S16 -r 32000
   aplay -B 20000 -f S16 -r 32000 -C -V mono /dev/null
   dmesg -c | gzip > yes.gz
- produced the "no" file by running the "capture then playback" scenario:
   dmesg -c
   aplay -B 20000 -f S16 -r 32000 -C -V mono /dev/null
   cat /dev/urandom | pv -B 3200 | aplay -f S16 -r 32000
   dmesg -c | gzip > no.gz

And I still have issues seing what could be wrong.

Could you somehow help me ?

Best regards,

-- 
cJ

PS: sorry for the resend, the initial message exceeded the allowed mailing list message size.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcasp-test.patch
Type: text/x-patch
Size: 27244 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120501/8cce0262/attachment-0001.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no.gz
Type: application/x-gzip
Size: 1296 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120501/8cce0262/attachment-0002.gz 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yes.gz
Type: application/x-gzip
Size: 1310 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120501/8cce0262/attachment-0003.gz