[alsa-devel] Wolfson 5102 on Beaglebone Black using ALSA
Hey everybody!
We have been working on integrating the Wolfson 5102 codec with the Beaglebone Black. We’ve made pretty decent progress, got the arizona code in kernel 4.4 registering the wm5102 as ALSA sound card (both player and recorder), have McAsp0 as 24.576 MHz clock source, and have 12 IRQs showing up in /proc/interrupts.
We have been working with sound{compatible = "simple-audio-card”}, but now have hit our first real question. sysclk is hard coded to ‘0’ under simple-audio-card, and we had to hack the kernel and change that to ‘1’ to achieve ALSA sound card registration. We’d all like for this work to proceed without having to hack the kernel, and wondered if one of you might recommend another approach or selection for device tree sound{compatible} that might work out better?
Thanks!
Clark
On Sat, May 14, 2016 at 03:16:18PM -0700, Clark Dunson wrote:
Hey everybody!
We have been working on integrating the Wolfson 5102 codec with the Beaglebone Black. We’ve made pretty decent progress, got the arizona code in kernel 4.4 registering the wm5102 as ALSA sound card (both player and recorder), have McAsp0 as 24.576 MHz clock source, and have 12 IRQs showing up in /proc/interrupts.
We have been working with sound{compatible = "simple-audio-card”}, but now have hit our first real question. sysclk is hard coded to ‘0’ under simple-audio-card, and we had to hack the kernel and change that to ‘1’ to achieve ALSA sound card registration. We’d all like for this work to proceed without having to hack the kernel, and wondered if one of you might recommend another approach or selection for device tree sound{compatible} that might work out better?
Yes unfortunately this part doesn't map that well onto simple card at the moment. Apart from the clock options you mention, simple card currently only calls dai_set_sysclk, which will tie audio interfaces to a clock domain on wm5102 but you also will need to call codec_set_sysclk to configure the clocking domains themselves. Possibly even set_pll as well if you need to configure the PLL.
There are basically two options here, you could improve simple card to add support needed for wm5102, although I am not entirely clear at what point one would consider a part too complex for simple card. Or write a machine driver for wm5102 on Beaglebone Black, a good example to start from for this would be sound/soc/samsung/bells.c.
Thanks, Charles
On 05/15/16 01:16, Clark Dunson wrote:
Hey everybody!
We have been working on integrating the Wolfson 5102 codec with the Beaglebone Black. We’ve made pretty decent progress, got the arizona code in kernel 4.4 registering the wm5102 as ALSA sound card (both player and recorder), have McAsp0 as 24.576 MHz clock source, and have 12 IRQs showing up in /proc/interrupts.
We have been working with sound{compatible = "simple-audio-card”}, but now have hit our first real question. sysclk is hard coded to ‘0’ under simple-audio-card, and we had to hack the kernel and change that to ‘1’ to achieve ALSA sound card registration. We’d all like for this work to proceed without having to hack the kernel, and wondered if one of you might recommend another approach or selection for device tree sound{compatible} that might work out better?
For simple card you would need: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-February/104316.ht... to be able to select the McASP clocks.
It is not going to apply on linux-next becasue of: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-May/107783.html
but it is not should not be a big issue to resolve (one patch to move the clkid to binding header).
The davinci-mcasp driver will remain broken in this sense for a foreseen future as we need to convert the daVinci architecture to CCF first to be able to progress with the clock selection.
Thanks guys,
Cannot thank you enough. We’ll probably go at it from both angles, schedule is very tight. We’ve worked with both the 3.18 cirrus branch, and 4.4 main line, would be so awesome if we could figure a way to write to the wm5102 regmap from user land. (Busybox i2cset is from the stone ages).
Will keep you posted on progress,
Clark
On May 16, 2016, at 5:33 AM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 05/15/16 01:16, Clark Dunson wrote:
Hey everybody!
We have been working on integrating the Wolfson 5102 codec with the Beaglebone Black. We’ve made pretty decent progress, got the arizona code in kernel 4.4 registering the wm5102 as ALSA sound card (both player and recorder), have McAsp0 as 24.576 MHz clock source, and have 12 IRQs showing up in /proc/interrupts.
We have been working with sound{compatible = "simple-audio-card”}, but now have hit our first real question. sysclk is hard coded to ‘0’ under simple-audio-card, and we had to hack the kernel and change that to ‘1’ to achieve ALSA sound card registration. We’d all like for this work to proceed without having to hack the kernel, and wondered if one of you might recommend another approach or selection for device tree sound{compatible} that might work out better?
For simple card you would need: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-February/104316.ht... to be able to select the McASP clocks.
It is not going to apply on linux-next becasue of: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-May/107783.html
but it is not should not be a big issue to resolve (one patch to move the clkid to binding header).
The davinci-mcasp driver will remain broken in this sense for a foreseen future as we need to convert the daVinci architecture to CCF first to be able to progress with the clock selection.
-- Péter
On Tue, May 17, 2016 at 08:12:32AM -0700, Clark Dunson wrote:
Thanks guys,
Cannot thank you enough. We’ll probably go at it from both angles, schedule is very tight. We’ve worked with both the 3.18 cirrus branch, and 4.4 main line, would be so awesome if we could figure a way to write to the wm5102 regmap from user land. (Busybox i2cset is from the stone ages).
You could use debugfs, if you looking in drivers/base/regmap/regmap-debugfs.c and change the undef to a define for REGMAP_ALLOW_WRITE_DEBUGFS. Then you can write registers by echoing register value pairs to the the registers file in debugfs. Be careful though this is only intended for testing and as the define makes all regmaps writable from user-space depending on your system that may let you do things that damage hardware.
Thanks, Charles
We have moved from breadboard to protoboard, and with many orders booked, I daresay that we have moved from experimenting to committed. Our application samples mostly channels of scientific data, but one of audio. Ergo we will have an ongoing interest in the wm5102 and its DSP capabilities. The more processing that we can do on the codec, the better.
We are pursuing Master mode at the moment, where the McAsp on the BBB supplies 24.576 MHz to wm5102 on MCLK1, and then BCLK and WCLK are generated by wm5102. We sample at 8x48k, and are driving AIF1 with dspB format. Also, we have need to send out a calibration signal ~daily, via SPKOUTL.
So far we have simply added our stuff at the end of the arizona-core.c probe, but would like to do it in a more up-streamable way. In looking at the samsung/bells.c driver (thank you again Charles), we realized that anything past basic configurations will be difficult with the device tree alone. The regmap stuff is a nice form of API, easy to deal with.
We had to simply disinvite extcon-arizona from the party though. On both the WM5102-6271-CS137-M-SCH-REV2.03 and our protoboard, JACKDET is an IRQ gone wild. On the Wolfson board, inserting my headphones into the jack shut it up. But on our protoboard, where we left that pin unconnected, we found that the probe of extcon-arizona hard enables JACKDET.
So that's the update, and thanks again for all the help so far.
Clark
On May 22, 2016, at 6:18 AM, Charles Keepax ckeepax@opensource.wolfsonmicro.com wrote:
On Tue, May 17, 2016 at 08:12:32AM -0700, Clark Dunson wrote:
Thanks guys,
Cannot thank you enough. We’ll probably go at it from both angles, schedule is very tight. We’ve worked with both the 3.18 cirrus branch, and 4.4 main line, would be so awesome if we could figure a way to write to the wm5102 regmap from user land. (Busybox i2cset is from the stone ages).
You could use debugfs, if you looking in drivers/base/regmap/regmap-debugfs.c and change the undef to a define for REGMAP_ALLOW_WRITE_DEBUGFS. Then you can write registers by echoing register value pairs to the the registers file in debugfs. Be careful though this is only intended for testing and as the define makes all regmaps writable from user-space depending on your system that may let you do things that damage hardware.
Thanks, Charles
On Fri, May 27, 2016 at 06:58:39PM -0700, Clark Dunson wrote:
We have moved from breadboard to protoboard, and with many orders booked, I daresay that we have moved from experimenting to committed. Our application samples mostly channels of scientific data, but one of audio. Ergo we will have an ongoing interest in the wm5102 and its DSP capabilities. The more processing that we can do on the codec, the better.
There are some hoops to jump through to get access to the necessary compilers etc. for the DSP, although again Joao who I CCed on your other email would be a good place to start the process of getting access to that.
We are pursuing Master mode at the moment, where the McAsp on the BBB supplies 24.576 MHz to wm5102 on MCLK1, and then BCLK and WCLK are generated by wm5102. We sample at 8x48k, and are driving AIF1 with dspB format. Also, we have need to send out a calibration signal ~daily, via SPKOUTL.
All sounds fine.
So far we have simply added our stuff at the end of the arizona-core.c probe, but would like to do it in a more up-streamable way. In looking at the samsung/bells.c driver (thank you again Charles), we realized that anything past basic configurations will be difficult with the device tree alone. The regmap stuff is a nice form of API, easy to deal with.
Yeah please avoid doing this, the driver should support all the features you require from the sound of things. There should be no need to hard code register writes.
What sort of things are you setting up with these register writes? Lets see if I can point you in the direction of the correct place to put some of those.
We had to simply disinvite extcon-arizona from the party though. On both the WM5102-6271-CS137-M-SCH-REV2.03 and our protoboard, JACKDET is an IRQ gone wild. On the Wolfson board, inserting my headphones into the jack shut it up. But on our protoboard, where we left that pin unconnected, we found that the probe of extcon-arizona hard enables JACKDET.
I am surprised you are seeing issues on one of our boards, they are all fairly well tested here. I would quite like to see a kernel log on that one if I can?
Apart from that, this all seems reasonable, the extcon driver exists to control the jack detection. If that is not wired up on your system then not building in this part of the system seems the correct response.
Thanks, Charles
There are some hoops to jump through to get access to the necessary compilers etc. for the DSP, although again Joao who I CCed on your other email would be a good place to start the process of getting access to that.
Thank you, this part may come later this year.
Yeah please avoid doing this, the driver should support all the features you require from the sound of things. There should be no need to hard code register writes.
What sort of things are you setting up with these register writes? Lets see if I can point you in the direction of the correct place to put some of those.
Thanks!
The clocking:
regmap_write(arizona->regmap, ARIZONA_CLOCK_32K_1, 0x00042); // Use Sysclk, Default = 0x0041 regmap_write(arizona->regmap, ARIZONA_SYSTEM_CLOCK_1, 0x0200); // Use MCLK1, and 24.576MHz from BBB McASP, Default = 0x0304
These would seem to be the relevant device tree entries from Documentation/devicetree/bindings/mfd/arizona.txt:
- clocks: Should reference the clocks supplied on MCLK1 and MCLK2 - clock-names: Should contains two strings: "mclk1" for the clock supplied on MCLK1, recommended to be a high quality audio reference clock "mclk2" for the clock supplied on MCLK2, recommended to be an always on 32k clock
Still trying to figure out how to specify these. I have pasted our device tree to the end of this email. (Oh, gpio for BBB McASP clock is deliberately routed away from gpio1_27, because somehow we are not convincing the driver to enable it, and so we have a gpio_set_value(MY_CLOCK_GPIO_ENABLE,1); in arizona-core probe until we figure out how.
We had to simply disinvite extcon-arizona from the party though. On both the WM5102-6271-CS137-M-SCH-REV2.03 and our protoboard, JACKDET is an IRQ gone wild. On the Wolfson board, inserting my headphones into the jack shut it up. But on our protoboard, where we left that pin unconnected, we found that the probe of extcon-arizona hard enables JACKDET.
I am surprised you are seeing issues on one of our boards, they are all fairly well tested here. I would quite like to see a kernel log on that one if I can?
Okay, I’ll hook up the dev board, likely Thurs-Fri after we complete board bring up.
Apart from that, this all seems reasonable, the extcon driver exists to control the jack detection. If that is not wired up on your system then not building in this part of the system seems the correct response.
Thanks, Charles
Thank you, Clark.
Device Tree _______________________________________
/* * 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. */ /dts-v1/;
#include "am33xx.dtsi" #include "am335x-bone-common.dtsi" #include "dt-bindings/mfd/arizona.h"
/ { model = "TI AM335x BeagleBone Black"; compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
leds { pinctrl-names = "default"; pinctrl-0 = <&led_pins_default>; compatible = "gpio-leds";
led@1 { label= "led_ir"; gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; default-state = "off"; };
led@2 { label= "led_red"; gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>; default-state = "off"; }; };
ldo18: ldo18 { compatible = "regulator-fixed"; regulator-name = "DC_1V8"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; enable-active-high; regulator-always-on; };
ldo50: ldo50 { /* BBB VCC_5V */ compatible = "regulator-fixed"; regulator-name = "DC_5V0"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; enable-active-high; regulator-always-on; };
clk_audio_fixed: clk_audio_fixed { #clock-cells = <0>; compatible = "fixed-clock"; clock-frequency = <24576000>; };
clk_audio: clk_audio { #clock-cells = <0>; compatible = "gpio-gate-clock"; clocks = <&clk_audio_fixed>; enable-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>; /* BeagleBone Black Clk enable on GPIO1_27 */ };
sound: sound@0 { status = "okay"; compatible = "simple-audio-card"; simple-audio-card,name = "WM5102"; simple-audio-card,widgets = "Line", "Line In"; simple-audio-card,routing = "IN1L", "Line In", "IN1R", "Line In", "IN2L", "Line In", "IN2R", "Line In", "IN3L", "Line In", "IN3R", "Line In"; /* simple-audio-card,hp-det-gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>; /*TP38*/ /*simple-audio-card,dai-link {*/ simple-audio-card,format = "dsp_b"; simple-audio-card,bitclock-master = <&sound_master>; simple-audio-card,frame-master = <&sound_master>; simple-audio-card,cpu { sound-dai = <&mcasp0>; clocks = <&clk_audio>; /* dai-tdm-slot-num = <6>; dai-tdm-slot-width = <32>; */ }; sound_master: simple-audio-card,codec { sound-dai = <&wm5102>; clocks = <&clk_audio>; system-clock-id = <1>; /* ARIZONA_CLK_SYSCLK */ /* dai-tdm-slot-num = <6>; dai-tdm-slot-width = <32>; */ }; /* };*/
};
};
&ldo3_reg { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-always-on; };
&mmc1 { vmmc-supply = <&vmmcsd_fixed>; };
&mmc2 { vmmc-supply = <&vmmcsd_fixed>; pinctrl-names = "default"; pinctrl-0 = <&emmc_pins>; bus-width = <8>; status = "okay"; };
&am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins { pinctrl-single,pins = < 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */ 0x18c ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (C16) I2C0_SCL.I2C0_SCL */ 0x188 ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (C17) I2C0_SDA.I2C0_SDA */ >; }; nxp_hdmi_bonelt_off_pins: nxp_hdmi_bonelt_off_pins { pinctrl-single,pins = < 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */ 0x18c ( PIN_INPUT | MUX_MODE0 ) /* (C16) I2C0_SCL.I2C0_SCL */ 0x188 ( PIN_INPUT | MUX_MODE0 ) /* (C17) I2C0_SDA.I2C0_SDA */ >; };
led_pins_default: led_pins_default { pinctrl-single,pins = < 0x178 ( PIN_OUTPUT | MUX_MODE7 ) /* (D18) uart1_ctsn.gpio0[12] TP38 */ 0x17c ( PIN_OUTPUT | MUX_MODE7 ) /* (D17) uart1_rtsn.gpio0[13] TP39 */ 0x28 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (T11) gpmc_ad10.gpio0[26] IR LED */ 0x38 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (V13) gpmc_ad14.gpio1[14] RED LED */ >; };
accel_pins_default: accel_pins_default { pinctrl-single,pins = < 0xe8 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (V5) lcd_pclk.gpio2[24] ACCEL_ST */ 0xec ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (R6) lcd_ac_bias_en.gpio2[25] ACCEL_FS */ >; };
mcasp0_slave_pins_default: mcasp0_slave_pins_default { pinctrl-single,pins = < 0x1a0 ( PIN_INPUT | MUX_MODE0 ) /* (B12) mcasp0_aclkr.mcasp0_aclkr */ 0x1a4 ( PIN_INPUT | MUX_MODE0 ) /* (C13) mcasp0_fsr.mcasp0_fsr */ 0x198 ( PIN_INPUT | MUX_MODE0 ) /* (D12) mcasp0_axr0.mcasp0_axr0 */ 0x19c ( PIN_OUTPUT | MUX_MODE2 ) /* (C12) mcasp0_ahclkr.mcasp0_axr2 */ >; };
wm5102_pins_default: wm5102_pins_default { pinctrl-single,pins = < 0x6c ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (V17) gpmc_a11.gpio1[27] 24.576 MHZ CE */ 0x78 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (U18) gpmc_be1n.gpio1[28] /RESET */ 0x7c ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (V6) gpmc_csn0.gpio1[29] LDOENA */ 0xe4 ( PIN_INPUT | MUX_MODE7 ) /* (R5) lcd_hsync.gpio2[23] /IRQ */ 0x1ac ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (A14) mcasp0_ahclkx.gpio3[21] AUDIO_MCLK */ 0x15c ( PIN_INPUT_PULLUP | MUX_MODE2 ) /* (A16) spi0_cs0.I2C1_SCL */ 0x158 ( PIN_INPUT_PULLUP | MUX_MODE2 ) /* (B16) spi0_d1.I2C1_SDA */ 0x164 ( PIN_INPUT | MUX_MODE7 ) /* (C18) eCAP0_in_PWM0_out.gpio0[7] (AUDIO BCLK) HIGHZ*/ >; };
};
&lcdc { status = "disabled"; port { lcdc_0: endpoint@0 { remote-endpoint = <&hdmi_0>; }; }; };
&i2c0 { tda19988 { compatible = "nxp,tda998x"; reg = <0x70>; pinctrl-names = "default", "off"; pinctrl-0 = <&nxp_hdmi_bonelt_pins>; pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
port { hdmi_0: endpoint@0 { remote-endpoint = <&lcdc_0>; }; }; }; };
&i2c1 { pinctrl-names = "default"; pintctrl-0 = <&wm5102_pins_default>; status = "okay"; clock-frequency = <400000>;
wm5102: wm5102@1b { compatible = "wlf,wm5102"; reg = <0x1b>; status = "okay"; /* /IRQ is connected to GPIO2_23. Mask from HiassofT DT for cirrus audio board was 8 */ interrupts = <23 8>; interrupt-controller; #interrupt-cells = <2>; interrupt-parent = <&gpio2>; /*clock-names = "mclk1", "mclk2";*/ gpio-controller; #gpio-cells = <2>; wlf,gpio-defaults = < ARIZONA_GP_FN_TXLRCLK ARIZONA_GP_DEFAULT ARIZONA_GP_DEFAULT ARIZONA_GP_DEFAULT ARIZONA_GP_DEFAULT >; wlf,reset = <&gpio1 28 GPIO_ACTIVE_HIGH>; /* allow /RESET wm5102 by driver (via inverter)*/ wlf,ldoena = <&gpio1 29 GPIO_ACTIVE_HIGH>; /* allow LDOENA wm5102 by driver */ LDOVDD-supply = <&ldo18>; /* fixed 1V8 regulator */ AVDD-supply = <&ldo18>; DBVDD1-supply = <&ldo18>; DBVDD2-supply = <&ldo18>; DBVDD3-supply = <&ldo18>; CPVDD-supply = <&ldo18>; /*DCVDD-supply = <&ldo18>; /* supplied by LDO1 */ MICVDD-supply = <&ldo50>; SPKVDDL-supply = <&ldo50>; /* fixed VDD_5V from BBB */ SPKVDDR-supply = <&ldo50>; #sound-dai-cells = <0>; /* we haven't figured out how reference the internal LDO, pin is pulled up */ #if 0 ldo1: ldo1 { wlf,ldoena = <&gpio1 29 GPIO_ACTIVE_HIGH>; /* allow LDOENA wm5102 by driver */ }; #endif };
};
&mcasp0 { pinctrl-names = "default"; pinctrl-0 = <&mcasp0_slave_pins_default>;
status = "okay"; op-mode = <0>; /* MCASP_IIS_MODE */ tdm-slots = <6>; /* 4 serializers */ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX - 0 2 0 0 */ 2 0 0 0 >; tx-num-evt = <32>; rx-num-evt = <32>; #sound-dai-cells = <0>; };
&rtc { system-power-controller; };
On Mon, May 30, 2016 at 08:18:17AM -0700, Clark Dunson wrote:
There are some hoops to jump through to get access to the necessary compilers etc. for the DSP, although again Joao who I CCed on your other email would be a good place to start the process of getting access to that.
Thank you, this part may come later this year.
Yeah please avoid doing this, the driver should support all the features you require from the sound of things. There should be no need to hard code register writes.
What sort of things are you setting up with these register writes? Lets see if I can point you in the direction of the correct place to put some of those.
Thanks!
The clocking:
regmap_write(arizona->regmap, ARIZONA_CLOCK_32K_1, 0x00042); // Use Sysclk, Default = 0x0041
Ah that one, yeah that is a problem. Generally very few of our customers use the system without a 32k clock on MCLK2. There is indeed no way to specify this right now other than this hack. I am working on a series of clocking patches which you refer to the binding doc on below but those are going to take a while to get merged. The issue is that the clocking framework really doesn't play nice with the SPI framework at this point in time and that needs to get sorted before I can merge them. Are you looking to upstream support for this board as you develope it? We might have to have a think about how we are going to support this one.
regmap_write(arizona->regmap, ARIZONA_SYSTEM_CLOCK_1, 0x0200); // Use MCLK1, and 24.576MHz from BBB McASP, Default = 0x0304
For this one you just need to add this call to your machine driver (late probe is usually a good place):
snd_soc_codec_set_sysclk(codec, ARIZONA_CLK_SYSCLK, ARIZONA_CLK_SRC_MCLK1, 24576000, SND_SOC_CLOCK_IN);
Although appreciate that is a little harder if you are using simple card.
These would seem to be the relevant device tree entries from Documentation/devicetree/bindings/mfd/arizona.txt:
- clocks: Should reference the clocks supplied on MCLK1 and MCLK2
- clock-names: Should contains two strings: "mclk1" for the clock supplied on MCLK1, recommended to be a high quality audio reference clock "mclk2" for the clock supplied on MCLK2, recommended to be an always on 32k clock
Still trying to figure out how to specify these. I have pasted our device tree to the end of this email. (Oh, gpio for BBB McASP clock is deliberately routed away from gpio1_27, because somehow we are not convincing the driver to enable it, and so we have a gpio_set_value(MY_CLOCK_GPIO_ENABLE,1); in arizona-core probe until we figure out how.
Didn't actually think these where merged yet, ok well. The binding is good but the driver has no support for it yet.
We had to simply disinvite extcon-arizona from the party though. On both the WM5102-6271-CS137-M-SCH-REV2.03 and our protoboard, JACKDET is an IRQ gone wild. On the Wolfson board, inserting my headphones into the jack shut it up. But on our protoboard, where we left that pin unconnected, we found that the probe of extcon-arizona hard enables JACKDET.
I am surprised you are seeing issues on one of our boards, they are all fairly well tested here. I would quite like to see a kernel log on that one if I can?
Okay, I’ll hook up the dev board, likely Thurs-Fri after we complete board bring up.
Apart from that, this all seems reasonable, the extcon driver exists to control the jack detection. If that is not wired up on your system then not building in this part of the system seems the correct response.
Thanks, Charles
Thank you, Clark.
Device Tree _______________________________________
/*
- 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.
*/ /dts-v1/;
#include "am33xx.dtsi" #include "am335x-bone-common.dtsi" #include "dt-bindings/mfd/arizona.h"
/ { model = "TI AM335x BeagleBone Black"; compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
leds { pinctrl-names = "default"; pinctrl-0 = <&led_pins_default>; compatible = "gpio-leds";
led@1 { label= "led_ir"; gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; default-state = "off"; }; led@2 { label= "led_red"; gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>; default-state = "off"; };};
ldo18: ldo18 { compatible = "regulator-fixed"; regulator-name = "DC_1V8"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; enable-active-high; regulator-always-on; };
ldo50: ldo50 { /* BBB VCC_5V */ compatible = "regulator-fixed"; regulator-name = "DC_5V0"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; enable-active-high; regulator-always-on; };
clk_audio_fixed: clk_audio_fixed { #clock-cells = <0>; compatible = "fixed-clock"; clock-frequency = <24576000>; };
clk_audio: clk_audio { #clock-cells = <0>; compatible = "gpio-gate-clock"; clocks = <&clk_audio_fixed>; enable-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>; /* BeagleBone Black Clk enable on GPIO1_27 */ };
sound: sound@0 { status = "okay"; compatible = "simple-audio-card"; simple-audio-card,name = "WM5102"; simple-audio-card,widgets = "Line", "Line In"; simple-audio-card,routing = "IN1L", "Line In", "IN1R", "Line In", "IN2L", "Line In", "IN2R", "Line In", "IN3L", "Line In", "IN3R", "Line In"; /* simple-audio-card,hp-det-gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>; /*TP38*/ /*simple-audio-card,dai-link {*/ simple-audio-card,format = "dsp_b"; simple-audio-card,bitclock-master = <&sound_master>; simple-audio-card,frame-master = <&sound_master>; simple-audio-card,cpu { sound-dai = <&mcasp0>; clocks = <&clk_audio>; /* dai-tdm-slot-num = <6>; dai-tdm-slot-width = <32>; */ }; sound_master: simple-audio-card,codec { sound-dai = <&wm5102>; clocks = <&clk_audio>; system-clock-id = <1>; /* ARIZONA_CLK_SYSCLK */ /* dai-tdm-slot-num = <6>; dai-tdm-slot-width = <32>; */ }; /* };*/
};
};
&ldo3_reg { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-always-on; };
&mmc1 { vmmc-supply = <&vmmcsd_fixed>; };
&mmc2 { vmmc-supply = <&vmmcsd_fixed>; pinctrl-names = "default"; pinctrl-0 = <&emmc_pins>; bus-width = <8>; status = "okay"; };
&am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins { pinctrl-single,pins = < 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */ 0x18c ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (C16) I2C0_SCL.I2C0_SCL */ 0x188 ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (C17) I2C0_SDA.I2C0_SDA */ >; };
nxp_hdmi_bonelt_off_pins: nxp_hdmi_bonelt_off_pins { pinctrl-single,pins = < 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */ 0x18c ( PIN_INPUT | MUX_MODE0 ) /* (C16) I2C0_SCL.I2C0_SCL */ 0x188 ( PIN_INPUT | MUX_MODE0 ) /* (C17) I2C0_SDA.I2C0_SDA */ >; };
led_pins_default: led_pins_default { pinctrl-single,pins = < 0x178 ( PIN_OUTPUT | MUX_MODE7 ) /* (D18) uart1_ctsn.gpio0[12] TP38 */ 0x17c ( PIN_OUTPUT | MUX_MODE7 ) /* (D17) uart1_rtsn.gpio0[13] TP39 */ 0x28 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (T11) gpmc_ad10.gpio0[26] IR LED */ 0x38 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (V13) gpmc_ad14.gpio1[14] RED LED */ >; };
accel_pins_default: accel_pins_default { pinctrl-single,pins = < 0xe8 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (V5) lcd_pclk.gpio2[24] ACCEL_ST */ 0xec ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (R6) lcd_ac_bias_en.gpio2[25] ACCEL_FS */ >; };
mcasp0_slave_pins_default: mcasp0_slave_pins_default { pinctrl-single,pins = < 0x1a0 ( PIN_INPUT | MUX_MODE0 ) /* (B12) mcasp0_aclkr.mcasp0_aclkr */ 0x1a4 ( PIN_INPUT | MUX_MODE0 ) /* (C13) mcasp0_fsr.mcasp0_fsr */ 0x198 ( PIN_INPUT | MUX_MODE0 ) /* (D12) mcasp0_axr0.mcasp0_axr0 */ 0x19c ( PIN_OUTPUT | MUX_MODE2 ) /* (C12) mcasp0_ahclkr.mcasp0_axr2 */ >; };
wm5102_pins_default: wm5102_pins_default { pinctrl-single,pins = < 0x6c ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (V17) gpmc_a11.gpio1[27] 24.576 MHZ CE */ 0x78 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (U18) gpmc_be1n.gpio1[28] /RESET */ 0x7c ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (V6) gpmc_csn0.gpio1[29] LDOENA */ 0xe4 ( PIN_INPUT | MUX_MODE7 ) /* (R5) lcd_hsync.gpio2[23] /IRQ */ 0x1ac ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (A14) mcasp0_ahclkx.gpio3[21] AUDIO_MCLK */ 0x15c ( PIN_INPUT_PULLUP | MUX_MODE2 ) /* (A16) spi0_cs0.I2C1_SCL */ 0x158 ( PIN_INPUT_PULLUP | MUX_MODE2 ) /* (B16) spi0_d1.I2C1_SDA */ 0x164 ( PIN_INPUT | MUX_MODE7 ) /* (C18) eCAP0_in_PWM0_out.gpio0[7] (AUDIO BCLK) HIGHZ*/ >; };
};
&lcdc { status = "disabled"; port { lcdc_0: endpoint@0 { remote-endpoint = <&hdmi_0>; }; }; };
&i2c0 { tda19988 { compatible = "nxp,tda998x"; reg = <0x70>; pinctrl-names = "default", "off"; pinctrl-0 = <&nxp_hdmi_bonelt_pins>; pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
port { hdmi_0: endpoint@0 { remote-endpoint = <&lcdc_0>; }; };}; };
&i2c1 { pinctrl-names = "default"; pintctrl-0 = <&wm5102_pins_default>; status = "okay"; clock-frequency = <400000>;
wm5102: wm5102@1b { compatible = "wlf,wm5102"; reg = <0x1b>; status = "okay"; /* /IRQ is connected to GPIO2_23. Mask from HiassofT DT for cirrus audio board was 8 */ interrupts = <23 8>; interrupt-controller; #interrupt-cells = <2>; interrupt-parent = <&gpio2>; /*clock-names = "mclk1", "mclk2";*/ gpio-controller; #gpio-cells = <2>; wlf,gpio-defaults = < ARIZONA_GP_FN_TXLRCLK ARIZONA_GP_DEFAULT ARIZONA_GP_DEFAULT ARIZONA_GP_DEFAULT ARIZONA_GP_DEFAULT >; wlf,reset = <&gpio1 28 GPIO_ACTIVE_HIGH>; /* allow /RESET wm5102 by driver (via inverter)*/ wlf,ldoena = <&gpio1 29 GPIO_ACTIVE_HIGH>; /* allow LDOENA wm5102 by driver */
This here is the correct place for the ldoena.
LDOVDD-supply = <&ldo18>; /* fixed 1V8 regulator */ AVDD-supply = <&ldo18>; DBVDD1-supply = <&ldo18>; DBVDD2-supply = <&ldo18>; DBVDD3-supply = <&ldo18>; CPVDD-supply = <&ldo18>; /*DCVDD-supply = <&ldo18>; /* supplied by LDO1
Yeah this line can go you don't need to specify DCVDD unless you are not using the internal LDO.
MICVDD-supply = <&ldo50>; SPKVDDL-supply = <&ldo50>; /* fixed VDD_5V from BBB */ SPKVDDR-supply = <&ldo50>; #sound-dai-cells = <0>;/* we haven't figured out how reference the internal LDO, pin is pulled up */ #if 0 ldo1: ldo1 { wlf,ldoena = <&gpio1 29 GPIO_ACTIVE_HIGH>; /* allow LDOENA wm5102 by driver */ }; #endif
This can go as well again no need to specify a block for internal LDO unless you want to do some strange configuration of it which you almost certainly don't.
};};
&mcasp0 { pinctrl-names = "default"; pinctrl-0 = <&mcasp0_slave_pins_default>;
status = "okay"; op-mode = <0>; /* MCASP_IIS_MODE */tdm-slots = <6>; /* 4 serializers */ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX - 0 2 0 0 */ 2 0 0 0 >; tx-num-evt = <32>; rx-num-evt = <32>; #sound-dai-cells = <0>; };
&rtc { system-power-controller; };
Hello Charles, Peter, and Mark
Another progress report, some feedback, and a question.
We have everything pretty much working now.
The clocking configuration I identified in an earlier post, (ie. MCLK1 begin fed from BBB McASP0 24.576 MHz, and BCLK being derived from it) works, though we still have a patch to arizona-core.c to make it so. Ready for any inputs on how we can make this change so we can upstream it.
Selecting single-ended mode vs. differential mode being a pairwise choice (ie. one selection for IN1, not independently for L/R), caught us by surprise and required a harrowing ECO. (This selection appears to also not be supported by the driver) In the end we had to abandon single-ended mode, as the PGA acted in a manner that defied our understanding. To wit: If we had a signal connected to IN2LP, (AC through 1uF capacitor), then what we did with IN2LN was pivotal. If we connected I2LN to ground, the signal would have large positive offsets, eg. +0.5 on WAV scale of 1.0 to +1.0, with unity gain set on PGA, Digital Volume, and mixer. Cranking the PGA gain would rail the signal in a positive direction before we had adequate gain. If we left IN2LN floating, we got closer to zero-centered, but when we set PGA to +6dB, we got huge negative offsets (-0.6 on WAV scale) and still we were dead in the water. Finally we connected a 1uF capacitor to 1N2LN, and set back to differential mode (default). Life is better now.
In our status meeting yesterday, we concluded that our moving forward with thousands of units would be benefited both on our side and Wolfson’s by an FAE as a go between. Is your Cupertino office still alive (we are in Bay area), or can we get a point of contact? Is it Joao?
Thanks!
Clark
(Once we complete board bringup, I’ll put together a more detailed post mortem and fwd to Charles/Mark. And thanks again.)
On May 30, 2016, at 10:19 AM, Charles Keepax ckeepax@opensource.wolfsonmicro.com wrote:
On Mon, May 30, 2016 at 08:18:17AM -0700, Clark Dunson wrote:
There are some hoops to jump through to get access to the necessary compilers etc. for the DSP, although again Joao who I CCed on your other email would be a good place to start the process of getting access to that.
Thank you, this part may come later this year.
Yeah please avoid doing this, the driver should support all the features you require from the sound of things. There should be no need to hard code register writes.
What sort of things are you setting up with these register writes? Lets see if I can point you in the direction of the correct place to put some of those.
Thanks!
The clocking:
regmap_write(arizona->regmap, ARIZONA_CLOCK_32K_1, 0x00042); // Use Sysclk, Default = 0x0041
Ah that one, yeah that is a problem. Generally very few of our customers use the system without a 32k clock on MCLK2. There is indeed no way to specify this right now other than this hack. I am working on a series of clocking patches which you refer to the binding doc on below but those are going to take a while to get merged. The issue is that the clocking framework really doesn't play nice with the SPI framework at this point in time and that needs to get sorted before I can merge them. Are you looking to upstream support for this board as you develope it? We might have to have a think about how we are going to support this one.
regmap_write(arizona->regmap, ARIZONA_SYSTEM_CLOCK_1, 0x0200); // Use MCLK1, and 24.576MHz from BBB McASP, Default = 0x0304
For this one you just need to add this call to your machine driver (late probe is usually a good place):
snd_soc_codec_set_sysclk(codec, ARIZONA_CLK_SYSCLK, ARIZONA_CLK_SRC_MCLK1, 24576000, SND_SOC_CLOCK_IN);
Although appreciate that is a little harder if you are using simple card.
These would seem to be the relevant device tree entries from Documentation/devicetree/bindings/mfd/arizona.txt:
- clocks: Should reference the clocks supplied on MCLK1 and MCLK2
- clock-names: Should contains two strings: "mclk1" for the clock supplied on MCLK1, recommended to be a high quality audio reference clock "mclk2" for the clock supplied on MCLK2, recommended to be an always on 32k clock
Still trying to figure out how to specify these. I have pasted our device tree to the end of this email. (Oh, gpio for BBB McASP clock is deliberately routed away from gpio1_27, because somehow we are not convincing the driver to enable it, and so we have a gpio_set_value(MY_CLOCK_GPIO_ENABLE,1); in arizona-core probe until we figure out how.
Didn't actually think these where merged yet, ok well. The binding is good but the driver has no support for it yet.
We had to simply disinvite extcon-arizona from the party though. On both the WM5102-6271-CS137-M-SCH-REV2.03 and our protoboard, JACKDET is an IRQ gone wild. On the Wolfson board, inserting my headphones into the jack shut it up. But on our protoboard, where we left that pin unconnected, we found that the probe of extcon-arizona hard enables JACKDET.
I am surprised you are seeing issues on one of our boards, they are all fairly well tested here. I would quite like to see a kernel log on that one if I can?
Okay, I’ll hook up the dev board, likely Thurs-Fri after we complete board bring up.
Apart from that, this all seems reasonable, the extcon driver exists to control the jack detection. If that is not wired up on your system then not building in this part of the system seems the correct response.
Thanks, Charles
Thank you, Clark.
Device Tree _______________________________________
/*
- 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.
*/ /dts-v1/;
#include "am33xx.dtsi" #include "am335x-bone-common.dtsi" #include "dt-bindings/mfd/arizona.h"
/ { model = "TI AM335x BeagleBone Black"; compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
leds { pinctrl-names = "default"; pinctrl-0 = <&led_pins_default>; compatible = "gpio-leds";
led@1 { label= "led_ir"; gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>; default-state = "off"; }; led@2 { label= "led_red"; gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>; default-state = "off"; };};
ldo18: ldo18 { compatible = "regulator-fixed"; regulator-name = "DC_1V8"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; enable-active-high; regulator-always-on; };
ldo50: ldo50 { /* BBB VCC_5V */ compatible = "regulator-fixed"; regulator-name = "DC_5V0"; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; enable-active-high; regulator-always-on; };
clk_audio_fixed: clk_audio_fixed { #clock-cells = <0>; compatible = "fixed-clock"; clock-frequency = <24576000>; };
clk_audio: clk_audio { #clock-cells = <0>; compatible = "gpio-gate-clock"; clocks = <&clk_audio_fixed>; enable-gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>; /* BeagleBone Black Clk enable on GPIO1_27 */ };
sound: sound@0 { status = "okay"; compatible = "simple-audio-card"; simple-audio-card,name = "WM5102"; simple-audio-card,widgets = "Line", "Line In"; simple-audio-card,routing = "IN1L", "Line In", "IN1R", "Line In", "IN2L", "Line In", "IN2R", "Line In", "IN3L", "Line In", "IN3R", "Line In"; /* simple-audio-card,hp-det-gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>; /*TP38*/ /*simple-audio-card,dai-link {*/ simple-audio-card,format = "dsp_b"; simple-audio-card,bitclock-master = <&sound_master>; simple-audio-card,frame-master = <&sound_master>; simple-audio-card,cpu { sound-dai = <&mcasp0>; clocks = <&clk_audio>; /* dai-tdm-slot-num = <6>; dai-tdm-slot-width = <32>; */ }; sound_master: simple-audio-card,codec { sound-dai = <&wm5102>; clocks = <&clk_audio>; system-clock-id = <1>; /* ARIZONA_CLK_SYSCLK */ /* dai-tdm-slot-num = <6>; dai-tdm-slot-width = <32>; */ }; /* };*/
};
};
&ldo3_reg { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; regulator-always-on; };
&mmc1 { vmmc-supply = <&vmmcsd_fixed>; };
&mmc2 { vmmc-supply = <&vmmcsd_fixed>; pinctrl-names = "default"; pinctrl-0 = <&emmc_pins>; bus-width = <8>; status = "okay"; };
&am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins { pinctrl-single,pins = < 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */ 0x18c ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (C16) I2C0_SCL.I2C0_SCL */ 0x188 ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (C17) I2C0_SDA.I2C0_SDA */ >; };
nxp_hdmi_bonelt_off_pins: nxp_hdmi_bonelt_off_pins { pinctrl-single,pins = < 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */ 0x18c ( PIN_INPUT | MUX_MODE0 ) /* (C16) I2C0_SCL.I2C0_SCL */ 0x188 ( PIN_INPUT | MUX_MODE0 ) /* (C17) I2C0_SDA.I2C0_SDA */ >; };
led_pins_default: led_pins_default { pinctrl-single,pins = < 0x178 ( PIN_OUTPUT | MUX_MODE7 ) /* (D18) uart1_ctsn.gpio0[12] TP38 */ 0x17c ( PIN_OUTPUT | MUX_MODE7 ) /* (D17) uart1_rtsn.gpio0[13] TP39 */ 0x28 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (T11) gpmc_ad10.gpio0[26] IR LED */ 0x38 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (V13) gpmc_ad14.gpio1[14] RED LED */ >; };
accel_pins_default: accel_pins_default { pinctrl-single,pins = < 0xe8 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (V5) lcd_pclk.gpio2[24] ACCEL_ST */ 0xec ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (R6) lcd_ac_bias_en.gpio2[25] ACCEL_FS */ >; };
mcasp0_slave_pins_default: mcasp0_slave_pins_default { pinctrl-single,pins = < 0x1a0 ( PIN_INPUT | MUX_MODE0 ) /* (B12) mcasp0_aclkr.mcasp0_aclkr */ 0x1a4 ( PIN_INPUT | MUX_MODE0 ) /* (C13) mcasp0_fsr.mcasp0_fsr */ 0x198 ( PIN_INPUT | MUX_MODE0 ) /* (D12) mcasp0_axr0.mcasp0_axr0 */ 0x19c ( PIN_OUTPUT | MUX_MODE2 ) /* (C12) mcasp0_ahclkr.mcasp0_axr2 */ >; };
wm5102_pins_default: wm5102_pins_default { pinctrl-single,pins = < 0x6c ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (V17) gpmc_a11.gpio1[27] 24.576 MHZ CE */ 0x78 ( PIN_OUTPUT_PULLDOWN | MUX_MODE7 ) /* (U18) gpmc_be1n.gpio1[28] /RESET */ 0x7c ( PIN_OUTPUT_PULLUP | MUX_MODE7 ) /* (V6) gpmc_csn0.gpio1[29] LDOENA */ 0xe4 ( PIN_INPUT | MUX_MODE7 ) /* (R5) lcd_hsync.gpio2[23] /IRQ */ 0x1ac ( PIN_INPUT_PULLUP | MUX_MODE0 ) /* (A14) mcasp0_ahclkx.gpio3[21] AUDIO_MCLK */ 0x15c ( PIN_INPUT_PULLUP | MUX_MODE2 ) /* (A16) spi0_cs0.I2C1_SCL */ 0x158 ( PIN_INPUT_PULLUP | MUX_MODE2 ) /* (B16) spi0_d1.I2C1_SDA */ 0x164 ( PIN_INPUT | MUX_MODE7 ) /* (C18) eCAP0_in_PWM0_out.gpio0[7] (AUDIO BCLK) HIGHZ*/ >; };
};
&lcdc { status = "disabled"; port { lcdc_0: endpoint@0 { remote-endpoint = <&hdmi_0>; }; }; };
&i2c0 { tda19988 { compatible = "nxp,tda998x"; reg = <0x70>; pinctrl-names = "default", "off"; pinctrl-0 = <&nxp_hdmi_bonelt_pins>; pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
port { hdmi_0: endpoint@0 { remote-endpoint = <&lcdc_0>; }; };}; };
&i2c1 { pinctrl-names = "default"; pintctrl-0 = <&wm5102_pins_default>; status = "okay"; clock-frequency = <400000>;
wm5102: wm5102@1b { compatible = "wlf,wm5102"; reg = <0x1b>; status = "okay"; /* /IRQ is connected to GPIO2_23. Mask from HiassofT DT for cirrus audio board was 8 */ interrupts = <23 8>; interrupt-controller; #interrupt-cells = <2>; interrupt-parent = <&gpio2>; /*clock-names = "mclk1", "mclk2";*/ gpio-controller; #gpio-cells = <2>; wlf,gpio-defaults = < ARIZONA_GP_FN_TXLRCLK ARIZONA_GP_DEFAULT ARIZONA_GP_DEFAULT ARIZONA_GP_DEFAULT ARIZONA_GP_DEFAULT >; wlf,reset = <&gpio1 28 GPIO_ACTIVE_HIGH>; /* allow /RESET wm5102 by driver (via inverter)*/ wlf,ldoena = <&gpio1 29 GPIO_ACTIVE_HIGH>; /* allow LDOENA wm5102 by driver */This here is the correct place for the ldoena.
LDOVDD-supply = <&ldo18>; /* fixed 1V8 regulator */ AVDD-supply = <&ldo18>; DBVDD1-supply = <&ldo18>; DBVDD2-supply = <&ldo18>; DBVDD3-supply = <&ldo18>; CPVDD-supply = <&ldo18>; /*DCVDD-supply = <&ldo18>; /* supplied by LDO1Yeah this line can go you don't need to specify DCVDD unless you are not using the internal LDO.
MICVDD-supply = <&ldo50>; SPKVDDL-supply = <&ldo50>; /* fixed VDD_5V from BBB */ SPKVDDR-supply = <&ldo50>; #sound-dai-cells = <0>;/* we haven't figured out how reference the internal LDO, pin is pulled up */ #if 0 ldo1: ldo1 { wlf,ldoena = <&gpio1 29 GPIO_ACTIVE_HIGH>; /* allow LDOENA wm5102 by driver */ }; #endif
This can go as well again no need to specify a block for internal LDO unless you want to do some strange configuration of it which you almost certainly don't.
};};
&mcasp0 { pinctrl-names = "default"; pinctrl-0 = <&mcasp0_slave_pins_default>;
status = "okay"; op-mode = <0>; /* MCASP_IIS_MODE */tdm-slots = <6>; /* 4 serializers */ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX - 0 2 0 0 */ 2 0 0 0
;
tx-num-evt = <32>; rx-num-evt = <32>; #sound-dai-cells = <0>;};
&rtc { system-power-controller; };
On Wed, Jun 15, 2016 at 09:14:39AM -0700, Clark Dunson wrote:
Hello Charles, Peter, and Mark
Another progress report, some feedback, and a question.
We have everything pretty much working now.
The clocking configuration I identified in an earlier post, (ie. MCLK1 begin fed from BBB McASP0 24.576 MHz, and BCLK being derived from it) works, though we still have a patch to arizona-core.c to make it so. Ready for any inputs on how we can make this change so we can upstream it.
This week is very busy for me let me put together some stuff and get back to you next week on this one. I have some changes that add the stuff required but it probably needs to be reshuffled so we can get it upstream in a reasonable time frame.
Selecting single-ended mode vs. differential mode being a pairwise choice (ie. one selection for IN1, not independently for L/R), caught us by surprise and required a harrowing ECO. (This selection appears to also not be supported by the driver) In the end we had to abandon single-ended mode, as
The wlf,inmode device tree entry lets you select between differencial and single ended.
the PGA acted in a manner that defied our understanding. To wit: If we had a signal connected to IN2LP, (AC through 1uF capacitor), then what we did with IN2LN was pivotal. If we connected I2LN to ground, the signal would have large positive offsets, eg. +0.5 on WAV scale of 1.0 to +1.0, with unity gain set on PGA, Digital Volume, and mixer. Cranking the PGA gain would rail the signal in a positive direction before we had adequate gain. If we left IN2LN floating, we got closer to zero-centered, but when we set PGA to +6dB, we got huge negative offsets (-0.6 on WAV scale) and still we were dead in the water. Finally we connected a 1uF capacitor to 1N2LN, and set back to differential mode (default). Life is better now.
Alas I am afraid you have exceeded my understanding of electronics here, you would need to discuss this with one of our hardware FAEs. I do know we have used both single ended and differencial in the past, but I am at a loss to explain what you are seeing there.
In our status meeting yesterday, we concluded that our moving forward with thousands of units would be benefited both on our side and Wolfson’s by an FAE as a go between. Is your Cupertino office still alive (we are in Bay area), or can we get a point of contact? Is it Joao?
Yes Joao is probably a good place to start, and we do still have the Cupertino office.
Thanks, Charles
participants (3)
-
Charles Keepax -
Clark Dunson -
Peter Ujfalusi