• State
  • Locked Locked
  • Replies 22 replies
  • Subscribers 101 subscribers
  • Views 3941 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.

4 wire PCM on AM335x

Peter T-Innova
Intellectual 640 points

Other Parts Discussed in Thread: TLV320AIC3106

Hello.

Have anyone experience, or knowledge, to tell if it should be easy to interface a 4 wire (clock, sync, Tx, Rx) PCM to AM335x? The device which I have in mind has both clock and sync output.

Br Peter

  • 0
    TI__Guru**** 393215 points
    Hi Peter,
     
    What you are looking for is a McBSP interface. The AM335X doesn't have any. It only has McASP, which supports I2S, TDM and S/PDIF. The AM35X and AM37X both have McBSP.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru 64655 points

    The McASP module in AM335x supports 2 - 32 TDM channels that can be used to transfer PCM data.  There should not be any issue with connecting the device you described.  Please refer to the McASP section of the TRM for more details.

    Regards,
    Paul

  • 0 in reply to peaves
    Intellectual 915 points

    HI Paul,

    I am trying to directly interface an AM335X processor to a cellular module with a digital audio PCM interface.  Is the process to call the ALSA PCM libraries like 

    What hardware pins would I use?  Ideally, I'd like to first test using a stock Beagle Bone Black running Debian/Ubuntu and the modem EVM board before a custom build.  Would the hardware need to be configured by a device tree overlay?  Any examples of how this might be done?

    I've found the McASP documentation rather detailed so something practical would be extremely useful.

    Best Regards

    Evan

  • 0 in reply to Evan Davey
    Expert 1510 points

    You can find detailed instructions on how to interface an audio device (like the one you are using) to the McASP in linux at the Sitara Linux Audio Page. I recommend reading all the of the sections in the Overview if you are not experienced with audio in linux. After that, look at the Porting Section, specifically the Audio DAC Example; it will guide you through the complete process of connecting an audio device to McASP.

  • 0 in reply to jelliott
    Intellectual 915 points
    Thanks for the link, I have studied all that. So is the process then to create a driver for the modem so that it will appear in Alsa in order to be able to treat it as a capture/playback device? I've been searching for an existing implementation of a 3G modem driver without any luck, surely I am not the first to try a digital voice call via a cellular module on linux?
  • 0 in reply to Evan Davey
    Expert 1510 points
    If you are able to find an existing driver for your device, then I would go with that. Otherwise, you can use that guide as a starting point. If you don't need a sophisticated ALSA driver to init your audio device (for instance, if some other process inits and it gets it ready to TX/RX data), then you could use a simple dummy driver to set up the McASP according to the basic parameters required by your device. In that guide I mentioned for 3.12 kernel, I simply made a template driver you can use. However, I believe there is a dummy codec driver that you may be able to utilize in the kernel that is DTS capable. I've never looked much into it, but I've seen it used before.
  • 0 in reply to jelliott
    Intellectual 915 points
    Ok, thanks. The dummy driver might be an option as it's likely the TX/RX will be externally controlled (i.e. via AT commands sent to the modem for dialling out / responding to an incoming call). Any idea where I might be able to research that? Have been digging around here without too much luck: www.kernel.org/.../sound
  • 0 in reply to Evan Davey
    Expert 1510 points
    I think this is a driver that will work for you:
    git.ti.com/.../simple-card.c

    Also keep in mind that the driver I made for the Audio DAC Example pretty does the exact same thing as simple-card--it's just separated as a new driver so that folks can use it as a base for making new drivers. So choose whatever will work best for your case.

    I actually worked on an issue similar to your situation, so I think this approach will work for you; for WiLink8, there is a i2s interface used to facilitate audio TX/RX for bluetooth. There is already an existing driver that configures WiLink8, so in this case we simply made a simple, external ALSA driver that assumed the i2s interface on WL8 was configured correctly, and just happily chugged away taking and sending data between the McASP <-> WL8 i2s.
  • 0 in reply to jelliott
    Intellectual 915 points
    Ok, thanks for your help. Yes, the WiLink8 situation sounds exactly the same, are you able to share that driver code? Otherwise, I will have a look at the simple-card driver .
  • 0 in reply to Evan Davey
    Expert 1510 points
    The WiLink8 code is the Audio DAC Example :)
  • 0 in reply to jelliott
    Intellectual 915 points
    Ok, thanks. But isn't that just one way? I guess it will be straight-forward enough to figure out how to make it bi-directional.
  • 0 in reply to Evan Davey
    Expert 1510 points
    Right, that example does just set-up McASP TX, but RX is very similar, so the steps will still apply.
  • 0 in reply to jelliott
    Intellectual 915 points

    So I have been digging into this a little deeper using the AM335X starter board as an example

     

    Here the WLAN/BT module (LBEE5ZSTNC-523) has a 4 pin interface to the processor MCASP0 where ACLKXX = MCLK, AXR0 = DOUT, AXR1 = DIN and FXS = WCLK (page 8 of the schematic).

    Where I am now getting lost is finding where the processor is configured in the device tree overlays to talk to this module.  I've looked at the TI SDK inside arch/arm/boot/dts/am335x-evmsk.dts but can't find anything obvious in there, am I looking in the right place?

  • 0 in reply to Evan Davey
    Expert 1510 points

    One thing you might want to review is that ACLK is equivalent to the Bit Clock (BCLK), and AHCLK is equivalent to the Master Clock (MCLK), which is the clock source from which BCLK and WCLK are derived. This diagram gives a simple example.

    As far as how to configure the processor side (McASP), it has to be done in both in the DTS and the davinci-evm.c in the ALSA SoC source. This page has a short overview. Also, this section of the Audio DAC guide gives an example of how to set up the McASP for a new device, with respect to davinci-evm.c and the dts.

  • 0 in reply to jelliott
    Intellectual 915 points
    Thanks, that helps a little. What I am still missing is how the AM335X Starter Kit sets up McASP for the WLAN/BT module (McASP0) and TLV320AIC3106 (McASP1). I had a dig around inside devinci-evm.c but couldn't find where this might be happening.
  • 0 in reply to Evan Davey
    Expert 1510 points
    Ah OK, I see what you're looking for now--unfortunately, in the SDK, the McASP is not set up at all for WiLink--it's only set up for AIC3106, so you'll only find references to that setup in dts/davinci-evm.
  • 0 in reply to Evan Davey
    Expert 1510 points

    Btw, here's a link for the am335x-evmsk dts that at which I'm looking. The "sound", "mcasp1", and "tlv320aic3106: tlv320aic3106@1b" entries are the ones that are used to set up mcasp -> aic3106, as well as the relevant pinmuxing blocks.

  • 0 in reply to jelliott
    Intellectual 915 points
    Ah, thanks, so not supported yet then! I (mostly) get the mcasp1 bit (with your help) but didn't understand mcasp0, and that's what I was looking for as it is closest to what I am trying to do. So I think the procedure it to define the pins muxing for mcasp0/mcasp1 then later hook mcasp0 into the driver we create (while mcasp1 in our case will go through a TLV320AIC3106).

    For the configuration, I can't find any clear documentation on the meaning of the sections below:
    tdm-slots = <2>;
    /* 16 serializer */
    serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
    1 0 0 0
    >;
    tx-num-evt = <32>;
    rx-num-evt = <32>;

    I assume tdm-slots = 2 means two channels i.e. left and right for stereo? But not sure about the format of serial-dir or what tx[rx]-num-evt mean.

    On a slightly different topic, one thing also still confusing me is the audio routing part, specifically for the TLV320AIC3106. How does the audio routing in the dts differ from the audio routing that would be defined in ALSA mixer using the widgets (by directing the DAC paths etc.)? Where are the labels for the sources/sinks defined, and what impact does this have?
  • 0 in reply to Evan Davey
    Intellectual 915 points

    I should add that I have looked here: www.kernel.org/.../davinci-mcasp-audio.txt but trying to understand that. For example, I don't get what the serial-dir list is actually referring to, or why I would set tx-num-evt to a particular value.

    Is the serial-dir related to the pin mix?

    mcasp1_pins: mcasp1_pins {
    pinctrl-single,pins = <
    0x10c (PIN_INPUT_PULLDOWN | MUX_MODE4) /* mii1_crs.mcasp1_aclkx */
    0x110 (PIN_INPUT_PULLDOWN | MUX_MODE4) /* mii1_rxerr.mcasp1_fsx */
    0x108 (PIN_OUTPUT_PULLDOWN | MUX_MODE4) /* mii1_col.mcasp1_axr2 */
    0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4) /* rmii1_ref_clk.mcasp1_axr3 */
    >;
    };

    Since this has been defined then we have 4 possible pins, and pin 3 is TX and pin 4 is rx?

    serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
    0 0 1 2
    >;

  • 0 in reply to Evan Davey
    Expert 1510 points

    The serial-dir is seperate from the pinmux--it controls whether the McASP will use a specific serial line (AXRn) as an input or an output.

    Evan Davey said:
    Since this has been defined then we have 4 possible pins, and pin 3 is TX and pin 4 is rx?

    Yup, that's correct.

    Evan Davey said:
    I assume tdm-slots = 2 means two channels i.e. left and right for stereo?

    Yup.

    Evan Davey said:
    or what tx[rx]-num-evt mean.

    Here's some info: http://processors.wiki.ti.com/index.php/Linux_Core_Audio_User%27s_Guide#If_there.27s_an_issue

    As far as the audio routing, unfortunately I am not too knowledgeable about that, so there's not much help I can offer.

  • 0 in reply to jelliott
    Intellectual 915 points
    OK, no worries. Thanks very much for your help!!
  • 0 in reply to Evan Davey
    Expert 1510 points

    No problem at all. Let me know if you have any other questions and I'll do my best to help. I have been wanting to look into the dapm audio routing stuff, so if I get some time I'll dig into and let you know anything valuable I learn.