Yeah, it turned out I needed a -cells = <0> on the mcasp0 peripheral.

I've got it finding it and creating a sound card, and if I run speaker-test, it sends a bunch of i2c commands to the codec (which aren't quite right). But the McASP/IIS pins never change state, so, I've made progress, but I'm still stuck.

Latest DTBO: https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PR...

On Sep 27, 2015, at 14:52 , Caleb Crome caleb@crome.org wrote:

I found that too. Check out the documentation here: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/sound...

You need to put in the #sound-dai-cells cell. Your value will likely be 0 for the codec, and maybe 1 for the SOC dai, but I"m not sure.

Unfortunately, I don't really understand how it works.

-Caleb

On Fri, Sep 25, 2015 at 10:57 PM, Rick Mann rmann@latencyzero.com wrote:

...

Hi. I've built a Beaglebone Black Cape that has, among other things, a TI Audio CODEC on it (TLV320AIC3104). This is the same CODEC as the BBB Audio Cape (http://elinux.org/CircuitCo:Audio_Cape_RevB), and it's connected in almost the exact same way.

The last few days I've been figuring out the Device Tree overlay needed to get Linux (4.1.4) to recognize it. It's finding the device and instantiating the low-level driver (tlv320aic3x-codec), although I'm not sure at this point if it's actually talking to it (I have verified that low-level i2c commands do work).

But when it comes to the sound card setup, I'm having trouble getting the Device Tree right. I'm hoping someone on this list can offer some insight. The DT is here:

   https://github.com/JetForMe/podtique/blob/master/bbb/cape/Podtique1/BB-ENABLE-PRU.dts

And this is dmesg when I try to load that (note the name of my overlay is BB-ENABLE-PRU, which is an artifact of the experimentation I've been doing; it'll change to something more appropriate):

[ 65.859275] bone_capemgr bone_capemgr: part_number 'BB-ENABLE-PRU', version 'N/A' [ 65.859318] bone_capemgr bone_capemgr: slot #4: override [ 65.859336] bone_capemgr bone_capemgr: Using override eeprom data at slot 4 [ 65.859355] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-ENABLE-PRU' [ 65.859488] bone_capemgr: bone_capemgr bone_capemgr: slot #4: Requesting part number/version based 'BB-ENABLE-PRU-00A0.dtbo [ 65.859506] bone_capemgr: bone_capemgr bone_capemgr: slot #4: Requesting firmware 'BB-ENABLE-PRU-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 65.861105] bone_capemgr: bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; converting to live tree [ 65.875618] gpio-of-helper ocp:gpio_helper: ready [ 65.876327] gpiolib_of: of_get_named_gpiod_flags: parsed 'gpio' property of node '//fixedregulator@1[0]' - status (0) [ 65.876619] core: lz-codec-reg: no parameters [ 65.876713] fixed: reg-fixed-voltage fixedregulator@1: lz-codec-reg supplying 0uV [ 65.883284] pruss_uio 4a300000.pruss: pins are not configured from the driver [ 65.900080] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; overlay id #0 [ 65.946254] gpiolib_of: of_get_named_gpiod_flags: parsed 'gpio-reset' property of node '/ocp/i2c@4819c000/tlv320aic3104@0[0]' - status (0) [ 65.946317] core: tlv320aic3x-codec 2-0018: Looking up IOVDD-supply from device tree [ 65.946405] core: tlv320aic3x-codec 2-0018: Looking up DVDD-supply from device tree [ 65.946468] core: tlv320aic3x-codec 2-0018: Looking up AVDD-supply from device tree [ 65.946544] core: tlv320aic3x-codec 2-0018: Looking up DRVDD-supply from device tree [ 65.946606] snd_soc_core: tlv320aic3x-codec 2-0018: codec register 2-0018 [ 65.946640] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: dai register 2-0018 #1 [ 65.946655] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: Registered DAI 'tlv320aic3x-hifi' [ 65.946671] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: Registered codec 'tlv320aic3x-codec.2-0018' [ 65.956491] //sound/simple-audio-card,cpu: could not get #sound-dai-cells for /ocp/mcasp@48038000 [ 65.978759] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: dai register 48038000.mcasp #1 [ 65.978795] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: Registered DAI '48038000.mcasp' [ 65.978954] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: Registered platform '48038000.mcasp' [ 66.012427] asoc-simple-card sound: parse error -22 [ 66.042609] asoc-simple-card: probe of sound failed with error -22

Note the bit about "#sound-dai-cells". I'm not sure what's wrong here, and it seems like it might be something in the distro-provided DTB, not my own.

aplay lists nothing (I think in part because I have yet to put in a proper asound.conf file):

# aplay -l aplay: device_list:268: no soundcards found...

Can someone suggest some diagnostics I can do to see what the state of things is? I'm just not sure what to look for. Thanks!

-- Rick Mann rmann@latencyzero.com

---

Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

---

Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

That's very similar to what I have (I use ax40 & axr2). I also use macsp0_ahclkx, but I'm not seeing a signal on it (or any other pin).

Does this work for you with a 4.1.x kernel?

On Sep 28, 2015, at 09:11 , Caleb Crome caleb@crome.org wrote:

I used these pins to get the audio cape going.

+/*

• • MCASP pin mapping

• •                      ball   BBB
    

• • MCASP0_ACLKX A13 P9.31
• • MCASP0_AFSX B13 P9.29
• • MCASP0_AXR2 (mcasp OUT) C12 P9.28
• • MCASP0_AXR3 (mcasp IN) A14 P9.25

+*/

mcasp_0_pins_default: mcasp_0_pins_default { pinctrl-single,pins = < 0x190 ( PIN_INPUT | MUX_MODE0 ) /* (A13) mcasp0_aclkx.mcasp0_aclkx */ 0x194 ( PIN_INPUT | MUX_MODE0 ) /* (B13) mcasp0_fsx.mcasp0_fsx */ 0x19c ( PIN_OUTPUT | MUX_MODE2 ) /* (C12) mcasp0_ahclkr.mcasp0_axr2 */ 0x1ac ( PIN_INPUT | MUX_MODE2 ) /* (A14) mcasp0_ahclkx.mcasp0_axr3 */

...

;

};

And importantly, the audio cape needs to use the AXR2 and AXR3 for my use.

+&mcasp0 {

• pinctrl-names = "default";
• pinctrl-0 = <&mcasp_0_pins_default>;
• status = "okay";
• op-mode = <0>; /* MCASP_IIS_MODE */
• tdm-slots = <8>;
• 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>;

};

Hope that can be of some help.

-Caleb

On Sun, Sep 27, 2015 at 10:14 PM, Rick Mann rmann@latencyzero.com wrote:

...

Yeah, it turned out I needed a -cells = <0> on the mcasp0 peripheral.

I've got it finding it and creating a sound card, and if I run speaker-test, it sends a bunch of i2c commands to the codec (which aren't quite right). But the McASP/IIS pins never change state, so, I've made progress, but I'm still stuck.

Latest DTBO:

   https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PRU.dts

...

On Sep 27, 2015, at 14:52 , Caleb Crome caleb@crome.org wrote:

I found that too. Check out the documentation here: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/sound...

You need to put in the #sound-dai-cells cell. Your value will likely be 0 for the codec, and maybe 1 for the SOC dai, but I"m not sure.

Unfortunately, I don't really understand how it works.

-Caleb

On Fri, Sep 25, 2015 at 10:57 PM, Rick Mann rmann@latencyzero.com wrote:

...

Hi. I've built a Beaglebone Black Cape that has, among other things, a TI Audio CODEC on it (TLV320AIC3104). This is the same CODEC as the BBB Audio Cape (http://elinux.org/CircuitCo:Audio_Cape_RevB), and it's connected in almost the exact same way.

The last few days I've been figuring out the Device Tree overlay needed to get Linux (4.1.4) to recognize it. It's finding the device and instantiating the low-level driver (tlv320aic3x-codec), although I'm not sure at this point if it's actually talking to it (I have verified that low-level i2c commands do work).

But when it comes to the sound card setup, I'm having trouble getting the Device Tree right. I'm hoping someone on this list can offer some insight. The DT is here:

  https://github.com/JetForMe/podtique/blob/master/bbb/cape/Podtique1/BB-ENABLE-PRU.dts

And this is dmesg when I try to load that (note the name of my overlay is BB-ENABLE-PRU, which is an artifact of the experimentation I've been doing; it'll change to something more appropriate):

[ 65.859275] bone_capemgr bone_capemgr: part_number 'BB-ENABLE-PRU', version 'N/A' [ 65.859318] bone_capemgr bone_capemgr: slot #4: override [ 65.859336] bone_capemgr bone_capemgr: Using override eeprom data at slot 4 [ 65.859355] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-ENABLE-PRU' [ 65.859488] bone_capemgr: bone_capemgr bone_capemgr: slot #4: Requesting part number/version based 'BB-ENABLE-PRU-00A0.dtbo [ 65.859506] bone_capemgr: bone_capemgr bone_capemgr: slot #4: Requesting firmware 'BB-ENABLE-PRU-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 65.861105] bone_capemgr: bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; converting to live tree [ 65.875618] gpio-of-helper ocp:gpio_helper: ready [ 65.876327] gpiolib_of: of_get_named_gpiod_flags: parsed 'gpio' property of node '//fixedregulator@1[0]' - status (0) [ 65.876619] core: lz-codec-reg: no parameters [ 65.876713] fixed: reg-fixed-voltage fixedregulator@1: lz-codec-reg supplying 0uV [ 65.883284] pruss_uio 4a300000.pruss: pins are not configured from the driver [ 65.900080] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; overlay id #0 [ 65.946254] gpiolib_of: of_get_named_gpiod_flags: parsed 'gpio-reset' property of node '/ocp/i2c@4819c000/tlv320aic3104@0[0]' - status (0) [ 65.946317] core: tlv320aic3x-codec 2-0018: Looking up IOVDD-supply from device tree [ 65.946405] core: tlv320aic3x-codec 2-0018: Looking up DVDD-supply from device tree [ 65.946468] core: tlv320aic3x-codec 2-0018: Looking up AVDD-supply from device tree [ 65.946544] core: tlv320aic3x-codec 2-0018: Looking up DRVDD-supply from device tree [ 65.946606] snd_soc_core: tlv320aic3x-codec 2-0018: codec register 2-0018 [ 65.946640] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: dai register 2-0018 #1 [ 65.946655] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: Registered DAI 'tlv320aic3x-hifi' [ 65.946671] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: Registered codec 'tlv320aic3x-codec.2-0018' [ 65.956491] //sound/simple-audio-card,cpu: could not get #sound-dai-cells for /ocp/mcasp@48038000 [ 65.978759] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: dai register 48038000.mcasp #1 [ 65.978795] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: Registered DAI '48038000.mcasp' [ 65.978954] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: Registered platform '48038000.mcasp' [ 66.012427] asoc-simple-card sound: parse error -22 [ 66.042609] asoc-simple-card: probe of sound failed with error -22

Note the bit about "#sound-dai-cells". I'm not sure what's wrong here, and it seems like it might be something in the distro-provided DTB, not my own.

aplay lists nothing (I think in part because I have yet to put in a proper asound.conf file):

# aplay -l aplay: device_list:268: no soundcards found...

Can someone suggest some diagnostics I can do to see what the state of things is? I'm just not sure what to look for. Thanks!

-- Rick Mann rmann@latencyzero.com

---

Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

---

Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- Rick Mann rmann@latencyzero.com

On Sep 28, 2015, at 15:22 , Caleb Crome caleb@crome.org wrote:

On Mon, Sep 28, 2015 at 11:55 AM, Rick Mann rmann@latencyzero.com wrote:

...

That's very similar to what I have (I use ax40 & axr2). I also use macsp0_ahclkx, but I'm not seeing a signal on it (or any other pin).

...

Does this work for you with a 4.1.x kernel?

Yes, it works for me. I assume your codec is master, do you see WCLK and BCLK running? How about MCLK?

Who is supposed to be driving MCLK in your case, the BBB or the codec?

According to someone else, and as you assume above, the BBB should generate the MCLK and the TLV generates WCLK and BCLK. That's counterintuitive to me, but the configuration it's sending to the TLV for register 0x08 is 0xC0, which sets the bits such that WCLK and BCLK are outputs (master mode). I think MCLK is always an input on this device.

(BTW, thanks for asking. In verifying what I just wrote, I learned a lot about how it's supposed to work).

I see that you have the AHCLKX set to INPUT. This should probably either be output (if the CPU is driving it), or not connected if the codec is driving it.

...

0x1ac (PIN_INPUT | MUX_MODE0) // P9_25 MCLK MCLK mcasp0_ahclkx

Yeah, I changed that the other day:

https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PR...

pinctrl-single,pins = < // Hdr I2S TLV SoC // ----- ---- ---- ------------- 0x190 (PIN_INPUT_PULLDOWN | MUX_MODE0) // P9_31 BCLK BCLK mcasp0_aclkx 0x194 (PIN_INPUT_PULLDOWN | MUX_MODE0) // P9_29 WCLK WCLK mcasp0_fsx 0x198 (PIN_INPUT_PULLDOWN | MUX_MODE0) // P9_30 RX SDOUT mcasp0_axr0 0x19c (PIN_INPUT_PULLDOWN | MUX_MODE2) // P9_28 TX SDIN mcasp0_axr2 0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE0) // P9_25 MCLK MCLK mcasp0_ahclkx

;

The TRM indicates all the pins should have their receiver enabled, but I decided to make MCLK an output.

In all cases, NONE of the pins, including MCLK, changes state. BTW, when I run speaker-test, it gets this far and hangs:

$ speaker-test

speaker-test 1.0.28

Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 128 to 32768 Period size range from 8 to 2048 Using max buffer size 32768 Periods = 4 was set period_size = 2048 was set buffer_size = 32768 0 - Front Left

Which makes me think some internal sound data buffer is filling up, and the write is blocking, and nothing is emptying the buffer because the McASP isn't accepting bytes, and therefore not sending data out.

If I interrupt speaker-test, it usually outputs this:

^CWrite error: -4,Interrupted system call xrun_recovery failed: -4,Interrupted system call Transfer failed: Interrupted system call

Further reinforcing my theory. Which suggests something's still not right for McASP0.

-Caleb

...

...

On Sep 28, 2015, at 09:11 , Caleb Crome caleb@crome.org wrote:

I used these pins to get the audio cape going.

+/*

• • MCASP pin mapping

• •                      ball   BBB
    

• • MCASP0_ACLKX A13 P9.31
• • MCASP0_AFSX B13 P9.29
• • MCASP0_AXR2 (mcasp OUT) C12 P9.28
• • MCASP0_AXR3 (mcasp IN) A14 P9.25

+*/

mcasp_0_pins_default: mcasp_0_pins_default { pinctrl-single,pins = < 0x190 ( PIN_INPUT | MUX_MODE0 ) /* (A13) mcasp0_aclkx.mcasp0_aclkx */ 0x194 ( PIN_INPUT | MUX_MODE0 ) /* (B13) mcasp0_fsx.mcasp0_fsx */ 0x19c ( PIN_OUTPUT | MUX_MODE2 ) /* (C12) mcasp0_ahclkr.mcasp0_axr2 */ 0x1ac ( PIN_INPUT | MUX_MODE2 ) /* (A14) mcasp0_ahclkx.mcasp0_axr3 */

...

;

};

And importantly, the audio cape needs to use the AXR2 and AXR3 for my use.

+&mcasp0 {

• pinctrl-names = "default";
• pinctrl-0 = <&mcasp_0_pins_default>;
• status = "okay";
• op-mode = <0>; /* MCASP_IIS_MODE */
• tdm-slots = <8>;
• 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>;

};

Hope that can be of some help.

-Caleb

On Sun, Sep 27, 2015 at 10:14 PM, Rick Mann rmann@latencyzero.com wrote:

...

Yeah, it turned out I needed a -cells = <0> on the mcasp0 peripheral.

I've got it finding it and creating a sound card, and if I run speaker-test, it sends a bunch of i2c commands to the codec (which aren't quite right). But the McASP/IIS pins never change state, so, I've made progress, but I'm still stuck.

Latest DTBO:

  https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PRU.dts

...

On Sep 27, 2015, at 14:52 , Caleb Crome caleb@crome.org wrote:

I found that too. Check out the documentation here: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/sound...

You need to put in the #sound-dai-cells cell. Your value will likely be 0 for the codec, and maybe 1 for the SOC dai, but I"m not sure.

Unfortunately, I don't really understand how it works.

-Caleb

On Fri, Sep 25, 2015 at 10:57 PM, Rick Mann rmann@latencyzero.com wrote:

...

Hi. I've built a Beaglebone Black Cape that has, among other things, a TI Audio CODEC on it (TLV320AIC3104). This is the same CODEC as the BBB Audio Cape (http://elinux.org/CircuitCo:Audio_Cape_RevB), and it's connected in almost the exact same way.

The last few days I've been figuring out the Device Tree overlay needed to get Linux (4.1.4) to recognize it. It's finding the device and instantiating the low-level driver (tlv320aic3x-codec), although I'm not sure at this point if it's actually talking to it (I have verified that low-level i2c commands do work).

But when it comes to the sound card setup, I'm having trouble getting the Device Tree right. I'm hoping someone on this list can offer some insight. The DT is here:

 https://github.com/JetForMe/podtique/blob/master/bbb/cape/Podtique1/BB-ENABLE-PRU.dts

And this is dmesg when I try to load that (note the name of my overlay is BB-ENABLE-PRU, which is an artifact of the experimentation I've been doing; it'll change to something more appropriate):

[ 65.859275] bone_capemgr bone_capemgr: part_number 'BB-ENABLE-PRU', version 'N/A' [ 65.859318] bone_capemgr bone_capemgr: slot #4: override [ 65.859336] bone_capemgr bone_capemgr: Using override eeprom data at slot 4 [ 65.859355] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-ENABLE-PRU' [ 65.859488] bone_capemgr: bone_capemgr bone_capemgr: slot #4: Requesting part number/version based 'BB-ENABLE-PRU-00A0.dtbo [ 65.859506] bone_capemgr: bone_capemgr bone_capemgr: slot #4: Requesting firmware 'BB-ENABLE-PRU-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 65.861105] bone_capemgr: bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; converting to live tree [ 65.875618] gpio-of-helper ocp:gpio_helper: ready [ 65.876327] gpiolib_of: of_get_named_gpiod_flags: parsed 'gpio' property of node '//fixedregulator@1[0]' - status (0) [ 65.876619] core: lz-codec-reg: no parameters [ 65.876713] fixed: reg-fixed-voltage fixedregulator@1: lz-codec-reg supplying 0uV [ 65.883284] pruss_uio 4a300000.pruss: pins are not configured from the driver [ 65.900080] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; overlay id #0 [ 65.946254] gpiolib_of: of_get_named_gpiod_flags: parsed 'gpio-reset' property of node '/ocp/i2c@4819c000/tlv320aic3104@0[0]' - status (0) [ 65.946317] core: tlv320aic3x-codec 2-0018: Looking up IOVDD-supply from device tree [ 65.946405] core: tlv320aic3x-codec 2-0018: Looking up DVDD-supply from device tree [ 65.946468] core: tlv320aic3x-codec 2-0018: Looking up AVDD-supply from device tree [ 65.946544] core: tlv320aic3x-codec 2-0018: Looking up DRVDD-supply from device tree [ 65.946606] snd_soc_core: tlv320aic3x-codec 2-0018: codec register 2-0018 [ 65.946640] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: dai register 2-0018 #1 [ 65.946655] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: Registered DAI 'tlv320aic3x-hifi' [ 65.946671] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: Registered codec 'tlv320aic3x-codec.2-0018' [ 65.956491] //sound/simple-audio-card,cpu: could not get #sound-dai-cells for /ocp/mcasp@48038000 [ 65.978759] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: dai register 48038000.mcasp #1 [ 65.978795] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: Registered DAI '48038000.mcasp' [ 65.978954] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: Registered platform '48038000.mcasp' [ 66.012427] asoc-simple-card sound: parse error -22 [ 66.042609] asoc-simple-card: probe of sound failed with error -22

Note the bit about "#sound-dai-cells". I'm not sure what's wrong here, and it seems like it might be something in the distro-provided DTB, not my own.

aplay lists nothing (I think in part because I have yet to put in a proper asound.conf file):

# aplay -l aplay: device_list:268: no soundcards found...

Can someone suggest some diagnostics I can do to see what the state of things is? I'm just not sure what to look for. Thanks!

-- Rick Mann rmann@latencyzero.com

---

Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

---

Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- Rick Mann rmann@latencyzero.com

-- Rick Mann rmann@latencyzero.com

---

Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

On Sep 28, 2015, at 16:46 , Caleb Crome caleb@crome.org wrote:

Hmm, the pinmux looks right, except that you have your TX set as an input. You should have this:

mymcasp1_pins_default: mymcasp1_pins_default { pinctrl-single,pins = < 0x1ac ( PIN_OUTPUT | MUX_MODE0 ) /* (A14) mcasp0_ahclkx.mcasp0_ahclkx */ 0x190 ( PIN_INPUT | MUX_MODE0 ) /* (A13) mcasp0_aclkx.mcasp0_aclkx */ 0x194 ( PIN_INPUT | MUX_MODE0 ) /* (B13) mcasp0_fsx.mcasp0_fsx */ 0x198 ( PIN_INPUT | MUX_MODE0 ) /* (D12) mcasp0_axr0.mcasp0_axr0 */ 0x19c ( PIN_OUTPUT | MUX_MODE2 ) /* (C12) mcasp0_ahclkr.mcasp0_axr2 */

...

;

};

The DTBO for the Audio Cape didn't mark the TX as an output, but I surely can try that.

I'm not using a DTBO, but editing the DTB directly. Do you currently get a sound card listed? i.e. does aplay -l show anything?

Oh yes, I get a sound card. That depended on the "sound" and "mcasp0" entries in my overlay to be correct. Sadly, the kernel doesn't actually talk to the IC until you invoke speaker-test (or some other audio program).

Also, did you disable your HDMI? You need to do that.

Yeah, it's disabled by the main dtb that I load:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-bo...

Instead of the default:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.1-ti/src/arm/am335x-bo...

The thing you need to get is the MCLK a.k.a. the ahclkx going. After that, all else should fall in line. Maybe. If ahclkx isn't going, then perhaps it's a problem with enabling the mcasp, but your dts looks okay.

Thanks for double-checking!

-Caleb

On Mon, Sep 28, 2015 at 3:34 PM, Rick Mann rmann@latencyzero.com wrote:

...

...

On Sep 28, 2015, at 15:22 , Caleb Crome caleb@crome.org wrote:

On Mon, Sep 28, 2015 at 11:55 AM, Rick Mann rmann@latencyzero.com wrote:

...

That's very similar to what I have (I use ax40 & axr2). I also use macsp0_ahclkx, but I'm not seeing a signal on it (or any other pin).

...

Does this work for you with a 4.1.x kernel?

Yes, it works for me. I assume your codec is master, do you see WCLK and BCLK running? How about MCLK?

Who is supposed to be driving MCLK in your case, the BBB or the codec?

According to someone else, and as you assume above, the BBB should generate the MCLK and the TLV generates WCLK and BCLK. That's counterintuitive to me, but the configuration it's sending to the TLV for register 0x08 is 0xC0, which sets the bits such that WCLK and BCLK are outputs (master mode). I think MCLK is always an input on this device.

(BTW, thanks for asking. In verifying what I just wrote, I learned a lot about how it's supposed to work).

...

I see that you have the AHCLKX set to INPUT. This should probably either be output (if the CPU is driving it), or not connected if the codec is driving it.

...

0x1ac (PIN_INPUT | MUX_MODE0) // P9_25 MCLK MCLK mcasp0_ahclkx

Yeah, I changed that the other day:

    https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PRU.dts

pinctrl-single,pins = < // Hdr I2S TLV SoC // ----- ---- ---- ------------- 0x190 (PIN_INPUT_PULLDOWN | MUX_MODE0) // P9_31 BCLK BCLK mcasp0_aclkx 0x194 (PIN_INPUT_PULLDOWN | MUX_MODE0) // P9_29 WCLK WCLK mcasp0_fsx 0x198 (PIN_INPUT_PULLDOWN | MUX_MODE0) // P9_30 RX SDOUT mcasp0_axr0 0x19c (PIN_INPUT_PULLDOWN | MUX_MODE2) // P9_28 TX SDIN mcasp0_axr2 0x1ac (PIN_OUTPUT_PULLDOWN | MUX_MODE0) // P9_25 MCLK MCLK mcasp0_ahclkx

...

;

The TRM indicates all the pins should have their receiver enabled, but I decided to make MCLK an output.

In all cases, NONE of the pins, including MCLK, changes state. BTW, when I run speaker-test, it gets this far and hangs:

$ speaker-test

speaker-test 1.0.28

Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 128 to 32768 Period size range from 8 to 2048 Using max buffer size 32768 Periods = 4 was set period_size = 2048 was set buffer_size = 32768 0 - Front Left

Which makes me think some internal sound data buffer is filling up, and the write is blocking, and nothing is emptying the buffer because the McASP isn't accepting bytes, and therefore not sending data out.

If I interrupt speaker-test, it usually outputs this:

^CWrite error: -4,Interrupted system call xrun_recovery failed: -4,Interrupted system call Transfer failed: Interrupted system call

Further reinforcing my theory. Which suggests something's still not right for McASP0.

...

-Caleb

...

...

On Sep 28, 2015, at 09:11 , Caleb Crome caleb@crome.org wrote:

I used these pins to get the audio cape going.

+/*

• • MCASP pin mapping

• •                      ball   BBB
    

• • MCASP0_ACLKX A13 P9.31
• • MCASP0_AFSX B13 P9.29
• • MCASP0_AXR2 (mcasp OUT) C12 P9.28
• • MCASP0_AXR3 (mcasp IN) A14 P9.25

+*/

mcasp_0_pins_default: mcasp_0_pins_default { pinctrl-single,pins = < 0x190 ( PIN_INPUT | MUX_MODE0 ) /* (A13) mcasp0_aclkx.mcasp0_aclkx */ 0x194 ( PIN_INPUT | MUX_MODE0 ) /* (B13) mcasp0_fsx.mcasp0_fsx */ 0x19c ( PIN_OUTPUT | MUX_MODE2 ) /* (C12) mcasp0_ahclkr.mcasp0_axr2 */ 0x1ac ( PIN_INPUT | MUX_MODE2 ) /* (A14) mcasp0_ahclkx.mcasp0_axr3 */

...

;

};

And importantly, the audio cape needs to use the AXR2 and AXR3 for my use.

+&mcasp0 {

• pinctrl-names = "default";
• pinctrl-0 = <&mcasp_0_pins_default>;
• status = "okay";
• op-mode = <0>; /* MCASP_IIS_MODE */
• tdm-slots = <8>;
• 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>;

};

Hope that can be of some help.

-Caleb

On Sun, Sep 27, 2015 at 10:14 PM, Rick Mann rmann@latencyzero.com wrote:

...

Yeah, it turned out I needed a -cells = <0> on the mcasp0 peripheral.

I've got it finding it and creating a sound card, and if I run speaker-test, it sends a bunch of i2c commands to the codec (which aren't quite right). But the McASP/IIS pins never change state, so, I've made progress, but I'm still stuck.

Latest DTBO:

  https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PRU.dts

> On Sep 27, 2015, at 14:52 , Caleb Crome caleb@crome.org wrote: > > I found that too. Check out the documentation here: > http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/sound... > > You need to put in the #sound-dai-cells cell. Your value will likely > be 0 for the codec, and maybe 1 for the SOC dai, but I"m not sure. > > Unfortunately, I don't really understand how it works. > > -Caleb > > > On Fri, Sep 25, 2015 at 10:57 PM, Rick Mann rmann@latencyzero.com wrote: >> Hi. I've built a Beaglebone Black Cape that has, among other things, a TI Audio CODEC on it (TLV320AIC3104). This is the same CODEC as the BBB Audio Cape (http://elinux.org/CircuitCo:Audio_Cape_RevB), and it's connected in almost the exact same way. >> >> The last few days I've been figuring out the Device Tree overlay needed to get Linux (4.1.4) to recognize it. It's finding the device and instantiating the low-level driver (tlv320aic3x-codec), although I'm not sure at this point if it's actually talking to it (I have verified that low-level i2c commands do work). >> >> But when it comes to the sound card setup, I'm having trouble getting the Device Tree right. I'm hoping someone on this list can offer some insight. The DT is here: >> >> https://github.com/JetForMe/podtique/blob/master/bbb/cape/Podtique1/BB-ENABL... >> >> And this is dmesg when I try to load that (note the name of my overlay is BB-ENABLE-PRU, which is an artifact of the experimentation I've been doing; it'll change to something more appropriate): >> >> [ 65.859275] bone_capemgr bone_capemgr: part_number 'BB-ENABLE-PRU', version 'N/A' >> [ 65.859318] bone_capemgr bone_capemgr: slot #4: override >> [ 65.859336] bone_capemgr bone_capemgr: Using override eeprom data at slot 4 >> [ 65.859355] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-ENABLE-PRU' >> [ 65.859488] bone_capemgr: bone_capemgr bone_capemgr: slot #4: Requesting part number/version based 'BB-ENABLE-PRU-00A0.dtbo >> [ 65.859506] bone_capemgr: bone_capemgr bone_capemgr: slot #4: Requesting firmware 'BB-ENABLE-PRU-00A0.dtbo' for board-name 'Override Board Name', version '00A0' >> [ 65.861105] bone_capemgr: bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; converting to live tree >> [ 65.875618] gpio-of-helper ocp:gpio_helper: ready >> [ 65.876327] gpiolib_of: of_get_named_gpiod_flags: parsed 'gpio' property of node '//fixedregulator@1[0]' - status (0) >> [ 65.876619] core: lz-codec-reg: no parameters >> [ 65.876713] fixed: reg-fixed-voltage fixedregulator@1: lz-codec-reg supplying 0uV >> [ 65.883284] pruss_uio 4a300000.pruss: pins are not configured from the driver >> [ 65.900080] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; overlay id #0 >> [ 65.946254] gpiolib_of: of_get_named_gpiod_flags: parsed 'gpio-reset' property of node '/ocp/i2c@4819c000/tlv320aic3104@0[0]' - status (0) >> [ 65.946317] core: tlv320aic3x-codec 2-0018: Looking up IOVDD-supply from device tree >> [ 65.946405] core: tlv320aic3x-codec 2-0018: Looking up DVDD-supply from device tree >> [ 65.946468] core: tlv320aic3x-codec 2-0018: Looking up AVDD-supply from device tree >> [ 65.946544] core: tlv320aic3x-codec 2-0018: Looking up DRVDD-supply from device tree >> [ 65.946606] snd_soc_core: tlv320aic3x-codec 2-0018: codec register 2-0018 >> [ 65.946640] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: dai register 2-0018 #1 >> [ 65.946655] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: Registered DAI 'tlv320aic3x-hifi' >> [ 65.946671] snd_soc_core: tlv320aic3x-codec 2-0018: ASoC: Registered codec 'tlv320aic3x-codec.2-0018' >> [ 65.956491] //sound/simple-audio-card,cpu: could not get #sound-dai-cells for /ocp/mcasp@48038000 >> [ 65.978759] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: dai register 48038000.mcasp #1 >> [ 65.978795] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: Registered DAI '48038000.mcasp' >> [ 65.978954] snd_soc_core: davinci-mcasp 48038000.mcasp: ASoC: Registered platform '48038000.mcasp' >> [ 66.012427] asoc-simple-card sound: parse error -22 >> [ 66.042609] asoc-simple-card: probe of sound failed with error -22 >> >> Note the bit about "#sound-dai-cells". I'm not sure what's wrong here, and it seems like it might be something in the distro-provided DTB, not my own. >> >> aplay lists nothing (I think in part because I have yet to put in a proper asound.conf file): >> >> # aplay -l >> aplay: device_list:268: no soundcards found... >> >> Can someone suggest some diagnostics I can do to see what the state of things is? I'm just not sure what to look for. Thanks! >> >> -- >> Rick Mann >> rmann@latencyzero.com >> >> >> _______________________________________________ >> Alsa-devel mailing list >> Alsa-devel@alsa-project.org >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- Rick Mann rmann@latencyzero.com

-- Rick Mann rmann@latencyzero.com

---

Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- Rick Mann rmann@latencyzero.com

On Sep 28, 2015, at 23:27 , Caleb Crome caleb@crome.org wrote:

On Mon, Sep 28, 2015 at 5:08 PM, Rick Mann rmann@latencyzero.com wrote:

...

On Sep 28, 2015, at 16:46 , Caleb Crome caleb@crome.org wrote:

Hmm, the pinmux looks right, except that you have your TX set as an input. You should have this:

mymcasp1_pins_default: mymcasp1_pins_default { pinctrl-single,pins = < 0x1ac ( PIN_OUTPUT | MUX_MODE0 ) /* (A14) mcasp0_ahclkx.mcasp0_ahclkx */ 0x190 ( PIN_INPUT | MUX_MODE0 ) /* (A13) mcasp0_aclkx.mcasp0_aclkx */ 0x194 ( PIN_INPUT | MUX_MODE0 ) /* (B13) mcasp0_fsx.mcasp0_fsx */ 0x198 ( PIN_INPUT | MUX_MODE0 ) /* (D12) mcasp0_axr0.mcasp0_axr0 */ 0x19c ( PIN_OUTPUT | MUX_MODE2 ) /* (C12) mcasp0_ahclkr.mcasp0_axr2 */ >; };

The DTBO for the Audio Cape didn't mark the TX as an output, but I surely can try that.

That's because you didn't tell it to :-) There's checkbox you need to uncheck to make it Tx. It's an uncelar UI. You uncheck Rx to make it a Tx.

What I mean is, the Audio Cape's DTBO (.dts, really), has the modes on all but the WCLK as 0x20 (one is 0x22). That makes them all inputs. Only WCLK is 0x00. Even if it's for the BB White and not Black, that part wouldn't change.

That won't get your clocking going unfortunately.

Also, the DTBO I found for the audio cape is for the BeagleBone, not the BeagleBoneBlack, so that threw me for a while.

also, I got things running using the audio cape and the davinci-evm.c device tree entry, not the simple-audio-card. I ended up putting a lot of printk's into the kernel so I could trace out how the whole thing worked.

Your fundamental problem seems to be in getting the McASP's output clock going. Once that's going, then you can worry about getting the codec's PLL to output BCLK and WCLK.

Look through the davinci-evm.c and see what it does that simple-audio-card doesn't. It's something to do with the MCLK for sure.

Could you send me your DTS?

Once your MCLK is going, you can use i2cdump to look at the codec registers:

sudo i2cdump -f -y 1 0x18

or similar.

Yeah, that works.

On Oct 1, 2015, at 08:38 , Caleb Crome caleb@crome.org wrote:

On Tue, Sep 29, 2015 at 11:41 AM, Rick Mann rmann@latencyzero.com wrote:

...

Ugh, sorry. Here you go:

https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PR...

Sent from my iPhone

On Sep 29, 2015, at 07:08, Caleb Crome caleb@crome.org wrote:

Now I have a working MCLK, and I see clocking on BCLK and WCLK, but the rates are questionable. MCLK is 24 MHz (even though in the DTS it's set to 12 MHz); that might be okay.

It's definitely not obvious why you'd be getting 24MHz instead of 12. Wait. Are you getting exactly 24 MHz, or about 24 MHz? in davinci-evm.c there are some .sysclk settings set to 24576000 as in the da830_snd_soc_card_crvdata.

It's pretty exactly 24.00 MHz, ±0.02 MHz.

I noticed I get these errors (this is 4.1.4-ti-r9 from the Beaglebone Black Debian "console" distro. For reference, here's my overlay: https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PR...). Since I set the clock rate in the sound node, and snd_soc_register_card() is failing (-517 is EPROBE_DEFER, "Driver requests probe retry"), I wonder if the DTS-speified clock rate isn't getting passed through to the tlv320aic.

... [ 133.516593] davinci_evm sound: ASoC: CPU DAI (null) not registered [ 133.522815] davinci_evm sound: snd_soc_register_card failed (-517) ... [ 133.607805] davinci_evm sound: ASoC: DAPM unknown pin MONO_LOUT

Now, I don't specify MONO_LOUT anywhere in my DTS, but it is in tlv320aic3x.c and davinci-evm.c.

Here's the complete dmesg upon loading the device tree:

[ 133.424928] bone_capemgr bone_capemgr: part_number 'BB-ENABLE-PRU', version 'N/A' [ 133.424975] bone_capemgr bone_capemgr: slot #4: override [ 133.424993] bone_capemgr bone_capemgr: Using override eeprom data at slot 4 [ 133.425011] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-ENABLE-PRU' [ 133.425143] bone_capemgr:capemgr_load_slot:1148: bone_capemgr bone_capemgr: slot #4: Requesting part number/version based 'BB-ENABLE-PRU-00A0.dtbo [ 133.425164] bone_capemgr:capemgr_load_slot:1162: bone_capemgr bone_capemgr: slot #4: Requesting firmware 'BB-ENABLE-PRU-00A0.dtbo' for board-name 'Override Board Name', version '00A0' [ 133.426741] bone_capemgr:capemgr_load_slot:1171: bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; converting to live tree [ 133.440820] gpio-of-helper ocp:gpio_helper: ready [ 133.448385] pruss_uio 4a300000.pruss: pins are not configured from the driver [ 133.460959] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-ENABLE-PRU-00A0.dtbo' loaded; overlay id #0 [ 133.516558] snd_soc_core:soc_bind_dai_link:938: davinci_evm sound: ASoC: binding TLV320AIC3X at idx 0 [ 133.516593] davinci_evm sound: ASoC: CPU DAI (null) not registered [ 133.522815] davinci_evm sound: snd_soc_register_card failed (-517) [ 133.533356] snd_soc_core:snd_soc_register_codec:3064: tlv320aic3x-codec 2-0018: codec register 2-0018 [ 133.533406] snd_soc_core:snd_soc_register_dais:2590: tlv320aic3x-codec 2-0018: ASoC: dai register 2-0018 #1 [ 133.533424] snd_soc_core:snd_soc_register_dais:2634: tlv320aic3x-codec 2-0018: ASoC: Registered DAI 'tlv320aic3x-hifi' [ 133.533442] snd_soc_core:snd_soc_register_codec:3138: tlv320aic3x-codec 2-0018: ASoC: Registered codec 'tlv320aic3x-codec.2-0018' [ 133.546622] base:of_property_match_string:1398: comparing tx with tx [ 133.546675] base:of_property_match_string:1398: comparing rx with tx [ 133.546686] base:of_property_match_string:1398: comparing rx with rx [ 133.546739] base:of_property_match_string:1398: comparing common with tx [ 133.546751] base:of_property_match_string:1398: comparing common with rx [ 133.546763] base:of_property_match_string:1398: comparing rx with tx [ 133.546773] base:of_property_match_string:1398: comparing rx with rx [ 133.550537] base:of_property_match_string:1398: comparing tx with tx [ 133.556638] snd_soc_core:snd_soc_register_dais:2590: davinci-mcasp 48038000.mcasp: ASoC: dai register 48038000.mcasp #1 [ 133.556671] snd_soc_core:snd_soc_register_dais:2634: davinci-mcasp 48038000.mcasp: ASoC: Registered DAI '48038000.mcasp' [ 133.556830] snd_soc_core:snd_soc_add_platform:2892: davinci-mcasp 48038000.mcasp: ASoC: Registered platform '48038000.mcasp' [ 133.606784] snd_soc_core:soc_bind_dai_link:938: davinci_evm sound: ASoC: binding TLV320AIC3X at idx 0 [ 133.607118] snd_soc_core:snd_soc_dapm_new_dai_widgets:3494: tlv320aic3x-codec 2-0018: ASoC: adding Playback widget [ 133.607139] snd_soc_core:snd_soc_dapm_new_dai_widgets:3513: tlv320aic3x-codec 2-0018: ASoC: adding Capture widget [ 133.607704] snd_soc_core:soc_probe_link_dais:1334: davinci_evm sound: ASoC: probe Podtique DaVinci EVM dai link 0 late -2 [ 133.607724] snd_soc_core:soc_probe_link_dais:1334: davinci_evm sound: ASoC: probe Podtique DaVinci EVM dai link 0 late -1 [ 133.607738] snd_soc_core:soc_probe_link_dais:1334: davinci_evm sound: ASoC: probe Podtique DaVinci EVM dai link 0 late 0 [ 133.607752] snd_soc_core:soc_probe_link_dais:1334: davinci_evm sound: ASoC: probe Podtique DaVinci EVM dai link 0 late 1 [ 133.607766] snd_soc_core:soc_probe_link_dais:1334: davinci_evm sound: ASoC: probe Podtique DaVinci EVM dai link 0 late 2 [ 133.607805] davinci_evm sound: ASoC: DAPM unknown pin MONO_LOUT [ 133.627880] snd_soc_core:soc_new_pcm:2510: davinci_evm sound: ASoC: registered pcm #0 AIC3X tlv320aic3x-hifi-0 [ 133.631201] davinci_evm sound: tlv320aic3x-hifi <-> 48038000.mcasp mapping ok [ 133.631252] snd_soc_core:snd_soc_dapm_link_dai_widgets:3570: tlv320aic3x-codec 2-0018: Right ADC -> Capture [ 133.631273] snd_soc_core:snd_soc_dapm_link_dai_widgets:3570: tlv320aic3x-codec 2-0018: Left ADC -> Capture [ 133.631294] snd_soc_core:snd_soc_dapm_link_dai_widgets:3570: tlv320aic3x-codec 2-0018: Playback -> Right DAC [ 133.631308] snd_soc_core:snd_soc_dapm_link_dai_widgets:3570: tlv320aic3x-codec 2-0018: Playback -> Left DAC

...

# speaker-test -r 22050 -c 2 -f 1000 -F S16_LE -t sine -s 1 -D hw:0,0

WCLK is 11.88 kHz, and it is pulses (DSP mode), rather than high for left, low for right for each channel's word. BCLK is 379.5 kHz.

Sounds like you're not in I2S mode, you must be in DSP or left-justified mode. That's set in your eavinci-evm.c in the snd_soc_dai_link structure under the field .dai_fmt. Most of them are set to SND_SOC_DAIFMT_DSP_B.

Interesting you mention that. It in fact does set it to DSP mode. Someone else on the list said for stereo, DSP and I2S modes were the same, and I didn't challenge him on that. I don't know how the code that reads the mcasp0 overlay (and thus reads the op-mode=0 part) communicates with the tlv320aic3x.c code to set the correct i2c register, but seems to not be doing that correctly.

I think it's time I built that tree myself and dropped in some printk() statements. :-/

On Oct 2, 2015, at 08:25 , Caleb Crome caleb@crome.org wrote:

Sent from my iPhone

...

On Oct 2, 2015, at 2:55 AM, Rick Mann rmann@latencyzero.com wrote:

It's pretty exactly 24.00 MHz, ±0.02 MHz.

Oh, it's coming back to me. Perhaps 24 MHz is all the pin can put out. So if you set your sysclk to 24 MHz, then the PLL will get set to the right thing, and give you the right clocks.

My board has its own clock, so I don't actually use the mclk from the bbb.

Well, the other Audio Cape (from Circuitco) seems to get by specifying 12 MHz. I'll try setting it to 24, but it seems weird that they can use 12 and I can't. Maybe they can only use 12 in the 3.8.x kernel, and something broke since then?

Also, you can use DSP mode for stereo just fine. I don't think you need to worry about that at all as long as both sides recognize the format.

Good to know.