Audio glitch with SGTL5000

Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi guys,

I'm observing a specific issue with SGTL5000 - after I stop the audio
playback, after several seconds there's a single strong audio glitch
(thump, pulse). In my case the audio codec is directly connected to the
product speaker amps (without any attenuators) and the experience can
be hardly described as pleasant...

I traced this behavior to the Linux kernel DAPM (Dynamic Audio Power
Management), which turns off all the analog and digital circuitry after
there's no audio stream for several seconds.

It looks like DAPM is not designed to be switched off, so I had to do
some (brutal) surgery to quick-solve the issue. I still have the
following gut feelings:
1. If this is an widespread issue, others should have seen it already.
2. If not, than maybe I have issue with my device tree and/or kernel
config.

Some info about my setup - imx6d, kernel 3.10.17-1.0.0ga, yocto daisy,
direct ALSA playback. Here's an extract of my DT audio settings:

sound {
	compatible = "fsl,imx-audio-sgtl5000";
	model = "imx6-myboard-sgtl5000";
	ssi-controller = <&ssi1>;
	audio-codec = <&codec>;
	audio-routing =
		"MIC_IN", "Mic Jack",
		"Mic Jack", "Mic Bias",
		"Headphone Jack", "HP_OUT";
	mux-int-port = <1>;
	mux-ext-port = <3>;
};

&ssi1 {
	fsl,mode = "i2s-slave";
	status = "okay";
};

Please share if you have observed similar behavior on your boards.
Thanks in advance!

Kind regards,
Nikolay

Re: Audio glitch with SGTL5000

[Fabio Estevam]

On Tue, Jan 20, 2015 at 8:12 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Hi guys,
>
> I'm observing a specific issue with SGTL5000 - after I stop the audio
> playback, after several seconds there's a single strong audio glitch
> (thump, pulse). In my case the audio codec is directly connected to the
> product speaker amps (without any attenuators) and the experience can
> be hardly described as pleasant...

Does this patch help?
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/sound/soc/codecs/sgtl5000.c?id=c251ea7bd7a04f1f2575467e0de76e803cf59149

Regards,

Fabio Estevam

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Fabio,

On 01/21/2015 12:23 AM, Fabio Estevam wrote:
> On Tue, Jan 20, 2015 at 8:12 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> Hi guys,
>>
>> I'm observing a specific issue with SGTL5000 - after I stop the audio
>> playback, after several seconds there's a single strong audio glitch
>> (thump, pulse). In my case the audio codec is directly connected to the
>> product speaker amps (without any attenuators) and the experience can
>> be hardly described as pleasant...
>
> Does this patch help?
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/sound/soc/codecs/sgtl5000.c?id=c251ea7bd7a04f1f2575467e0de76e803cf59149

Thanks for your fast answer! Just tried the patch, but unfortunately it
doesn't solve my issue - the pop is still observed on line-out.

I tried to reproduce the issue also with the integrated headphone amp,
just to find out that my board design has an issue (oops!) - the
headphones' ground is connected to the power supply ground instead of
the virtual ground, so I can't test the VAG ramp fix this way. So I can
only speculate that you tested your fix on a properly wired headphone
output, and that's where it worked OK.

Btw, I verified with a protocol analyzer whether the kernel actually
sends the proper I2C commands to the audio codec, and I can confirm
that all commands are sent and acknowledged as expected (including the
SMALL_POP bit setting).

My quick-fix for this was to remove almost all DAPM widgets and
configure the registers only once at start, and this avoid the
pop/click on line-out:


diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index ea47938..1223fb7 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -142,32 +142,6 @@ static int mic_bias_event(struct 
snd_soc_dapm_widget *w,
  	return 0;
  }

-/*
- * As manual described, ADC/DAC only works when VAG powerup,
- * So enabled VAG before ADC/DAC up.
- * In power down case, we need wait 400ms when vag fully ramped down.
- */
-static int power_vag_event(struct snd_soc_dapm_widget *w,
-	struct snd_kcontrol *kcontrol, int event)
-{
-	switch (event) {
-	case SND_SOC_DAPM_PRE_PMU:
-		snd_soc_update_bits(w->codec, SGTL5000_CHIP_ANA_POWER,
-			SGTL5000_VAG_POWERUP, SGTL5000_VAG_POWERUP);
-		break;
-
-	case SND_SOC_DAPM_POST_PMD:
-		snd_soc_update_bits(w->codec, SGTL5000_CHIP_ANA_POWER,
-			SGTL5000_VAG_POWERUP, 0);
-		msleep(400);
-		break;
-	default:
-		break;
-	}
-
-	return 0;
-}
-
  /* input sources for ADC */
  static const char *adc_mux_text[] = {
  	"MIC_IN", "LINE_IN"
@@ -201,50 +175,15 @@ static const struct snd_soc_dapm_widget 
sgtl5000_dapm_widgets[] = {
  			    mic_bias_event,
  			    SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD),

-	SND_SOC_DAPM_PGA("HP", SGTL5000_CHIP_ANA_POWER, 4, 0, NULL, 0),
-	SND_SOC_DAPM_PGA("LO", SGTL5000_CHIP_ANA_POWER, 0, 0, NULL, 0),
-
  	SND_SOC_DAPM_MUX("Capture Mux", SND_SOC_NOPM, 0, 0, &adc_mux),
  	SND_SOC_DAPM_MUX("Headphone Mux", SND_SOC_NOPM, 0, 0, &dac_mux),
-
-	/* aif for i2s input */
-	SND_SOC_DAPM_AIF_IN("AIFIN", "Playback",
-				0, SGTL5000_CHIP_DIG_POWER,
-				0, 0),
-
-	/* aif for i2s output */
-	SND_SOC_DAPM_AIF_OUT("AIFOUT", "Capture",
-				0, SGTL5000_CHIP_DIG_POWER,
-				1, 0),
-
-	SND_SOC_DAPM_SUPPLY("VAG_POWER", SGTL5000_CHIP_ANA_POWER, 7, 0,
-			    power_vag_event,
-			    SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
-
-	SND_SOC_DAPM_ADC("ADC", "Capture", SGTL5000_CHIP_ANA_POWER, 1, 0),
-	SND_SOC_DAPM_DAC("DAC", "Playback", SGTL5000_CHIP_ANA_POWER, 3, 0),
  };

  /* routes for sgtl5000 */
  static const struct snd_soc_dapm_route sgtl5000_dapm_routes[] = {
  	{"Capture Mux", "LINE_IN", "LINE_IN"},	/* line_in --> adc_mux */
  	{"Capture Mux", "MIC_IN", "MIC_IN"},	/* mic_in --> adc_mux */
-
-	{"ADC", NULL, "VAG_POWER"},
-	{"ADC", NULL, "Capture Mux"},		/* adc_mux --> adc */
-	{"AIFOUT", NULL, "ADC"},		/* adc --> i2s_out */
-
-	{"DAC", NULL, "VAG_POWER"},
-	{"DAC", NULL, "AIFIN"},			/* i2s-->dac,skip audio mux */
-	{"Headphone Mux", "DAC", "DAC"},	/* dac --> hp_mux */
-	{"LO", NULL, "DAC"},			/* dac --> line_out */
-
-	{"LINE_IN", NULL, "VAG_POWER"},
  	{"Headphone Mux", "LINE_IN", "LINE_IN"},/* line_in --> hp_mux */
-	{"HP", NULL, "Headphone Mux"},		/* hp_mux --> hp */
-
-	{"LINE_OUT", NULL, "LO"},
-	{"HP_OUT", NULL, "HP"},
  };

  /* custom function to fetch info of PCM playback volume */
@@ -1100,7 +1039,13 @@ static int sgtl5000_set_power_regs(struct 
snd_soc_codec *codec)
  	ana_pwr = snd_soc_read(codec, SGTL5000_CHIP_ANA_POWER);
  	ana_pwr |= SGTL5000_DAC_STEREO |
  			SGTL5000_ADC_STEREO |
-			SGTL5000_REFTOP_POWERUP;
+			SGTL5000_VAG_POWERUP |
+			SGTL5000_REFTOP_POWERUP |
+			SGTL5000_DAC_POWERUP |
+			SGTL5000_CAPLESS_HP_POWERUP |
+			SGTL5000_ADC_POWERUP |
+			SGTL5000_LINE_OUT_POWERUP;
+
  	lreg_ctrl = snd_soc_read(codec, SGTL5000_CHIP_LINREG_CTRL);

  	if (vddio < 3100 && vdda < 3100) {
@@ -1330,7 +1275,10 @@ static int sgtl5000_probe(struct snd_soc_codec 
*codec)
  	snd_soc_write(codec, SGTL5000_CHIP_SSS_CTRL,
  			SGTL5000_DAC_SEL_I2S_IN << SGTL5000_DAC_SEL_SHIFT);
  	snd_soc_write(codec, SGTL5000_CHIP_DIG_POWER,
-			SGTL5000_ADC_EN | SGTL5000_DAC_EN);
+			SGTL5000_ADC_EN |
+			SGTL5000_DAC_EN |
+			SGTL5000_I2S_OUT_POWERUP |
+			SGTL5000_I2S_IN_POWERUP);

  	/* enable dac volume ramp by default */
  	snd_soc_write(codec, SGTL5000_CHIP_ADCDAC_CTRL,


Well, I don't like this brute-force approach and that's why I'm looking 
for a more intelligent one.

Kind regards,
Nikolay

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Fabio,

One more thing - just checked one of the latest mainline kernels 
(3.17.7) and understood why your patch worked - the SMALL_POP definition 
is really broken there, as you suggested. But on the 3.10.17-1.0.0ga 
version the definition was OK.

Kind regards,
Nikolay

Re: Audio glitch with SGTL5000

[Fabio Estevam]

Hi Nikolay,

On Tue, Jan 20, 2015 at 10:34 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:

> I tried to reproduce the issue also with the integrated headphone amp,
> just to find out that my board design has an issue (oops!) - the
> headphones' ground is connected to the power supply ground instead of
> the virtual ground, so I can't test the VAG ramp fix this way. So I can
> only speculate that you tested your fix on a properly wired headphone
> output, and that's where it worked OK.

I tested on headphone output on a mx28evk.

Here is a better link to the patch:
https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/patch/sound/soc/codecs/sgtl5000.c?id=c251ea7bd7a04f1f2575467e0de76e803cf59149

The previous one only showed the change to sgtl5000.c.

Does the problem also happens on 3.19-rc5?

Regards,

Fabio Estevam

Re: Audio glitch with SGTL5000

[Fabio Estevam]

On Tue, Jan 20, 2015 at 10:38 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Hi Fabio,
>
> One more thing - just checked one of the latest mainline kernels (3.17.7)
> and understood why your patch worked - the SMALL_POP definition is really
> broken there, as you suggested. But on the 3.10.17-1.0.0ga version the
> definition was OK.

I see it wrong at
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/sound/soc/codecs/sgtl5000.h?h=imx_3.10.17_1.0.0_ga

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Fabio,

On 01/21/2015 02:50 AM, Fabio Estevam wrote:
> Hi Nikolay,
>
> On Tue, Jan 20, 2015 at 10:34 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>
>> I tried to reproduce the issue also with the integrated headphone amp,
>> just to find out that my board design has an issue (oops!) - the
>> headphones' ground is connected to the power supply ground instead of
>> the virtual ground, so I can't test the VAG ramp fix this way. So I can
>> only speculate that you tested your fix on a properly wired headphone
>> output, and that's where it worked OK.
>
> I tested on headphone output on a mx28evk.
>
> Here is a better link to the patch:
> https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/patch/sound/soc/codecs/sgtl5000.c?id=c251ea7bd7a04f1f2575467e0de76e803cf59149
>
> The previous one only showed the change to sgtl5000.c.

Thanks. But now I don't understand the logic of this patch. Here's the
prototype of the helper function:

int snd_soc_update_bits(struct snd_soc_codec *codec, unsigned int reg, 
unsigned int mask, unsigned int value);

3rd argument is a mask, and you're passing there SGTL5000_SMALL_POP, 
which is now 0.

> Does the problem also happens on 3.19-rc5?

Can't use mainline for this specific project, as I need VPU support.

Kind regards,
Nikolay

Re: Audio glitch with SGTL5000

[Fabio Estevam]

On Wed, Jan 21, 2015 at 12:30 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Hi Fabio,
>
>
> On 01/21/2015 02:50 AM, Fabio Estevam wrote:
>>
>> Hi Nikolay,
>>
>> On Tue, Jan 20, 2015 at 10:34 PM, Nikolay Dimitrov <picmaster@mail.bg>
>> wrote:
>>
>>> I tried to reproduce the issue also with the integrated headphone amp,
>>> just to find out that my board design has an issue (oops!) - the
>>> headphones' ground is connected to the power supply ground instead of
>>> the virtual ground, so I can't test the VAG ramp fix this way. So I can
>>> only speculate that you tested your fix on a properly wired headphone
>>> output, and that's where it worked OK.
>>
>>
>> I tested on headphone output on a mx28evk.
>>
>> Here is a better link to the patch:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/patch/sound/soc/codecs/sgtl5000.c?id=c251ea7bd7a04f1f2575467e0de76e803cf59149
>>
>> The previous one only showed the change to sgtl5000.c.
>
>
> Thanks. But now I don't understand the logic of this patch. Here's the
> prototype of the helper function:
>
> int snd_soc_update_bits(struct snd_soc_codec *codec, unsigned int reg,
> unsigned int mask, unsigned int value);
>
> 3rd argument is a mask, and you're passing there SGTL5000_SMALL_POP, which
> is now 0.

Yes, you are right. It seems I cleared the bit instead of setting it.
I will retest on my boards.

>
>> Does the problem also happens on 3.19-rc5?
>
>
> Can't use mainline for this specific project, as I need VPU support.

Understood, but for debugging this sgtl5000 issue it would be easier
to use mainline and start a thread at alsa-devel.

Regards,

Fabio Estevam

Re: Audio glitch with SGTL5000

[Fabio Estevam]

On Wed, Jan 21, 2015 at 12:56 AM, Fabio Estevam <festevam@gmail.com> wrote:

> Yes, you are right. It seems I cleared the bit instead of setting it.
> I will retest on my boards.

This is interesting: just tested on a imx53-qsb and with my patch
applied, which clears SMALL_POP I don't hear the loud click after the
playback. With SMALL_POP set I do hear the click.

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Fabio,

On 01/21/2015 04:59 AM, Fabio Estevam wrote:
> On Wed, Jan 21, 2015 at 12:56 AM, Fabio Estevam <festevam@gmail.com> wrote:
>
>> Yes, you are right. It seems I cleared the bit instead of setting it.
>> I will retest on my boards.
>
> This is interesting: just tested on a imx53-qsb and with my patch
> applied, which clears SMALL_POP I don't hear the loud click after the
> playback. With SMALL_POP set I do hear the click.

Hehe, I'm not sure that you cleared the bit actually :). I think that
with mask 0 you're not writing to the I2C reg at all - you can check
the return value of snd_soc_update_bits(), should be 0 (no error, no
value changed). But would be great if you can also monitor the I2C bus
traffic to confirm whether you really write or not to this register.

Can you try to change only the last argument and hear whether it makes
a difference, like this:

snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, 1, 1);
snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, 1, 0);

Regards,
Nikolay

PS: Really sorry for the delayed response, but my inet connectivity was 
limited for a while.

Re: Audio glitch with SGTL5000

[Fabio Estevam]

Hi Nikolay,

On Wed, Jan 21, 2015 at 9:55 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:

> Hehe, I'm not sure that you cleared the bit actually :). I think that
> with mask 0 you're not writing to the I2C reg at all - you can check
> the return value of snd_soc_update_bits(), should be 0 (no error, no
> value changed). But would be great if you can also monitor the I2C bus
> traffic to confirm whether you really write or not to this register.
>
> Can you try to change only the last argument and hear whether it makes
> a difference, like this:
>
> snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, 1, 1);
> snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, 1, 0);

My tests show the following:

- With SMALL_POP 0 (no click)
- With SMALL_POP 1 (click)

Yes, this sounds strange. With my patch applied we end up with
SMALL_POP 0 (default value) and I don't hear the click on mx28evk nor
mx53qsb.

Regards,

Fabio Estevam

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Fabio,

On 01/22/2015 02:00 AM, Fabio Estevam wrote:
> Hi Nikolay,
>
> On Wed, Jan 21, 2015 at 9:55 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>
>> Hehe, I'm not sure that you cleared the bit actually :). I think that
>> with mask 0 you're not writing to the I2C reg at all - you can check
>> the return value of snd_soc_update_bits(), should be 0 (no error, no
>> value changed). But would be great if you can also monitor the I2C bus
>> traffic to confirm whether you really write or not to this register.
>>
>> Can you try to change only the last argument and hear whether it makes
>> a difference, like this:
>>
>> snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, 1, 1);
>> snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, 1, 0);
>
> My tests show the following:
>
> - With SMALL_POP 0 (no click)
> - With SMALL_POP 1 (click)
>
> Yes, this sounds strange. With my patch applied we end up with
> SMALL_POP 0 (default value) and I don't hear the click on mx28evk nor
> mx53qsb.

Well, it's possible that there's a mistake in the datasheet. If you have 
access to some engineers who worked on the audio codec, could be a good 
idea to check with them about this SMALL_POP bit.

So, it looks like I'll have to stick with my ugly fix for a while. I'll 
share with the ML if I find a solution for my issue.

Kind regards,
Nikolay

Re: Audio glitch with SGTL5000

[Gary Thomas]

On 2015-01-21 17:00, Fabio Estevam wrote:
> Hi Nikolay,
>
> On Wed, Jan 21, 2015 at 9:55 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>
>> Hehe, I'm not sure that you cleared the bit actually :). I think that
>> with mask 0 you're not writing to the I2C reg at all - you can check
>> the return value of snd_soc_update_bits(), should be 0 (no error, no
>> value changed). But would be great if you can also monitor the I2C bus
>> traffic to confirm whether you really write or not to this register.
>>
>> Can you try to change only the last argument and hear whether it makes
>> a difference, like this:
>>
>> snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, 1, 1);
>> snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, 1, 0);
>
> My tests show the following:
>
> - With SMALL_POP 0 (no click)
> - With SMALL_POP 1 (click)
>
> Yes, this sounds strange. With my patch applied we end up with
> SMALL_POP 0 (default value) and I don't hear the click on mx28evk nor
> mx53qsb.

Are you using headphone or line-out?

My i.MX6 boards all suffer from this annoying pop - it would be great
to get to the bottom of this.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Gary,

On 01/22/2015 03:24 PM, Gary Thomas wrote:
> Are you using headphone or line-out?
>
> My i.MX6 boards all suffer from this annoying pop - it would be great
> to get to the bottom of this.

Before applying my ugly fix, I can hear the glitch on both outputs, but 
need to warn you that my headphones test is flawed, as the SGTL5000 
codec on my board is improperly connected to the headphones (audio 
output is only 2-wire DC-decoupled instead of using 3-wire cap-less 
output with virtual ground).

Are you looking for a fix for line-out, headphones, both? Also, which 
kernel are you using?

Regards,
Nikolay

Re: Audio glitch with SGTL5000

[Gary Thomas]

On 2015-01-22 11:32, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 01/22/2015 03:24 PM, Gary Thomas wrote:
>> Are you using headphone or line-out?
>>
>> My i.MX6 boards all suffer from this annoying pop - it would be great
>> to get to the bottom of this.
>
> Before applying my ugly fix, I can hear the glitch on both outputs, but need to warn you that my headphones test is flawed, as the SGTL5000 codec on my board is improperly
> connected to the headphones (audio output is only 2-wire DC-decoupled instead of using 3-wire cap-less output with virtual ground).
>
> Are you looking for a fix for line-out, headphones, both? Also, which kernel are you using?

Currently, only headphones.

I'm using linux-boundary/3.10.31

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Audio glitch with SGTL5000

[Eric Nelson]

On 01/22/2015 11:35 AM, Gary Thomas wrote:
> On 2015-01-22 11:32, Nikolay Dimitrov wrote:
>> Hi Gary,
>>
>> On 01/22/2015 03:24 PM, Gary Thomas wrote:
>>> Are you using headphone or line-out?
>>>
>>> My i.MX6 boards all suffer from this annoying pop - it would be great
>>> to get to the bottom of this.
>>
>> Before applying my ugly fix, I can hear the glitch on both outputs,
>> but need to warn you that my headphones test is flawed, as the
>> SGTL5000 codec on my board is improperly
>> connected to the headphones (audio output is only 2-wire DC-decoupled
>> instead of using 3-wire cap-less output with virtual ground).
>>
>> Are you looking for a fix for line-out, headphones, both? Also, which
>> kernel are you using?
> 
> Currently, only headphones.
> 
> I'm using linux-boundary/3.10.31
> 

Which has the SMALL_POP fix applied:
	https://github.com/boundarydevices/linux-imx6/commit/983ce7a

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Eric,

On 01/22/2015 09:05 PM, Eric Nelson wrote:
> On 01/22/2015 11:35 AM, Gary Thomas wrote:
>> On 2015-01-22 11:32, Nikolay Dimitrov wrote:
>>> Hi Gary,
>>>
>>> On 01/22/2015 03:24 PM, Gary Thomas wrote:
>>>> Are you using headphone or line-out?
>>>>
>>>> My i.MX6 boards all suffer from this annoying pop - it would be great
>>>> to get to the bottom of this.
>>>
>>> Before applying my ugly fix, I can hear the glitch on both outputs,
>>> but need to warn you that my headphones test is flawed, as the
>>> SGTL5000 codec on my board is improperly
>>> connected to the headphones (audio output is only 2-wire DC-decoupled
>>> instead of using 3-wire cap-less output with virtual ground).
>>>
>>> Are you looking for a fix for line-out, headphones, both? Also, which
>>> kernel are you using?
>>
>> Currently, only headphones.
>>
>> I'm using linux-boundary/3.10.31
>>
>
> Which has the SMALL_POP fix applied:
> 	https://github.com/boundarydevices/linux-imx6/commit/983ce7a

As we discussed with Fabio, when you define SGTL5000_SMALL_POP as 0, the 
following call...

snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, SGTL5000_SMALL_POP, 1);

...doesn't actually write to the I2C register, and leaves the default 
behavior, which is SMALL_POP = 1. And as Fabio noted, the audible 
behavior of this SMALL_POP bit is inverted as compared to the 
documentation, so SMALL_POP 0 should have the click audible, and 
SMALL_POP 1 should make it inaudible.

For me personally the patch is misleading written this way - it looks 
like it's writing to the register, but neither this write is actually 
happening (you can sniff the I2C bus if you wish), and also this patch 
hides the issue with improperly documented SMALL_POP bit.

Kind regards,
Nikolay

Re: Audio glitch with SGTL5000

[Gary Thomas]

On 2015-01-22 12:05, Eric Nelson wrote:
> On 01/22/2015 11:35 AM, Gary Thomas wrote:
>> On 2015-01-22 11:32, Nikolay Dimitrov wrote:
>>> Hi Gary,
>>>
>>> On 01/22/2015 03:24 PM, Gary Thomas wrote:
>>>> Are you using headphone or line-out?
>>>>
>>>> My i.MX6 boards all suffer from this annoying pop - it would be great
>>>> to get to the bottom of this.
>>>
>>> Before applying my ugly fix, I can hear the glitch on both outputs,
>>> but need to warn you that my headphones test is flawed, as the
>>> SGTL5000 codec on my board is improperly
>>> connected to the headphones (audio output is only 2-wire DC-decoupled
>>> instead of using 3-wire cap-less output with virtual ground).
>>>
>>> Are you looking for a fix for line-out, headphones, both? Also, which
>>> kernel are you using?
>>
>> Currently, only headphones.
>>
>> I'm using linux-boundary/3.10.31
>>
>
> Which has the SMALL_POP fix applied:
> 	https://github.com/boundarydevices/linux-imx6/commit/983ce7a

Yes, but I still get them, so it's not 100% correct :-(

Also, Eric, is there anything magic about sound on the SabreLite?  I know
I've had it working in the past, but today it's totally silent.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Audio glitch with SGTL5000

[Fabio Estevam]

On Thu, Jan 22, 2015 at 5:20 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:

> As we discussed with Fabio, when you define SGTL5000_SMALL_POP as 0, the
> following call...
>
> snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, SGTL5000_SMALL_POP, 1);
>
> ...doesn't actually write to the I2C register, and leaves the default
> behavior, which is SMALL_POP = 1. And as Fabio noted, the audible behavior
> of this SMALL_POP bit is inverted as compared to the documentation, so
> SMALL_POP 0 should have the click audible, and SMALL_POP 1 should make it
> inaudible.
>
> For me personally the patch is misleading written this way - it looks like
> it's writing to the register, but neither this write is actually happening
> (you can sniff the I2C bus if you wish), and also this patch hides the issue
> with improperly documented SMALL_POP bit.

There was no intention to hide anything in that patch. The end result
(SMALL_POP cleared) silenced the click on my two boards, but I agree
that I would need to fix it properly as you pointed out.

This is off-topic here on a Yocto list though, so I suggest we move
such discussion to the alsa-devel list which is the appropriate place.

Re: Audio glitch with SGTL5000

[Gary Thomas]

On 2015-01-22 12:21, Gary Thomas wrote:
> On 2015-01-22 12:05, Eric Nelson wrote:
>> On 01/22/2015 11:35 AM, Gary Thomas wrote:
>>> On 2015-01-22 11:32, Nikolay Dimitrov wrote:
>>>> Hi Gary,
>>>>
>>>> On 01/22/2015 03:24 PM, Gary Thomas wrote:
>>>>> Are you using headphone or line-out?
>>>>>
>>>>> My i.MX6 boards all suffer from this annoying pop - it would be great
>>>>> to get to the bottom of this.
>>>>
>>>> Before applying my ugly fix, I can hear the glitch on both outputs,
>>>> but need to warn you that my headphones test is flawed, as the
>>>> SGTL5000 codec on my board is improperly
>>>> connected to the headphones (audio output is only 2-wire DC-decoupled
>>>> instead of using 3-wire cap-less output with virtual ground).
>>>>
>>>> Are you looking for a fix for line-out, headphones, both? Also, which
>>>> kernel are you using?
>>>
>>> Currently, only headphones.
>>>
>>> I'm using linux-boundary/3.10.31
>>>
>>
>> Which has the SMALL_POP fix applied:
>>     https://github.com/boundarydevices/linux-imx6/commit/983ce7a
>
> Yes, but I still get them, so it's not 100% correct :-(
>
> Also, Eric, is there anything magic about sound on the SabreLite?  I know
> I've had it working in the past, but today it's totally silent.
>

Nevermind - I rebuilt my image today and the sound is back.

That said, it brings up an interesting issue.  I'm running the
same kernel on two i.MX6 boards - the SabreLite and one of my
company's internal design which is _almost_ identical.  The SGTL5000
setup is identical.  My SabreLite does not have a pop, but my other
board does.  I wonder what could be the difference?  They do have
slightly different i.MX6 silicon (not sure about the SGTL5000).
SabreLite = i.MX6Q rev 1.0,  My board = i.MX6Q rev 1.2

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Audio glitch with SGTL5000

[Fabio Estevam]

On Thu, Jan 22, 2015 at 5:46 PM, Gary Thomas <gary@mlbassoc.com> wrote:

> Nevermind - I rebuilt my image today and the sound is back.
>
> That said, it brings up an interesting issue.  I'm running the
> same kernel on two i.MX6 boards - the SabreLite and one of my
> company's internal design which is _almost_ identical.  The SGTL5000
> setup is identical.  My SabreLite does not have a pop, but my other
> board does.  I wonder what could be the difference?  They do have
> slightly different i.MX6 silicon (not sure about the SGTL5000).
> SabreLite = i.MX6Q rev 1.0,  My board = i.MX6Q rev 1.2

Do you get the pop on your board if you use the workaround patch that
Nikolay is using?

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Fabio,

On 01/22/2015 09:33 PM, Fabio Estevam wrote:
> On Thu, Jan 22, 2015 at 5:20 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>
>> As we discussed with Fabio, when you define SGTL5000_SMALL_POP as 0, the
>> following call...
>>
>> snd_soc_update_bits(codec, SGTL5000_CHIP_REF_CTRL, SGTL5000_SMALL_POP, 1);
>>
>> ...doesn't actually write to the I2C register, and leaves the default
>> behavior, which is SMALL_POP = 1. And as Fabio noted, the audible behavior
>> of this SMALL_POP bit is inverted as compared to the documentation, so
>> SMALL_POP 0 should have the click audible, and SMALL_POP 1 should make it
>> inaudible.
>>
>> For me personally the patch is misleading written this way - it looks like
>> it's writing to the register, but neither this write is actually happening
>> (you can sniff the I2C bus if you wish), and also this patch hides the issue
>> with improperly documented SMALL_POP bit.
>
> There was no intention to hide anything in that patch.

Sorry, I didn't mean that at all.

> This is off-topic here on a Yocto list though, so I suggest we move
> such discussion to the alsa-devel list which is the appropriate place.

OK, understood.

Regards,
Nikolay

Re: Audio glitch with SGTL5000

[Fabio Estevam]

Hi Nikolay,

On Thu, Jan 22, 2015 at 5:49 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:

> Sorry, I didn't mean that at all.

No problem. I am glad you spotted the problem with the SMALL_POP bit.
I will also check if there is an error in the SMALL_POP bit definition
in the manual.

>> This is off-topic here on a Yocto list though, so I suggest we move
>> such discussion to the alsa-devel list which is the appropriate place.
>
>
> OK, understood.

Maybe sending your workaround patch as a RFC could be a start for the
discussion there.

Thanks,

Fabio Estevam

Re: Audio glitch with SGTL5000

[Gary Thomas]

On 2015-01-22 12:49, Fabio Estevam wrote:
> On Thu, Jan 22, 2015 at 5:46 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>
>> Nevermind - I rebuilt my image today and the sound is back.
>>
>> That said, it brings up an interesting issue.  I'm running the
>> same kernel on two i.MX6 boards - the SabreLite and one of my
>> company's internal design which is _almost_ identical.  The SGTL5000
>> setup is identical.  My SabreLite does not have a pop, but my other
>> board does.  I wonder what could be the difference?  They do have
>> slightly different i.MX6 silicon (not sure about the SGTL5000).
>> SabreLite = i.MX6Q rev 1.0,  My board = i.MX6Q rev 1.2
>
> Do you get the pop on your board if you use the workaround patch that
> Nikolay is using?
>

I haven't seen it - was it sent to this list?

I'd be happy to try it as the behaviour on this one board is
very consistent and pronounced.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Gary,

On 01/22/2015 10:16 PM, Gary Thomas wrote:
> On 2015-01-22 12:49, Fabio Estevam wrote:
>> On Thu, Jan 22, 2015 at 5:46 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>
>>> Nevermind - I rebuilt my image today and the sound is back.
>>>
>>> That said, it brings up an interesting issue.  I'm running the
>>> same kernel on two i.MX6 boards - the SabreLite and one of my
>>> company's internal design which is _almost_ identical.  The SGTL5000
>>> setup is identical.  My SabreLite does not have a pop, but my other
>>> board does.  I wonder what could be the difference?  They do have
>>> slightly different i.MX6 silicon (not sure about the SGTL5000).
>>> SabreLite = i.MX6Q rev 1.0,  My board = i.MX6Q rev 1.2
>>
>> Do you get the pop on your board if you use the workaround patch that
>> Nikolay is using?
>>
>
> I haven't seen it - was it sent to this list?

Yep, check my message sent on 21.Jan, 02:34AM to this same thread.

Regards,
Nikolay

Re: Audio glitch with SGTL5000

[Gary Thomas]

On 2015-01-22 13:28, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 01/22/2015 10:16 PM, Gary Thomas wrote:
>> On 2015-01-22 12:49, Fabio Estevam wrote:
>>> On Thu, Jan 22, 2015 at 5:46 PM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>
>>>> Nevermind - I rebuilt my image today and the sound is back.
>>>>
>>>> That said, it brings up an interesting issue.  I'm running the
>>>> same kernel on two i.MX6 boards - the SabreLite and one of my
>>>> company's internal design which is _almost_ identical.  The SGTL5000
>>>> setup is identical.  My SabreLite does not have a pop, but my other
>>>> board does.  I wonder what could be the difference?  They do have
>>>> slightly different i.MX6 silicon (not sure about the SGTL5000).
>>>> SabreLite = i.MX6Q rev 1.0,  My board = i.MX6Q rev 1.2
>>>
>>> Do you get the pop on your board if you use the workaround patch that
>>> Nikolay is using?
>>>
>>
>> I haven't seen it - was it sent to this list?
>
> Yep, check my message sent on 21.Jan, 02:34AM to this same thread.
>
> Regards,
> Nikolay


Sorry, it won't apply (malformed).  Could you send it as an attachment?
To me privately if you wish.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Audio glitch with SGTL5000

[Eric Nelson]

Hi all,

On 01/22/2015 12:52 PM, Fabio Estevam wrote:
> Hi Nikolay,
> 
> On Thu, Jan 22, 2015 at 5:49 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> 
>> Sorry, I didn't mean that at all.
> 
> No problem. I am glad you spotted the problem with the SMALL_POP bit.
> I will also check if there is an error in the SMALL_POP bit definition
> in the manual.
> 
>>> This is off-topic here on a Yocto list though, so I suggest we move
>>> such discussion to the alsa-devel list which is the appropriate place.
>>
>>
>> OK, understood.
> 
> Maybe sending your workaround patch as a RFC could be a start for the
> discussion there.
> 

I think I found the problem, and it was fixed in main-line in this
commit by Marek:

	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/sound/soc/codecs/sgtl5000.c?id=dd4d2d6dfb49e8916064f2cb07f0ad7b32a82fb7

I pushed a 3.10.17 version of it to our Github tree:
	https://github.com/boundarydevices/linux-imx6/commit/ff27114

Re: Audio glitch with SGTL5000

[Otavio Salvador]

On Sat, Feb 28, 2015 at 3:53 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Hi all,
>
> On 01/22/2015 12:52 PM, Fabio Estevam wrote:
>> Hi Nikolay,
>>
>> On Thu, Jan 22, 2015 at 5:49 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>>
>>> Sorry, I didn't mean that at all.
>>
>> No problem. I am glad you spotted the problem with the SMALL_POP bit.
>> I will also check if there is an error in the SMALL_POP bit definition
>> in the manual.
>>
>>>> This is off-topic here on a Yocto list though, so I suggest we move
>>>> such discussion to the alsa-devel list which is the appropriate place.
>>>
>>>
>>> OK, understood.
>>
>> Maybe sending your workaround patch as a RFC could be a start for the
>> discussion there.
>>
>
> I think I found the problem, and it was fixed in main-line in this
> commit by Marek:
>
>         https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/sound/soc/codecs/sgtl5000.c?id=dd4d2d6dfb49e8916064f2cb07f0ad7b32a82fb7
>
> I pushed a 3.10.17 version of it to our Github tree:
>         https://github.com/boundarydevices/linux-imx6/commit/ff27114

Very same fix seems applied in 3.10.53 as well.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Audio glitch with SGTL5000

[Gary Thomas]

On 2015-02-28 11:53, Eric Nelson wrote:
> Hi all,
>
> On 01/22/2015 12:52 PM, Fabio Estevam wrote:
>> Hi Nikolay,
>>
>> On Thu, Jan 22, 2015 at 5:49 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>>
>>> Sorry, I didn't mean that at all.
>>
>> No problem. I am glad you spotted the problem with the SMALL_POP bit.
>> I will also check if there is an error in the SMALL_POP bit definition
>> in the manual.
>>
>>>> This is off-topic here on a Yocto list though, so I suggest we move
>>>> such discussion to the alsa-devel list which is the appropriate place.
>>>
>>>
>>> OK, understood.
>>
>> Maybe sending your workaround patch as a RFC could be a start for the
>> discussion there.
>>
>
> I think I found the problem, and it was fixed in main-line in this
> commit by Marek:
>
> 	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/sound/soc/codecs/sgtl5000.c?id=dd4d2d6dfb49e8916064f2cb07f0ad7b32a82fb7
>
> I pushed a 3.10.17 version of it to our Github tree:
> 	https://github.com/boundarydevices/linux-imx6/commit/ff27114

I still get the large pops on my board with this change included.
My kernel is currently based on the linux-imx:3.10.53_1.1.0_ga
I'd love to check it on my SabreLite, but I need that running
3.10.53 as well, so it will have to wait.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Eric,

On 02/28/2015 08:53 PM, Eric Nelson wrote:
> Hi all,
>
> On 01/22/2015 12:52 PM, Fabio Estevam wrote:
>> Hi Nikolay,
>>
>> On Thu, Jan 22, 2015 at 5:49 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>>
>>> Sorry, I didn't mean that at all.
>>
>> No problem. I am glad you spotted the problem with the SMALL_POP bit.
>> I will also check if there is an error in the SMALL_POP bit definition
>> in the manual.
>>
>>>> This is off-topic here on a Yocto list though, so I suggest we move
>>>> such discussion to the alsa-devel list which is the appropriate place.
>>>
>>>
>>> OK, understood.
>>
>> Maybe sending your workaround patch as a RFC could be a start for the
>> discussion there.
>>
>
> I think I found the problem, and it was fixed in main-line in this
> commit by Marek:
>
> 	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/sound/soc/codecs/sgtl5000.c?id=dd4d2d6dfb49e8916064f2cb07f0ad7b32a82fb7
>
> I pushed a 3.10.17 version of it to our Github tree:
> 	https://github.com/boundarydevices/linux-imx6/commit/ff27114

Can you confirm tha this fix solves the pop on line-out? Just want to
be sure, as most of the related patch-work fixes mostly the headphones-
related pop.

Regards,
Nikolay

Re: Audio glitch with SGTL5000

[Eric Nelson]

Hi Nikolay,

On 03/01/2015 02:29 PM, Nikolay Dimitrov wrote:
> Hi Eric,
> 
> On 02/28/2015 08:53 PM, Eric Nelson wrote:
>> Hi all,
>>
>> On 01/22/2015 12:52 PM, Fabio Estevam wrote:
>>> Hi Nikolay,
>>>
>>> On Thu, Jan 22, 2015 at 5:49 PM, Nikolay Dimitrov <picmaster@mail.bg>
>>> wrote:
>>>
>>>> Sorry, I didn't mean that at all.
>>>
>>> No problem. I am glad you spotted the problem with the SMALL_POP bit.
>>> I will also check if there is an error in the SMALL_POP bit definition
>>> in the manual.
>>>
>>>>> This is off-topic here on a Yocto list though, so I suggest we move
>>>>> such discussion to the alsa-devel list which is the appropriate place.
>>>>
>>>>
>>>> OK, understood.
>>>
>>> Maybe sending your workaround patch as a RFC could be a start for the
>>> discussion there.
>>>
>>
>> I think I found the problem, and it was fixed in main-line in this
>> commit by Marek:
>>
>>     https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/sound/soc/codecs/sgtl5000.c?id=dd4d2d6dfb49e8916064f2cb07f0ad7b32a82fb7
>>
>>
>> I pushed a 3.10.17 version of it to our Github tree:
>>     https://github.com/boundarydevices/linux-imx6/commit/ff27114
> 
> Can you confirm tha this fix solves the pop on line-out? Just want to
> be sure, as most of the related patch-work fixes mostly the headphones-
> related pop.
> 

Our boards don't support line-out, so I can't confirm that, though
it should (VAG applies to both HP and LO).

Also, Gary reported earlier that the patch doesn't fix the
pop on 3.10.53.

I presume that's because we also have Fabio's SMALL_POP fix applied on
our 3.10.17 tree.

Regards,


Eric

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

Hi guys,

Finally the circumstances (e.g. customer priorities :D) allowed me to
port the audio glitch work-around to 3.10.53. Feel welcome to take a
look at it and give it a try, and I'll be more than happy if it fixes
the issue for you.

Note: the patch is just RFC to illustrate the issue and one possible
solution.

Kind regards,
Nikolay

[-- Attachment #2: sound-sgtl5000-Fix-audio-glitch-after-audio-stream-i.patch --]
[-- Type: text/x-patch, Size: 4705 bytes --]

From f3f5259c959b561e53feef72524d587fccac1edd Mon Sep 17 00:00:00 2001
From: Nikolay Dimitrov <picmaster@mail.bg>
Date: Wed, 24 Jun 2015 20:11:28 +0300
Subject: [PATCH] sound: sgtl5000: Fix audio glitch after audio stream is
 stopped

When an audio stream is stopped, ALSA DAPM subsystem shutdowns the
audio codec after several seconds of inactivity to conserve power. This
shutdown sequence causes an audible glitch on SGTL5000 codec's line-out.
This patch disables the DAPM for SGTL5000 and keeps the codec's internal
modules powered-on all the time to prevent the audio glitch.

Upstream-status: Inappropriate [design]
 - ALSA DAPM is mandatory by design, and the patch violates this
   requirement

Signed-off-by: Nikolay Dimitrov <picmaster@mail.bg>
---
 sound/soc/codecs/sgtl5000.c |   68 +++++++------------------------------------
 1 file changed, 10 insertions(+), 58 deletions(-)

diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c
index ddf66d9..3750ec8 100644
--- a/sound/soc/codecs/sgtl5000.c
+++ b/sound/soc/codecs/sgtl5000.c
@@ -142,32 +142,6 @@ static int mic_bias_event(struct snd_soc_dapm_widget *w,
 	return 0;
 }
 
-/*
- * As manual described, ADC/DAC only works when VAG powerup,
- * So enabled VAG before ADC/DAC up.
- * In power down case, we need wait 400ms when vag fully ramped down.
- */
-static int power_vag_event(struct snd_soc_dapm_widget *w,
-	struct snd_kcontrol *kcontrol, int event)
-{
-	switch (event) {
-	case SND_SOC_DAPM_POST_PMU:
-		snd_soc_update_bits(w->codec, SGTL5000_CHIP_ANA_POWER,
-			SGTL5000_VAG_POWERUP, SGTL5000_VAG_POWERUP);
-		break;
-
-	case SND_SOC_DAPM_PRE_PMD:
-		snd_soc_update_bits(w->codec, SGTL5000_CHIP_ANA_POWER,
-			SGTL5000_VAG_POWERUP, 0);
-		msleep(400);
-		break;
-	default:
-		break;
-	}
-
-	return 0;
-}
-
 /* input sources for ADC */
 static const char *adc_mux_text[] = {
 	"MIC_IN", "LINE_IN"
@@ -201,27 +175,8 @@ static const struct snd_soc_dapm_widget sgtl5000_dapm_widgets[] = {
 			    mic_bias_event,
 			    SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD),
 
-	SND_SOC_DAPM_PGA("HP", SGTL5000_CHIP_ANA_POWER, 4, 0, NULL, 0),
-	SND_SOC_DAPM_PGA("LO", SGTL5000_CHIP_ANA_POWER, 0, 0, NULL, 0),
-
 	SND_SOC_DAPM_MUX("Capture Mux", SND_SOC_NOPM, 0, 0, &adc_mux),
 	SND_SOC_DAPM_MUX("Headphone Mux", SND_SOC_NOPM, 0, 0, &dac_mux),
-
-	/* aif for i2s input */
-	SND_SOC_DAPM_AIF_IN("AIFIN", "Playback",
-				0, SGTL5000_CHIP_DIG_POWER,
-				0, 0),
-
-	/* aif for i2s output */
-	SND_SOC_DAPM_AIF_OUT("AIFOUT", "Capture",
-				0, SGTL5000_CHIP_DIG_POWER,
-				1, 0),
-
-	SND_SOC_DAPM_ADC("ADC", "Capture", SGTL5000_CHIP_ANA_POWER, 1, 0),
-	SND_SOC_DAPM_DAC("DAC", "Playback", SGTL5000_CHIP_ANA_POWER, 3, 0),
-
-	SND_SOC_DAPM_PRE("VAG_POWER_PRE", power_vag_event),
-	SND_SOC_DAPM_POST("VAG_POWER_POST", power_vag_event),
 };
 
 /* routes for sgtl5000 */
@@ -229,18 +184,7 @@ static const struct snd_soc_dapm_route sgtl5000_dapm_routes[] = {
 	{"Capture Mux", "LINE_IN", "LINE_IN"},	/* line_in --> adc_mux */
 	{"Capture Mux", "MIC_IN", "MIC_IN"},	/* mic_in --> adc_mux */
 
-	{"ADC", NULL, "Capture Mux"},		/* adc_mux --> adc */
-	{"AIFOUT", NULL, "ADC"},		/* adc --> i2s_out */
-
-	{"DAC", NULL, "AIFIN"},			/* i2s-->dac,skip audio mux */
-	{"Headphone Mux", "DAC", "DAC"},	/* dac --> hp_mux */
-	{"LO", NULL, "DAC"},			/* dac --> line_out */
-
 	{"Headphone Mux", "LINE_IN", "LINE_IN"},/* line_in --> hp_mux */
-	{"HP", NULL, "Headphone Mux"},		/* hp_mux --> hp */
-
-	{"LINE_OUT", NULL, "LO"},
-	{"HP_OUT", NULL, "HP"},
 };
 
 /* custom function to fetch info of PCM playback volume */
@@ -1096,7 +1040,12 @@ static int sgtl5000_set_power_regs(struct snd_soc_codec *codec)
 	ana_pwr = snd_soc_read(codec, SGTL5000_CHIP_ANA_POWER);
 	ana_pwr |= SGTL5000_DAC_STEREO |
 			SGTL5000_ADC_STEREO |
-			SGTL5000_REFTOP_POWERUP;
+			SGTL5000_VAG_POWERUP |
+			SGTL5000_REFTOP_POWERUP |
+			SGTL5000_DAC_POWERUP |
+			SGTL5000_CAPLESS_HP_POWERUP |
+			SGTL5000_ADC_POWERUP |
+			SGTL5000_LINE_OUT_POWERUP;
 	lreg_ctrl = snd_soc_read(codec, SGTL5000_CHIP_LINREG_CTRL);
 
 	if (vddio < 3100 && vdda < 3100) {
@@ -1326,7 +1275,10 @@ static int sgtl5000_probe(struct snd_soc_codec *codec)
 	snd_soc_write(codec, SGTL5000_CHIP_SSS_CTRL,
 			SGTL5000_DAC_SEL_I2S_IN << SGTL5000_DAC_SEL_SHIFT);
 	snd_soc_write(codec, SGTL5000_CHIP_DIG_POWER,
-			SGTL5000_ADC_EN | SGTL5000_DAC_EN);
+			SGTL5000_ADC_EN |
+			SGTL5000_DAC_EN |
+			SGTL5000_I2S_OUT_POWERUP |
+			SGTL5000_I2S_IN_POWERUP);
 
 	/* enable dac volume ramp by default */
 	snd_soc_write(codec, SGTL5000_CHIP_ADCDAC_CTRL,
-- 
1.7.10.4

Re: Audio glitch with SGTL5000

[Otavio Salvador]

On Wed, Jun 24, 2015 at 3:12 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Finally the circumstances (e.g. customer priorities :D) allowed me to
> port the audio glitch work-around to 3.10.53. Feel welcome to take a
> look at it and give it a try, and I'll be more than happy if it fixes
> the issue for you.

By any chance, could you check if 3.14.28 GA is affected? Is Linux
mainline affected?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Audio glitch with SGTL5000

[Nikolay Dimitrov]

Hi Otavio,

On 07/03/2015 12:37 AM, Otavio Salvador wrote:
> On Wed, Jun 24, 2015 at 3:12 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> Finally the circumstances (e.g. customer priorities :D) allowed me to
>> port the audio glitch work-around to 3.10.53. Feel welcome to take a
>> look at it and give it a try, and I'll be more than happy if it fixes
>> the issue for you.
>
> By any chance, could you check if 3.14.28 GA is affected? Is Linux
> mainline affected?

I haven't tested neither 3.14.28 nor mainline as I haven't added
support for this specific board there. Once I have some spare hours to
do this, I'll share the results.

Regards,
Nikolay