Two Audio-Codecs via McASP at AM335x

Hey Markus,

It should definitely be possible to interface two codecs to the AM335x.  If you want both of them to be independent in terms of the clocking and sampling rates, then you will probably want to use McASP0 for one and McASP1 for the other.  If you want them locked into the same clocks, then using one McASP and time division multiplexing should be fine.

What kernel are you using?  Are you using the TI AMSDK?  If so, what version?  I will try to dig up whatever relevant examples I can for you.

Regards,

Josh

Though it connects to the McASP's on a C674x-based DSP (or ARM9), the following board does interface multiple codecs and has links to schematics and test code:

http://www.spectrumdigital.com/product_info.php?&products_id=233&osCsid=b2a6f0a87e1def1dad517d65e64b17bf

I'm also a bit interested in this, especially hearing best-practices / prev. experiences from a clocking perspective as there are many options to solve this.

Basically I'd like to have the flexibility of running the system in both 44.1, 88.2 as well as 48, 96, 192k

My plan was to use McASP0 as master but with an external clock/osc/pll to achieve the above freq (as this is not possible with the built in PLL's/deviders) without SRC-needs. 

Preferably be able to run both a DAC in say 88.2 and at the same time an ADC on the same McAsp bus in 44.1.

Maybe more obvious to separate these to McAsp1 but my plan was to use McAsp1 as the master for the internal processing (code) so it slaves to it's sample-rate and still be reconfigurable to run either 44.1 or 48k.

Question is what external clocks to use. I've been looking at Silabs Si5351C that could be fed with the 24MHz master clock out (from the am335x) and then generate say 256fs for the DAC system-clock / i2s data. (ie 24.576MHz for 96kHz etc)

I also know there are some dedicated PLL IC's out there made for the purpose but would be great to get some input here.

/d

Hey Josh,

thanks for your answer. I have not gotten into compiling the Kernel yet. Preferrably I would like to ommit that, if possible. The kernel, I am using is the 3.8.13 from the current BeagleBone Black Angstrom distribution. The setup I need is:

- BeagleBone Black

- Two TLV320AIC3007

- One SPI-Bus and some GPIOs for ChipSelects left for configuration of other circuit components not related to this issue. 

Different sample rates are not necessary and optional. I would definietly like to go for the easiest solution. From what you have written it seems that I needed to use McASP0, McASP1 and SPI0 (the one with two CS) for the two audio codecs and the other SPI-bus for my other circuit components. A brief look on the BBB pinouts seems not to have any collision between McASP0, McASP1, SPI0 and SPI1. 

The big knowledge gap for me is in the device tree descriptions and the drivers to set all the options of the TLV320AIC3007. 

As I am getting just started, we can go step by step, if you advice me, which literature to dig in. I then can follow up with more specific questions during implementation phase.

Regards, 

Markus

Hey Markus,

I have been looking to the kernel provided by the BeagleBone folks and familiarizing myself with it, so I apologize for the delay.

As for where we should start, I think the best place to start would be in the following device tree files:

• kernel/arch/arm/boot/dts/am33xx.dtsi -- this file has definitions for both mcasp0 and mcasp1 as well as the spi which you will definitely want to to take a look at
• kernel/arch/arm/boot/dts/am335x-bone-common.dtsi -- this file has the pinmuxing and definitions for capes.

As an example for how to do the pinmuxing in the device tree, have a look at this sample code:

mcasp0_pins: mcasp0_pins {
pinctrl-single,pins = <
   0x1ac 0x30 /* mcasp0_ahclkx, MODE0 | INPUT */
   0x19c 0x02 /* mcasp0_ahclkr, */
   0x194 0x10 /* mcasp0_fsx, MODE0 | OUTPUT */
   0x190 0x00 /* mcasp0_aclkr.mcasp0_aclkx, MODE0 | OUTPUT_PULLDOWN */
    0x1a8 0x1f /* mcasp0_axr1 GPIO1_27 | OUTPUT | PULLUP */
>;

This should be a decent place to start.  I will keep giving you updates as I find new, useful information.

Regards,

Josh

Hey Markus,

I have a better idea of what you're going to need to do to get both McASPs up and running.  All the changes should be confined to the device tree.  When you update your device tree, you can just do a "make dtbs" in your kernel directory to get the new .dtb file, so you won't have to recompile the kernel.

Here are some code snippets the show how to enable the setup the McASP, aic3x, and (in this case i2c) in the device tree.  It should be a really great start for you:

Here is an example for the pinmuxing for mcasp1 (it says mcasp0, but it is actually mcasp1 I believe):

am335x_evm_audio_pins: am335x_evm_audio_pins {
      pinctrl-single,pins = <
        0x10c 0x24  /* mcasp0_aclkx.mcasp0_aclkx, INPUT | MODE4 */
        0x110 0x24  /* mcasp0_fsx.mcasp0_fsx,  INPUT | MODE 4*/
        0x108 0x4  /* mcasp0_ahclkr.mcasp0_axr2, OUTPUT | MODE4 */
        0x144 0x24  /* mcasp0_ahclkx.mcasp0_axr3, INPUT | MODE4 */
      >;
};

The I2C setup for the codec is done in a manner such as this:

tlv320aic3x: tlv320aic3x@1b {
        compatible = "ti,tlv320aic3x";
        reg = <0x1b>;
        status = "okay";
};

To set up the McASP, use this code as a baseline:

&mcasp1 {
    pinctrl-names = "default";
    pinctrl-0 = <&am335x_evm_audio_pins>;

    status = "okay";

    op-mode = <0>;          /* MCASP_IIS_MODE */
    tdm-slots = <2>;
    num-serializer = <16>;
    serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
      0 0 1 2
      0 0 0 0
      0 0 0 0
      0 0 0 0
    >;
    tx-num-evt = <1>;
    rx-num-evt = <1>;
};

Now we need to connect all of these pieces so that we can have a recognized sound card in linux:

sound {
      compatible = "ti,da830-evm-audio";
      ti,model = "DA830 EVM";
      ti,audio-codec = <&tlv320aic3x>;
      ti,mcasp-controller = <&mcasp1>;
      ti,codec-clock-rate = <12000000>;
      ti,audio-routing =
        "Headphone Jack",       "HPLOUT",
        "Headphone Jack",       "HPROUT",
        "LINE1L",               "Line In",
        "LINE1R",               "Line In";
};

Note that all this code can be used as a basis for either McASP0 or McASP1--just alter the values appropriately.  Let me know if this is helpful to you.

Regards,

Josh

Hello Josh,

thank you for your answers. I already have seen these code-bits in the BB-BONE-AUDI01*.dts. So What I will do over the next few weeks is make a cape which contains two TLV320AIC3007 on separate McASP, but the same I2C.

Then we can try to get it running together. Will keep you posted. 

Markus

Hi Josh,

I have news on the discussion: I built a cape which holds one TLV320AIC3007. The connections w.r.t. the Beagle Bone Black are exactly as Adafruits BeagleBone Audio Cape Rev B (http://elinux.org/CircuitCo:Audio_Cape_RevB). Unfortunately there is no dts-File provided yet from Adafruits. I played with the dts from Rev A Audio Cape and altered the connections accordingly. So far no luck. Also it is unclear to me, if I need to built the new ASOC driver.

The site

http://code.metager.de/source/history/linux/stable/sound/soc/codecs/tlv320aic3x.c

states some recent updates to the driver w.r.t. to TLV320AIC3007, which cannob be on my current Angstrom-distirbution (which is currently from somewhere June 2013).

So far I only had little time to try. I need to read up on how to compile the driver, I have no idea about that. Instructions and ideas welcome.

Regards,

Markus

P.S.: I try to post pictures of the board soon.

Hello Markus,

We recently released a new SDK that now includes 3.12 kernel, so we have made the switch to device tree.  There is a new page up for audio, which can found here.  The introduction and porting sections should be helpful to you, even though it sounds like you are using community 3.8 based package.  Let me know how it goes.

Regards,

Josh

Hi Josh,

Perhaps you can help me. I need to connect an ADS1278EVM to a Beaglebone Black (Angstrom, kernel 3.8) through the McASP port (FrameSync format).

Is it possible to accomplish this task using the device tree and the audio drivers? Of course there will be no codecs!

Can you give me some guidance?

Thanks in advance,

Levy 

Hi Levy,

This guide for interfacing a DAC to McASP should be of help to you:

http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_Audio_DAC_Example

Regards,

Josh

Hi, Josh,

I have already started the learning curve of EZLINUX SDK 7.0 and I will take a look at the "Audio DAC Example" soon. Thanks.

Let me ask you something else: I have created the sdcard with the SDK image and tried to copy it to the eMMC using the standard procedure (turned BBB on with the boot button pressed). That did not work and, after a while, I realized that BBB boots from the SDcard itself! What do I have to do to copy the SDK image to the eMMC and get rid of the SDcard?

Thanks in advance,

Levy

Hi Levy,

BBB should boot from on board eMMC by default unless it has a valid image from which to boot.  If you take out the SD card, then it will boot from eMMC.

Also, check out this wiki page: http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_Setup_Script#BeagleBone_Black_Users

Josh

Hi, Josh

Could you help me solve this question? Thank you!

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/361025/1274674.aspx#1274674

Whoops, sorry--I mispoke in that last comment. Your codec would use the same driver as those on the evms/capes.

Using the aic3007 should be very similar to how the aic3106 is used in the dts for the gp-evm in the current TI SDK. In the i2c driver node for codec, you can pretty much use the "tlv320aic3106" part as-is. Although, you should change the "compatible =" entry to  "ti,tlv320aic3007" (and also you can change other references to 3106 to 3007). Beyond that, your "sound" and mcasp nodes should pretty much stay the same (just be sure to change references to 3107 to 3007 like I just mentioned).

If you make those changes and your aic3x driver doesn't load, try using i2c-tools to see if you can communicate with codec at all. That tool should help you get past any i2c problems, and then you can move on to verify the i2s signals between mcasp and codec.

I would recommend looking at the content in the Porting Guide of the Sitara Linux Audio page. It has a couple of guides that will help you verify you have all the pieces in place. I don't know how much SDK 7/8 kernel differs from the kernel you're using, but it should be similar enough to be very useful.

Markus,

Did you ever get your device tree file working to support the two AIC3107 codecs on the same board?  If so, did you end up with one device tree file for both codecs, or one file apiece for each codec?

I am working on a similar project where we have built two audio capes based on the CircuitCo Audio Cape Rev B using the AIC3104.  One is connected thru I2C1 and McASP0, and the other is connected thru I2C2 and McASP1.  So even though the AIC3104 has a fixed I2C address, the 2 codecs are on different busses.  The pinmux is okay.

As of yet, I have been unable to get both codecs recognizable by ALSA.  When I have just a single .dts file for one codec only, I can get either codec to work.  But I haven't gotten both to be recognized together.

I am using Debian Wheezy 3.8.13-bone73

Craig

Jason,

I don't know how to combine two sound fragments in the same dts file.  So I've kept the dts files for the two audio codecs separate.  I have attached them, or at least I believe that I have.  The files were renamed with a .txt extension because dts files are not allowed to be uploaded here.

If you can tell me how to combine both sound fragments in the same dts file, that would be great.

Craig

P.S. Just in case the files weren't attached, I am printing them here:

BB-BONE-AUDI-03-00A0.dts:

/*
 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 *
 * GPIO Pin User-Configuration Settings:
 *   Bits 2:0  mode       pinmux (0-7)
 *   Bit  3    puden      internal resistor 0=>Enable, 1=>Disable
 *   Bit  4    puTypeSel  internal resistor type 0=>PullDown, 1=>Pull-Up
 *   Bit  5    rxActive   0=>Output, 1=>Input
 *   Bit  6    slewCtrl   0=>Fast, 1=>Slow (Only set to Slow for I2C)
 *
 *               Craig Leeds:
 * Configuration for McASP0 on first codec:
 *
 * Differences from CircuitCo Audio Cape on original BeagleBone Black:
 *  On BBB with CircuitCo Audio Cape
 *    Input to Sitara is jittery 24 MHz clock.  Output on MCASP0_AHCLKX is 12 MHz.
 *  On First Audio Codec on our board:
 *    Input to Sitara is stable 25 MHz clock.  
 *    Input to 1st AIC3104 codec MCLK is 10 MHz clock directly from crystal
 *    Codec provides the 3,072,000 Hz clock to MCASP0_ACLKX
 *    MCASP0_AHCLKX is not connected
 *    BCLK     = MCASP0_ACLKX on P8.37  GPIO2_14  U1   pin 48  0xc0 mode 3 In
 *    WCLK     = MCASP0_FSX   on P8.38  GPIO2_15  U2   pin 49  0xc4 mode 3 In
 *    AUD_DIN  = MCASP0_AXR0  on P8.36  GPIO2_16  U3   pin 50  0xc8 mode 3 In
 *    AUD_DOUT = MCASP0_AXR1  on P8.31  GPIO0_10  V4   pin 54  0xd8 mode 3 Out
 *    Uses I2C1 instead of I2C2
 *    SCL      = I2C1_SCL     on P9.17  GPIO0_5   D17  pin 86  0x158 mode 2 PullUp Slow
 *    SDA      = I2C1_SDA     on P9.18  GPIO0_4   D18  pin 87  0x15c mode 2 PullUp Slow
 */
/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "BB-BONE-AUDI-03";
    version = "00A0", "A0";

    /* state the resources this cape uses */
    exclusive-use =
        /* the pin header uses */
        "P8.37",    /* mcasp0: MCASP0_ACLKX */
        "P8.38",    /* mcasp0: MCASP0_FSX */
        "P8.36",    /* mcasp0: MCASP0_AXR0 DIN */
        "P8.31",    /* mcasp0: MCASP0_AXR1 DOUT */
        /* the hardware ip uses */
        "mcasp0";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {

            i2c1_pins: pinmux_i2c1_pins {
                pinctrl-single,pins = <
                    0x158 0x72     /* I2C1_SDA, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */
                    0x15C 0x72    /* I2C1_SCL, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */
                >;
            };

            bone_audio_cape1_audio_pins: pinmux_bone_audio_cape1_audio_pins {
                pinctrl-single,pins = <
                    0x0c0 0x23      /* MCASP0_ACLKX MODE3 | INPUT */
                    0x0c4 0x23      /* MCASP0_FSX   MODE3 | INPUT */
                    0x0c8 0x23      /* MCASP0_AXR0  MODE3 | INPUT */
                    0x0d8 0x03        /* MCASP0_AXR1  MODE3 | OUTPUT */
                >;
            };
        };
    };

    fragment@1 {
        target = <&i2c1>;
        __overlay__ {
            #address-cells = <1>;
            #size-cells = <0>;
            clock-frequency = <100000>;
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <&i2c1_pins>;


            tlv320aic3x: tlv320aic3x@18 {
                compatible = "ti,tlv320aic3x";
                reg = <0x18>;
                status = "okay";
            };
        };
    };

    fragment@2 {
        target = <&mcasp0>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&bone_audio_cape1_audio_pins>;

            status = "okay";

            op-mode = <0>;          /* MCASP_IIS_MODE */
            tdm-slots = <2>;
            num-serializer = <16>;
            serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
                2 1 0 0
                0 0 0 0
                0 0 0 0
                0 0 0 0
            >;
            tx-num-evt = <1>;
            rx-num-evt = <1>;
        };
    };

    fragment@3 {
        target = <&ocp>;
        __overlay__ {
            sound {
                compatible = "ti,da830-evm-audio";
                ti,model = "AIC3104_1";
                ti,audio-codec = <&tlv320aic3x>;
                ti,mcasp-controller = <&mcasp0>;
                ti,codec-clock-rate = <10000000>;   /* Craig Leeds: Clock input is from stable 10MHz crystal, MCASP0_AHCLKX is not used */
                ti,audio-routing =
                    "Headphone Jack",       "HPLOUT",
                    "Headphone Jack",       "HPROUT",
                    "LINE1L",               "Line In",
                    "LINE1R",               "Line In";
            };
        };

    };
};

BB-BONE-AUDI-04-00A0.dts:

/*
 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 *
 * GPIO Pin User-Configuration Settings:
 *   Bits 2:0  mode       pinmux (0-7)
 *   Bit  3    puden      internal resistor 0=>Enable, 1=>Disable
 *   Bit  4    puTypeSel  internal resistor type 0=>PullDown, 1=>Pull-Up
 *   Bit  5    rxActive   0=>Output, 1=>Input
 *   Bit  6    slewCtrl   0=>Fast, 1=>Slow (Only set to Slow for I2C)
 *
 *               Craig Leeds:
 * Configuration for McASP1 on second codec on our board:
 *
 * Differences from CircuitCo Audio Cape with original BeagleBone Black:
 *  On BBB with CircuitCo Audio Cape
 *    Input to Sitara is jittery 24 MHz clock.  Output on MCASP0_AHCLKX is 12 MHz.
 *  On our 2nd audio codec on our board:
 *    Input to Sitara is stable 25 MHz clock. 
 *    Input to 2nd AIC3104 codec MCLK is 10 MHz clock directly from crystal
 *    Codec provides the 3,072,000 Hz clock to MCASP1_ACLKX
 *    MCASP1_AHCLKX is not connected
 *    BCLK     = MCASP1_ACLKX on P9.42  GPIO3_18  B12  Pin 104  0x1a0 mode 3 In
 *    WCLK     = MCASP1_FSX   on P9.27  GPIO3_19  C13  Pin 105  0x1a4 mode 3 In
 *    AUD_DIN  = MCASP1_AXR0  on P9.41  GPIO3_20  D13  Pin 106  0x1a8 mode 3 In
 *    AUD_DOUT = MCASP1_AXR1  on P9.25  GPIO3_21  A14  Pin 107  0x1ac mode 3 Out
 *    Uses I2C2 (just like Audio Cape used it for McASP0)
 *    SCL      = I2C2_SCL     on P9.19  GPIO0_13  D17  Pin  95  0x17c mode 3 PullUp Slow
 *    SDA      = I2C2_SDA     on P9.20  GPIO0_12  D18  Pin  94  0x178 mode 3 PullUp Slow
 */
/dts-v1/;
/plugin/;

/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";

    /* identification */
    part-number = "BB-BONE-AUDI-04";
    version = "00A0", "A0";

    /* state the resources this cape uses */
    exclusive-use =
        /* the pin header uses */
        "P9.42",    /* mcasp1: MCASP1_ACLKX */
        "P9.27",    /* mcasp1: MCASP1_FSX */
        "P9.41",    /* mcasp1: MCASP1_AXR0 DIN */
        "P9.25",    /* mcasp1: MCASP1_AXR1 DOUT */
        /* the hardware ip uses */
        "mcasp1";

    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {

            i2c2_pins: pinmux_i2c2_pins {
                pinctrl-single,pins = <
                    0x178 0x73     /* I2C2_SDA, SLEWCTRL_SLOW | INPUT_PULLUP | MODE3 */
                    0x17C 0x73    /* I2C2_SCL, SLEWCTRL_SLOW | INPUT_PULLUP | MODE3 */
                >;
            };

            bone_audio_cape2_audio_pins: pinmux_bone_audio_cape2_audio_pins {
                pinctrl-single,pins = <
                    0x1a0 0x23      /* MCASP1_ACLKX MODE3 | INPUT */
                    0x1a4 0x23      /* MCASP1_FSX   MODE3 | INPUT */
                    0x1a8 0x23      /* MCASP1_AXR0  MODE3 | INPUT */
                    0x1ac 0x03        /* MCASP1_AXR1  MODE3 | OUTPUT */
                >;
            };
        };
    };

    fragment@1 {
        target = <&i2c2>;
        __overlay__ {
            #address-cells = <1>;
            #size-cells = <0>;
            clock-frequency = <100000>;
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <&i2c2_pins>;

            tlv320aic3x: tlv320aic3x@18 {
                compatible = "ti,tlv320aic3x";
                reg = <0x18>;
                status = "okay";
            };
        };
    };

    fragment@2 {
        target = <&mcasp1>;
        __overlay__ {
            pinctrl-names = "default";
            pinctrl-0 = <&bone_audio_cape2_audio_pins>;

            status = "okay";

            op-mode = <0>;          /* MCASP_IIS_MODE */
            tdm-slots = <2>;
            num-serializer = <16>;
            serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
                2 1 0 0
                0 0 0 0
                0 0 0 0
                0 0 0 0
            >;
            tx-num-evt = <1>;
            rx-num-evt = <1>;
        };
    };

    fragment@3 {
        target = <&ocp>;
        __overlay__ {
            sound {
                compatible = "ti,da830-evm-audio";
                ti,model = "AIC3104_2";
                ti,audio-codec = <&tlv320aic3x>;
                ti,mcasp-controller = <&mcasp1>;
                ti,codec-clock-rate = <10000000>;   /* Craig Leeds: Clock input is from stable 10MHz crystal, MCASP1_AHCLKX is not used */
                ti,audio-routing =
                    "Headphone Jack",       "HPLOUT",
                    "Headphone Jack",       "HPROUT",
                    "LINE1L",               "Line In",
                    "LINE1R",               "Line In";
            };
        };
    };
};

/cfs-file/__key/communityserver-discussions-components-files/791/1351.BB_2D00_BONE_2D00_AUDI_2D00_03_2D00_00A0_2D00_dts.txt

/cfs-file/__key/communityserver-discussions-components-files/791/0602.BB_2D00_BONE_2D00_AUDI_2D00_04_2D00_00A0_2D00_dts.txt

Craig,

I am not terribly familiar with device tree overlays (as TI does not support them in our current Processor SDK releases) but maybe an example of our dts nodes can be helpful. Here is how we enable two sound nodes in our dts file:

sound0: sound@0 {
     compatible = ".....
     .....
};
sound1: sound@1 {
     compatible = " .....
     .....
};

So, you may try using sound0: sound@0 and sound1: sound@1 in your overlays and see if this helps.
use this in one of your overlays:
fragment@3 {
     target = <&ocp>;
     __overlay__ {
          sound0: sound@0 {
               .....
               .....
          };
     };
};
and use this in the other overlay:
fragment@3 {
     target = <&ocp>;
     __overlay__ {
          sound1: sound@1 {
               .....
               .....
          };
     };
};

It appears like your overlays are overwriting each other at the 'sound' node since the name is the exact same. Maybe the difference in naming above will allow them both to be added simultaneously.

Jason Reeder

Hi,

Allow me to use this thread to address similar issue I have for adding 2 different codecs in dts sound node.
my original thread created is the following link and someone re-directed me to this thread to get help. But I have tried some combination the overlay solution suggested in this thread and it is not working for me yet: e2e.ti.com/.../470497 (my original thread).

Basically i have ported a first codec (pcm5102) connected to mcasp0 and it works fine and can stream audio to it.
Now I have a second codec (PCM5168) which is connected to mcasp1 and I want to add it in the device tree SOUND node. My question is how to properly do that?

here is my current sound node for the first codec from my dts file which works fine:

pcm5102: pcm5102 {
compatible = "ti,pcm5102";
};

sound {
compatible = "ti,pcm5102-evm-audio";
ti,model = "TI PCM5102";
ti,audio-codec = <&pcm5102>;
ti,mcasp-controller = <&mcasp0>;
ti,codec-clock-rate = <24000000>;

};


now I have added
pcm3168: pcm3168 {
compatible = "ti,pcm3168";
};
 
 How can I add this second codec to the sound node in the same dts file?

Hi:

I know you answered this 2 years ago, but perhaps you can help me a bit anyways... I am doing a similar project, but with a PCM3168. I just need to know how to configure i2c for it in the device tree... is with a code similar to the one you posted? Where can i find information about this? i want to setup of i2c for controlling the PCM3168

thanks!

Stefan,

I'm sorry that it's taken me so long to respond.  I just got back to working on this project.  I did see both Codecs working one time.  Then I tried to streamline my code to remove what wasn't necessary in the kernel and dts files that I changed.  And I'm embarrassed to say that I never got it working again.  Since I've just started working on it again, I am revisiting the issue.  But of course the kernel has now changed considerably since last year, so I'm not sure that the methodology that I used last year would be the right way.  Did you have any luck with this?

Thanks.

Craig