• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Embedded Software » Linux » Linux forum » Linux, sound on McASP : external MCLK, CPU generates WCLK and BCLK, slave codec(s), full duplex issues
Share
Linux
  • Forum
Options
  • Subscribe via RSS
Resources
  • Keystone II MCSDK (A15 Linux) Download
  • Linux, sound on McASP : external MCLK, CPU generates WCLK and BCLK, slave codec(s), full duplex issues

    Linux, sound on McASP : external MCLK, CPU generates WCLK and BCLK, slave codec(s), full duplex issues

    This question is not answered
    J��r��me Carretero
    Posted by J��r��me Carretero
    on Apr 30 2012 09:54 AM
    Prodigy20 points

    Hi, 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.

    Linux is v3.3; at the moment, 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:

    diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
    index 95441bf..167d5cf 100644
    --- a/sound/soc/davinci/davinci-mcasp.c
    +++ b/sound/soc/davinci/davinci-mcasp.c
    @@ -461,6 +496,21 @@ static int davinci_mcasp_set_dai_fmt(struct snd_soc_dai *cpu_dai,
                    mcasp_clr_bits(base + DAVINCI_MCASP_PDIR_REG,
                                    ACLKX | AHCLKX | AFSX | ACLKR | AHCLKR | AFSR);
                    break;
    +       
    +       case SND_SOC_DAIFMT_EM_CBS_CFS:
    +               /* external master clock, cpu generates bit and frame clocks */
    +               mcasp_clr_bits(base + DAVINCI_MCASP_AHCLKXCTL_REG, AHCLKXE);
    +               mcasp_set_bits(base + DAVINCI_MCASP_ACLKXCTL_REG, ACLKXE);
    +               mcasp_set_bits(base + DAVINCI_MCASP_TXFMCTL_REG, AFSXE);
    +
    +               mcasp_clr_bits(base + DAVINCI_MCASP_AHCLKRCTL_REG, AHCLKRE);
    +               mcasp_set_bits(base + DAVINCI_MCASP_ACLKRCTL_REG, ACLKRE);
    +               mcasp_set_bits(base + DAVINCI_MCASP_RXFMCTL_REG, AFSRE);
    +
    +               mcasp_clr_bits(base + DAVINCI_MCASP_PDIR_REG, AHCLKX | AHCLKR);
    +               mcasp_set_bits(base + DAVINCI_MCASP_PDIR_REG, ACLKX | ACLKR);
    +               mcasp_set_bits(base + DAVINCI_MCASP_PDIR_REG, AFSX | AFSR);
    +               break;
     
            default:
                    return -EINVAL;
    


    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:

    diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
    index 95441bf..167d5cf 100644
    --- a/sound/soc/davinci/davinci-mcasp.c
    +++ b/sound/soc/davinci/davinci-mcasp.c
    @@ -291,6 +292,9 @@
     
     #define DAVINCI_MCASP_NUM_SERIALIZER   16
     
    +static int playing = 0;
    +static int recording = 0;
     static inline void mcasp_set_bits(void __iomem *reg, u32 val)
     {
            __raw_writel(__raw_readl(reg) | val, reg);
    @@ -346,6 +355,12 @@ static void mcasp_start_rx(struct davinci_audio_dev *dev)
     
            mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLR_REG, RXSMRST);
            mcasp_set_ctl_reg(dev->base + DAVINCI_MCASP_GBLCTLR_REG, RXFSRST);
    +
    +       if (!playing) {
    +               pr_debug("%s: also starting tx\n", __func__);
    +               mcasp_start_tx(dev);
    +       }
    +
     }
     
     static void mcasp_start_tx(struct davinci_audio_dev *dev)
    @@ -384,23 +406,36 @@ static void davinci_mcasp_start(struct davinci_audio_dev *dev, int stream)
                            mcasp_set_bits(dev->base + DAVINCI_MCASP_WFIFOCTL,
                                                                    FIFO_ENABLE);
                    mcasp_start_tx(dev);
    +               playing = 1;
            } else {
                    if (dev->rxnumevt)      /* enable FIFO */
                            mcasp_set_bits(dev->base + DAVINCI_MCASP_RFIFOCTL,
                                                                    FIFO_ENABLE);
                    mcasp_start_rx(dev);
    +               recording = 1;
            }
     }
     
     static void mcasp_stop_rx(struct davinci_audio_dev *dev)
     {
    +       recording = 0;
    +       pr_debug("%s\n", __func__);
            mcasp_set_reg(dev->base + DAVINCI_MCASP_GBLCTLR_REG, 0);
            mcasp_set_reg(dev->base + DAVINCI_MCASP_RXSTAT_REG, 0xFFFFFFFF);
    +       if (!playing) {
    +               pr_debug("%s: not playing, shutting down tx too\n", __func__);
    +               mcasp_set_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, 0);
    +       }
     }
      
     static void mcasp_stop_tx(struct davinci_audio_dev *dev)
     {
    -       mcasp_set_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, 0);
    +       playing = 0;
    +       pr_debug("%s\n", __func__);
    +       if (!recording) {
    +               pr_debug("%s: not recording, shutting down\n", __func__);
    +               mcasp_set_reg(dev->base + DAVINCI_MCASP_GBLCTLX_REG, 0);
    +       }
            mcasp_set_reg(dev->base + DAVINCI_MCASP_TXSTAT_REG, 0xFFFFFFFF);
     }
    
    @@ -641,11 +691,21 @@ static void davinci_hw_param(struct davinci_audio_dev *dev, int stream) # wrong numbers
     
            mcasp_clr_bits(dev->base + DAVINCI_MCASP_ACLKXCTL_REG, TX_ASYNC);
     
            if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
    -               /* bit stream is MSB first  with no delay */
    +               /* bit stream is MSB first with no delay */
                    /* DSP_B mode */
    +               /* HACK: disable master transmit clock generation
                    mcasp_set_bits(dev->base + DAVINCI_MCASP_AHCLKXCTL_REG,
                                    AHCLKXE);
    +               */
                    mcasp_set_reg(dev->base + DAVINCI_MCASP_TXTDM_REG, mask);
                    mcasp_set_bits(dev->base + DAVINCI_MCASP_TXFMT_REG, TXORD);
     @@ -661,13 +721,22 @@ static void davinci_hw_param(struct davinci_audio_dev *dev, int stream)
                    /* bit stream is MSB first with no delay */
                    /* DSP_B mode */
                    mcasp_set_bits(dev->base + DAVINCI_MCASP_RXFMT_REG, RXORD);
    +               /* HACK: disable master receive clock generation
                    mcasp_set_bits(dev->base + DAVINCI_MCASP_AHCLKRCTL_REG,
                                    AHCLKRE);
    +               */
                    mcasp_set_reg(dev->base + DAVINCI_MCASP_RXTDM_REG, mask);
     
    -               if ((dev->tdm_slots >= 2) && (dev->tdm_slots <= 32))
    +               if ((dev->tdm_slots >= 2) && (dev->tdm_slots <= 32)) {
                            mcasp_mod_bits(dev->base + DAVINCI_MCASP_RXFMCTL_REG,
                                            FSRMOD(dev->tdm_slots), FSRMOD(0x1FF));
    +
    +                       if (!playing) {
    +                               /* HACK: generate frame sync for Tx too */
    +                               mcasp_mod_bits(dev->base + DAVINCI_MCASP_TXFMCTL_REG,
    +                                       FSXMOD(dev->tdm_slots), FSXMOD(0x1FF));
    +                       }
    +               }
                    else
                            printk(KERN_ERR "capture tdm slot %d not supported\n",
                                    dev->tdm_slots);
    
    

    We only plan to support 32kHz, so currently we have left an ugly hack in the code:

    diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c
    index 95441bf..167d5cf 100644
    --- a/sound/soc/davinci/davinci-mcasp.c
    +++ b/sound/soc/davinci/davinci-mcasp.c
    @@ -641,11 +691,21 @@ static void davinci_hw_param(struct davinci_audio_dev *dev, int stream)
     
            mcasp_clr_bits(dev->base + DAVINCI_MCASP_ACLKXCTL_REG, TX_ASYNC);
     
    +       /* UGLY: set clock divider, no support for frequencies != 32k
    +        *
    +        * We want 32kHz FCLK with 32bits (left, right) transferred for
    +        * every frame, so it makes a 1.024MHz BCLK (/8).
    +        */
    +       mcasp_mod_bits(dev->base + DAVINCI_MCASP_ACLKXCTL_REG, ACLKXDIV(8-1),
    +        ACLKXDIV_MASK);
    +
            if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
    

    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

    Currently I am reviewing the McASP code with regards to SPRUH77A (OMAP-L138 Technical Reference Manual), but some help would be appreciated.

    Regards,

    Linux OMAP-L138 MCASP
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    All Replies
    • J��r��me Carretero
      Posted by J��r��me Carretero
      on May 01 2012 09:49 AM
      Prodigy20 points

      I also posted this issue on alsa-devel: http://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/051613.html

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Mike Looijmans
      Posted by Mike Looijmans
      on Jul 27 2012 03:30 AM
      Intellectual930 points

      We are using the (Arago) linux kernel 2.6.37 (also labelled v2.6.37_DAVINCIPSP_03.21.00.04). There are several TLV320AIC3256 codec connected to an OMAP-L138 SoM board via I2C and McASP. The board is based on the DA850 EVM.

      To support the codec, I've backported the tlv320aic32x4 driver from the 2.6.39 linux kernel.

      The I2C part is configured correctly, and I can get and set mixer components and other settings via I2C to the codec.

      However, setting up the McASP data path is a complete riddle, and I need help to get this to work.

      In the board files, the following structs "glue" the codec to the audio data transfer unit:

      static struct snd_soc_dai_link da8xx_evm_dai[] = {
              {
                      .name = "TLV320AIC3X-1",
                      .stream_name = "AIC3X-1",
                      .cpu_dai_name= "davinci-mcasp.0",
                      .codec_dai_name = "tlv320aic32x4-hifi",
                      .codec_name = "tlv320aic32x4.11-0018",
                      .platform_name = "davinci-pcm-audio",
                      .init = evm_aic3x_init_analog,
                      .ops = &evm_ops,
              },
              {
                      .name = "TLV320AIC3X-2",
                      .stream_name = "AIC3X-2",
                      .cpu_dai_name= "davinci-mcasp.0",
                      .codec_dai_name = "tlv320aic32x4-hifi",
                      .codec_name = "tlv320aic32x4.12-0018",
                      .platform_name = "davinci-pcm-audio",
                      .init = evm_aic3x_init_analog,
                      .ops = &evm_ops,
              },
      

      The string "davinci-mcasp.0" refers to the struct in sound/soc/davinci/davinci-mcasp.c:

      static struct snd_soc_dai_driver davinci_mcasp_dai[] = {
              {
                      .name           = "davinci-mcasp.0",
                      .playback       = {
                              .channels_min   = 2,
                              .channels_max   = 2,
                              .rates          = DAVINCI_MCASP_RATES,
                              .formats        = SNDRV_PCM_FMTBIT_S8 |
                                                      SNDRV_PCM_FMTBIT_S16_LE |
                                                      SNDRV_PCM_FMTBIT_S32_LE,
                      },
                      .capture        = {
                              .channels_min   = 2,
                              .channels_max   = 2,
                              .rates          = DAVINCI_MCASP_RATES,
                              .formats        = SNDRV_PCM_FMTBIT_S8 |
                                                      SNDRV_PCM_FMTBIT_S16_LE |
                                                      SNDRV_PCM_FMTBIT_S32_LE,
                      },
                      .ops            = &davinci_mcasp_dai_ops,
      
              },

      And in the board config files, there is also a struct that configures the McASP ports:

      static u8 da850_iis_serializer_direction[] = {
              INACTIVE_MODE,  INACTIVE_MODE,  INACTIVE_MODE,  INACTIVE_MODE,
              INACTIVE_MODE,  INACTIVE_MODE,  RX_MODE,        TX_MODE,
              INACTIVE_MODE,  INACTIVE_MODE,  INACTIVE_MODE,  INACTIVE_MODE,
              INACTIVE_MODE,  INACTIVE_MODE,  INACTIVE_MODE,  INACTIVE_MODE,
      };
      
      static struct snd_platform_data da850_evm_snd_data = {
              .tx_dma_offset  = 0x2000,
              .rx_dma_offset  = 0x2000,
              .op_mode        = DAVINCI_MCASP_IIS_MODE,
              .num_serializer = ARRAY_SIZE(da850_iis_serializer_direction),
              .tdm_slots      = 2,
              .serial_dir     = da850_iis_serializer_direction,
              .asp_chan_q     = EVENTQ_1,
              .version        = MCASP_VERSION_2,
              .txnumevt       = 1,
              .rxnumevt       = 1,
      };
      
      ...
      da8xx_register_mcasp(0, &da850_evm_snd_data);
      

      Now this part is a complete mystery. To have multiple CODECs, do i need to register multiple instances of the McASP driver and fill in the serializer structs for each? And if not, how does it know which input is for which codec? And what are all the fields? There's no documentation whatsoever, so the above was my best guess to get at least one codec functioning. It sort of seems to do something, but all samples are zero and I get lots of overrun errors when using arecord to capture data from it.

      OMAP-L138 MCASP
      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    TI E2E™ Community
    • Support Forums
    • Blogs
    • Videos
    • Groups
    • Site Support & Feedback
    • Settings
    TI E2E™ Community Groups
    • TI University Program
    • Make the Switch
    • Microcontroller Projects
    • Motor Drive & Control
    Other Communities
    • Deyisupport
    • Designsomething.org
    • beagleboard.org
    • TI on Element 14
    • TI on TechXchangeSM
    Other Technical & Support Resources
    • WEBENCH® Design Center
    • Product Information Centers
    • Technical Documents
    • TI Design Network
    • TI Technical Articles
    • TI Training

    All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

    Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

    Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
    TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

    TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
    embedded processors, along with software, tools and the industry’s largest sales/support staff.

    © Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
    Trademarks | Privacy Policy | Terms of Use