From mboxrd@z Thu Jan 1 00:00:00 1970 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 73842C433EF for ; Wed, 23 Feb 2022 18:55:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244049AbiBWS4P (ORCPT ); Wed, 23 Feb 2022 13:56:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244045AbiBWS4P (ORCPT ); Wed, 23 Feb 2022 13:56:15 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 532323F313; Wed, 23 Feb 2022 10:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645642547; x=1677178547; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=RimaKXFhr9mzukP4fNaT0hhnC3zqMaGlaLRl4CVVfDA=; b=EkILOzoyt++6gRKq/aNdDrAjgnIXqSd6c4EkEqSOX9OjIfO1NvoSEAlL y4p2Ripu5Oxq5Q2L5aZoUiqIXWiSehkwayf2cpo9gQqsmV/Pjs2+KKQH0 46vZU7PQapUVC8GtbkXbg6Z+QWPDHiTHd5FO5FC+NJiXwt+xppwADW5Py p7G29tdBPkBnU/ZzetbJkTjPbyrS+eyrX0jPHPj9OKXiZ1Pi90CfwwKpS UTletKk7Fy08ZL86yeVoDPl1bbsfv/eGEEPmNaW1oPkYTOglr9yDud/vx dV/fTyzvlAARVIh8AVLrCYOV8K076IrzYmuM2lb7yXXqxsOucJ6s6acCD w==; X-IronPort-AV: E=McAfee;i="6200,9189,10267"; a="251792693" X-IronPort-AV: E=Sophos;i="5.88,391,1635231600"; d="scan'208";a="251792693" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2022 10:55:39 -0800 X-IronPort-AV: E=Sophos;i="5.88,391,1635231600"; d="scan'208";a="491319477" Received: from aacunaco-mobl1.amr.corp.intel.com (HELO [10.209.144.93]) ([10.209.144.93]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Feb 2022 10:55:39 -0800 Message-ID: Date: Wed, 23 Feb 2022 12:21:45 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Subject: Re: [PATCH 1/3] soundwire: qcom: add runtime pm support Content-Language: en-US To: Srinivas Kandagatla , robh+dt@kernel.org, vkoul@kernel.org, yung-chuan.liao@linux.intel.com Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, quic_srivasam@quicinc.com References: <20220221104127.15670-1-srinivas.kandagatla@linaro.org> <20220221104127.15670-2-srinivas.kandagatla@linaro.org> <70db9c01-104e-e081-198e-0b6d8a1c17da@linux.intel.com> <1e532280-5388-157b-8e2d-2ca8b2619f37@linaro.org> From: Pierre-Louis Bossart In-Reply-To: <1e532280-5388-157b-8e2d-2ca8b2619f37@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org > There are two cases here. > > 1> Controller Instance support ClockStop Mode0, we mostly use the > generic core to do that except in resume path we make sure that we start > the clock. > > 2> Controller Instances which that do not support ClockStop, we do soft > reset of controller along with hard resetting slaves. both are fine. we have similar cases defined in sdw_intel.h >>> +static int swrm_runtime_resume(struct device *dev) >>> +{ >>> +    struct qcom_swrm_ctrl *ctrl = dev_get_drvdata(dev); >>> +    int ret; >>> + >>> +    clk_prepare_enable(ctrl->hclk); >>> + >>> +    if (ctrl->clk_stop_bus_reset) { >>> +        reinit_completion(&ctrl->enumeration); >>> +        ctrl->reg_write(ctrl, SWRM_COMP_SW_RESET, 0x01); >>> +        qcom_swrm_get_device_status(ctrl); >> >> don't you need some sort of delay before checking the controller and >> device status? The bus reset sequence takes 4096 bits, that's a non-zero >> time. > > This is soft reset not full Bus Reset as WSA slaves have hard reset pins > that will be toggled as part of suspend-resume. Above you mentioned the peripherals go through a reset as well, in which case they can only re-attach on the bus after 16 frames best case - they need to observe a full cycle of the dynamic sync before changing status. That's still a non-zero delay (0.3ms for a 48kHz frame rate) >> >>> +        sdw_handle_slave_status(&ctrl->bus, ctrl->status); >>> +        qcom_swrm_init(ctrl);