From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 426D0E007CD; Thu, 22 Jan 2015 11:20:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [193.201.172.119 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx3.mail.bg (mx3.mail.bg [193.201.172.119]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id AF1DEE005B4 for ; Thu, 22 Jan 2015 11:20:28 -0800 (PST) Received: from [192.168.0.123] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx3.mail.bg (Postfix) with ESMTPSA id 0BB212029C5E; Thu, 22 Jan 2015 21:20:26 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1421954427; bh=73iaCTmi158Nv9Pj4hwuRsLKpTdqGIdscDILwwCDP1k=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TNC3ZOfyhSQqz9HKy9KVbNII+RzhrgoH80h2MOPSsYP66Ej5L7+lfoPjWK+yzfY8b ME7Ed8Ih0dSb4uwOYf81mnYqMWfWen0308q6NU/B78jgKtQEdyhKS1Wd2iPYSwdBnj Vkqc/aVE9KTLULBru7bhWemPB2cCJhi6zH0QlsT0= Message-ID: <54C14D7A.6070206@mail.bg> Date: Thu, 22 Jan 2015 21:20:26 +0200 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Eric Nelson , Gary Thomas , meta-freescale@yoctoproject.org References: <54BED2E8.70901@mail.bg> <54BEF411.9080503@mail.bg> <54BF0F40.6030407@mail.bg> <54C03C72.3050502@mail.bg> <54C0F9FE.6020208@mlbassoc.com> <54C14241.4090805@mail.bg> <54C1430A.6050303@mlbassoc.com> <54C149E5.6040303@boundarydevices.com> In-Reply-To: <54C149E5.6040303@boundarydevices.com> Subject: Re: Audio glitch with SGTL5000 X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 19:20:46 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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