Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8DCBC636CC for ; Tue, 31 Jan 2023 22:19:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230189AbjAaWTf (ORCPT ); Tue, 31 Jan 2023 17:19:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230202AbjAaWT2 (ORCPT ); Tue, 31 Jan 2023 17:19:28 -0500 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 508427A9D for ; Tue, 31 Jan 2023 14:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675203566; x=1706739566; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=1k+bgDHjFw33vi2FYCvnMsD2v6XTns/PIAju5+u3Wh4=; b=R8z8SZH4GbpBKk50WqkOcLu5g6V7y4fLXr5RqJgqCW+QrrGDfqL5jli5 kCa+MLutPL7Gr8pjRn39B9E9AOeaf6H+bRc2HLmq/4U2uOk4apyczTu1R VeFUkiO4122/2h+Yl6LLmdmzLPgu+Jg4jaaCUQkwy0oVRucMnyHAUrR7M ZPAj37wrwMuyL5CTpCUrkKMua2OOzgFeYjxzUt7smlx2Auabi7W0zicif mqv4TrPfhcwzi979fICoO4vB6EtbSLB1ts3UP3nUg8coJqEkoeyGdp46U uQm5SnyQ0Qthc7UCvkQ97TFRux0lnj5XmItem//15bmjY7NRyS33kXdzM g==; X-IronPort-AV: E=McAfee;i="6500,9779,10607"; a="308318506" X-IronPort-AV: E=Sophos;i="5.97,261,1669104000"; d="scan'208";a="308318506" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2023 14:19:26 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10607"; a="788615794" X-IronPort-AV: E=Sophos;i="5.97,261,1669104000"; d="scan'208";a="788615794" Received: from ncollins-mobl.amr.corp.intel.com (HELO [10.212.85.244]) ([10.212.85.244]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2023 14:19:25 -0800 Message-ID: <12b10990-8f06-e0a3-df6a-33fa20ba2cd9@linux.intel.com> Date: Tue, 31 Jan 2023 09:52:22 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.4.2 Subject: Re: [PATCH v3 8/8] ASoC: cs42l42: Wait for debounce interval after resume Content-Language: en-US To: Richard Fitzgerald , Stefan Binding , Vinod Koul , Bard Liao , Mark Brown Cc: patches@opensource.cirrus.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org References: <20230127165111.3010960-1-sbinding@opensource.cirrus.com> <20230127165111.3010960-9-sbinding@opensource.cirrus.com> <1e5e1312-18f5-e70f-3237-c2ffc851eef7@linux.intel.com> From: Pierre-Louis Bossart In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/31/23 05:03, Richard Fitzgerald wrote: > On 30/01/2023 16:45, Pierre-Louis Bossart wrote: >> >> >> On 1/27/23 10:51, Stefan Binding wrote: >>> Since clock stop causes bus reset on Intel controllers, we need >> >> nit-pick: It's more that the Intel controller has a power optimization >> where the context is lost when stopping the clock, which requires a bus >> reset and full re-enumeration/initialization when the clock resumes. >> > > Ok, it's true that clock stop doesn't _cause_ bus reset, bus reset is > necessary when exiting clock stop. We can re-word if you want us to > describe that accurately. > > But from the codec driver's point of view, a clock stop causes a bus > reset. it's fine, we all agree here. >> The rest of the patch is fine so >> >> Reviewed-by: Pierre-Louis Bossart >> >>> to wait for the debounce interval on resume, to ensure all the >>> interrupt status registers are set correctly. >>> >>> Signed-off-by: Stefan Binding