Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756909AbdCUJPx (ORCPT ); Tue, 21 Mar 2017 05:15:53 -0400 Received: from rtits2.realtek.com ([211.75.126.72]:51840 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753669AbdCUJPw (ORCPT ); Tue, 21 Mar 2017 05:15:52 -0400 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.56 with qID v2L9FIBN002586, This message is accepted by code: ctloc85258 From: Bard Liao To: Kai-Heng Feng , Mark Brown CC: Liam Girdwood , Oder Chiou , "alsa-devel@alsa-project.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode Thread-Topic: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode Thread-Index: AQHSoS5G+S9N2Bimuk2IJBa89nnBeaGdT0OAgAAKeICAAJCnzf//i3KAgADI3oCAAMINoA== Date: Tue, 21 Mar 2017 09:15:18 +0000 Message-ID: References: <20170320035831.10762-1-kai.heng.feng@canonical.com> <20170320150845.7rltrhycdkk2mza4@sirena.org.uk> <20170320160622.5s2oqdyluvanjp2u@sirena.org.uk> <20170320172647.t7qacxqcgawe7xlf@sirena.org.uk> In-Reply-To: Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.85.154] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v2L9G5HZ009369 Content-Length: 1405 Lines: 33 > -----Original Message----- > From: Kai-Heng Feng [mailto:kai.heng.feng@canonical.com] > Sent: Tuesday, March 21, 2017 1:26 PM > To: Mark Brown > Cc: Liam Girdwood; Bard Liao; Oder Chiou; alsa-devel@alsa-project.org; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell > XPS 9343 I2S mode > > > >> I had the same thought originally, but printk under each case suggests > >> otherwise - _POST_PMU is triggered not right after _PRE_PMU but right > >> before _PRE_PMD. > > > > Then you've broken something else on your system, that is obviously > > completely nonsensical and would break anything that relies on having a > > _POST_PMU event. Why would we have two events that run at the same > time > > one of which is obviously misnamed? > > Hmm, that's weird though. I did the same test to rt286_spk_event() > (without applying the patch I sent), what I observed was the same: > _POST_PMU was triggered right after I stopped play sound, i.e. right > before _PRE_PMD not right after _PRE_PMU. > Although I don't think it will happen on my side, but I still ran the same test as you. The result is just as what we expected, _PRE_PMU and _POST_PMU run on powering up stage and _PRE_PMD and _POST_PMD run on powering down stage. Please check what's going on with your system. > ------Please consider the environment before printing this e-mail.