Wolfson 5102 on Beaglebone Black using ALSA

Wolfson 5102 on Beaglebone Black using ALSA

[Clark Dunson]

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

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

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Charles Keepax]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Peter Ujfalusi]

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.html
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

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Clark Dunson]

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.html
> 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

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Charles Keepax]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Clark Dunson]

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

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

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Charles Keepax]

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

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Clark Dunson]

> 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;
};



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

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Charles Keepax]

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;
> };
> 
> 
> 
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Clark Dunson]

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 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;
>> };
>> 
>> 
>> 

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

Re: Wolfson 5102 on Beaglebone Black using ALSA

[Charles Keepax]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel