linux-kernel - Re: [PATCH v2] ASoC: rk3399_gru_sound: fix recording pop at first attempt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160924181042.7odqqbae2sixdeyx@sirena.org.uk>
Date:   Sat, 24 Sep 2016 19:10:42 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Rob Herring <robh@...nel.org>
Cc:     Xing Zheng <zhengxing@...k-chips.com>,
        linux-rockchip@...ts.infradead.org, woojoo.lee@...sung.com,
        cychiang@...gle.com, hychao@...gle.com, smbarber@...gle.com,
        heiko@...ech.de, dianders@...gle.com,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ASoC: rk3399_gru_sound: fix recording pop at first
 attempt

On Fri, Sep 23, 2016 at 04:27:37PM -0500, Rob Herring wrote:
> On Thu, Sep 22, 2016 at 09:50:06PM +0800, Xing Zheng wrote:
> > From: Wonjoon Lee <woojoo.lee@...sung.com>

> > Pop happens when mclk applied but dmic's own boot-time

> This statement doesn't make sense.

It is very clear if you're familiar with the problem domain - because a
DMIC is digital it's got an on/off state which means that when it
transitions from off and not outputting anything to outputting something
you get a sudden DC transition which manifests as a pop in the audio
output.

> > Specify dmic delay times in dt to make sure
> > clocks are ready earlier than dmic working

> I don't think this really belongs in DT. Seems like better control of 
> the init order is needed. Or why not just a fixed delay in the driver?

The changelog says this is due to the DMICs having a startup time of
their own so needing a delay after they've started.  That's going to be
a system dependent thing since it'll depend on the specific component
selected and DMICs are easily interchangable.

Download attachment "signature.asc" of type "application/pgp-signature" (456 bytes)