• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 420 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP-L137 McASP audio driver GBLCTL readback question

Richard Tennis
Prodigy 250 points
Other Parts Discussed in Thread: OMAP-L137

In the latest Arago linux-davinci git kernel, the functions mcasp_start_rx() and mcasp_start_tx() in file

sound/soc/davinci/davinci-mcasp.c write to the GBLCTLR and GBLCTLX registers respectively and then read back from the same registers.

According to the McASP reference guide (sprufm1.pdf), section 2.4.1.4, the readback should be performed on the GBLCTL register. Which is the correct behavior. The audio works on the L137 EVM, but I wonder if that is just because the clocks are fast enough.   When I try to use much slower external clocks I get no output.

Richard.

  • 0
    TI__Genius 14545 points

    Richard Tennis said:
    The audio works on the L137 EVM, but I wonder if that is just because the clocks are fast enough.   When I try to use much slower external clocks I get no output.

     

    Richard,

      I think you are asking is more of a software issue, but I'll give you the hardware perspective. Since Audio is time sensitive, the McASP has internal logic to detect clock errors and/or glitches in clocks. If there is an error, it is expected that the audio is then corrupted, and will output a nasty sound via an amplifier or codec. For this reason, the McASP implements the functionality to ensure that the corrupt audio does not propogate downstream to a D/A device. This is accomplished through digitally muting the audio. (stream of zeros in the PCM code sequence for I2S for example). This is probably what you are detecting, so yes if the clocking is not configured correctly then you should expect to receive a digitally muted audio stream.

     

    The GBLCTRLR is an alias register of the Receive bits of the GBLCTR register. The GBLCTRLX is an alias register of the Transmit bits of the GBLCTR register. This is in the description of these registers in the OMAP-L137 Technical Reference Manual (McASP Chapter)

     

    Drew

  • 0 in reply to dabuan
    Prodigy 250 points

    Drew,

    Thank you for your insight. I am pretty sure now that the driver should be reading back the GBLCTL register instead of the TX and RX alias registers. I changed the code to do that and immediately got an error: "GBLCTL write error". After increasing the timeout period, the error went away.

    I am still not getting any output due to a frame sync error and the automatic digital muting you mentioned. The frame sync error I think is due to some initialization timing issues which I am still trying to fix.

    Richard.