Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp2188387pxy; Mon, 2 Aug 2021 23:08:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymw/ORChH3GWVkBjpI1DoFwibjibWAKh8Ik8VfECAHB8iky0/6+A37ynLC3OYP1jAHZTBC X-Received: by 2002:a92:c605:: with SMTP id p5mr106859ilm.209.1627970881679; Mon, 02 Aug 2021 23:08:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627970881; cv=none; d=google.com; s=arc-20160816; b=rcAPIb7/2+x6DMp4H7FC16y7YoqAbjAS3rwaSHWZ5XErywbyLi5j/Wn7JNdqBM/VtL AhIWcXeXQ65ykQsDQ3AVQEmvhw1HCOohA9NVPg6Qocjs2H0dKh0ADoKROn8GnWOpv/7f WJDxkrgChDYnnqUALKGTBl/Q7sadH5EAMjDc8YVsj8jAvst4S+tIRmOKsQMIiP8lgv23 k+M++3MCbT1T7phquHrzdXhO4LO9aZP602HzxpOqvwbt6GRI+Uj1/+NL8PIULy1Stz6F nccMNU4aj7Jq8yuBBAtQa4DUb3GNIVSSsFKsAgbHIMbLZmLixDR9cbnsyQr3bnJVOxk7 fYCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :sender:dkim-signature; bh=2cVRR6X0LJPFMsvW7MYfIuMqP7lLF7KckuG7UikunoI=; b=suOu4OLX6V8lTj58nkEMkVriMV9/GH1MwBWjpag66//3PoSrz0uPc8aj4027koc1wi o1tDBlqAAJWuOchX35nAnLjLQ3ePHyZPCQ+S4HBXudBhFyOMkmvUqFo3Q+GqXzrujYPQ pgRYZngnPMC5KYHZhkkhhH+ltVAikiidmw8QGOLH+W5kbGedTibrx/+cKyt3g0DB0O1W mIhXBjEpSZ6+SP25Fh37PAYDvvOks4ReBaQRi1OzhmBv0ebiHdxnufHNguO0Izabj+LE k8tSKKycQ0I6GKE3cQzlsWuic04Ipxr1KUeq0ceJmGsv0/yrnpCQ8bxMhPp4iGZBFEvS 1uAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=nd2ren9c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d22si1263143ioo.71.2021.08.02.23.07.50; Mon, 02 Aug 2021 23:08:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=nd2ren9c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233895AbhHCGGs (ORCPT + 99 others); Tue, 3 Aug 2021 02:06:48 -0400 Received: from so254-9.mailgun.net ([198.61.254.9]:37250 "EHLO so254-9.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231386AbhHCGGr (ORCPT ); Tue, 3 Aug 2021 02:06:47 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1627970797; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=2cVRR6X0LJPFMsvW7MYfIuMqP7lLF7KckuG7UikunoI=; b=nd2ren9c3OxZg54JaNlduz9187OpDIZKXnw4KrsWDphAXGV+NdaE50f11AhCjafxTG2rm5s0 dvw7vpmc1VM28uOVXHWqfEN0tvb1944Oig4mAMe6fzeUW8omAvZS5NDm9jxr1F3mfyWFjuXf QHzi6UrRb9RjuQaPqAQvwivGg1U= X-Mailgun-Sending-Ip: 198.61.254.9 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n02.prod.us-west-2.postgun.com with SMTP id 6108dcd596a66e66b227c251 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 03 Aug 2021 06:06:13 GMT Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 4463EC4323A; Tue, 3 Aug 2021 06:06:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan) by smtp.codeaurora.org (Postfix) with ESMTPSA id 296A2C433D3; Tue, 3 Aug 2021 06:06:12 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 03 Aug 2021 11:36:12 +0530 From: Sai Prakash Ranjan To: Will Deacon Cc: Robin Murphy , Joerg Roedel , Rajendra Nayak , Taniya Das , srimuc , iommu@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, robdclark@chromium.org Subject: Re: [PATCH] iommu/arm-smmu: Add clk_bulk_{prepare/unprepare} to system pm callbacks In-Reply-To: <20210802161206.GA29168@willie-the-truck> References: <20210727093322.13202-1-saiprakash.ranjan@codeaurora.org> <20210802161206.GA29168@willie-the-truck> Message-ID: <5aefcc8950ec8ced0a67815c92e985df@codeaurora.org> X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-08-02 21:42, Will Deacon wrote: > On Tue, Jul 27, 2021 at 03:03:22PM +0530, Sai Prakash Ranjan wrote: >> Some clocks for SMMU can have parent as XO such as >> gpu_cc_hub_cx_int_clk >> of GPU SMMU in QTI SC7280 SoC and in order to enter deep sleep states >> in >> such cases, we would need to drop the XO clock vote in unprepare call >> and >> this unprepare callback for XO is in RPMh (Resource Power >> Manager-Hardened) >> clock driver which controls RPMh managed clock resources for new QTI >> SoCs >> and is a blocking call. >> >> Given we cannot have a sleeping calls such as clk_bulk_prepare() and >> clk_bulk_unprepare() in arm-smmu runtime pm callbacks since the iommu >> operations like map and unmap can be in atomic context and are in fast >> path, add this prepare and unprepare call to drop the XO vote only for >> system pm callbacks since it is not a fast path and we expect the >> system >> to enter deep sleep states with system pm as opposed to runtime pm. >> >> This is a similar sequence of clock requests (prepare,enable and >> disable,unprepare) in arm-smmu probe and remove. >> >> Signed-off-by: Sai Prakash Ranjan >> Co-developed-by: Rajendra Nayak >> Signed-off-by: Rajendra Nayak >> --- >> drivers/iommu/arm/arm-smmu/arm-smmu.c | 20 ++++++++++++++++++-- >> 1 file changed, 18 insertions(+), 2 deletions(-) > > [+Rob] > > How does this work with that funny GPU which writes to the SMMU > registers > directly? Does the SMMU need to remain independently clocked for that > to > work or is it all in the same clock domain? > As Rob mentioned, device link should take care of all the dependencies between SMMU and its consumers. But not sure how the question relates to this patch as this change is for system pm and not runtime pm, so it is exactly the sequence of SMMU probe/remove which if works currently for that GPU SMMU, then it should work just fine for system suspend and resume as well. >> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c >> b/drivers/iommu/arm/arm-smmu/arm-smmu.c >> index d3c6f54110a5..9561ba4c5d39 100644 >> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c >> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c >> @@ -2277,6 +2277,13 @@ static int __maybe_unused >> arm_smmu_runtime_suspend(struct device *dev) >> >> static int __maybe_unused arm_smmu_pm_resume(struct device *dev) >> { >> + int ret; >> + struct arm_smmu_device *smmu = dev_get_drvdata(dev); >> + >> + ret = clk_bulk_prepare(smmu->num_clks, smmu->clks); >> + if (ret) >> + return ret; >> + >> if (pm_runtime_suspended(dev)) >> return 0; > > If we subsequently fail to enable the clks in arm_smmu_runtime_resume() > should we unprepare them again? > If we are unable to turn on the clks then its fatal and we will not live for long. Thanks, Sai > Will > >> @@ -2285,10 +2292,19 @@ static int __maybe_unused >> arm_smmu_pm_resume(struct device *dev) >> >> static int __maybe_unused arm_smmu_pm_suspend(struct device *dev) >> { >> + int ret = 0; >> + struct arm_smmu_device *smmu = dev_get_drvdata(dev); >> + >> if (pm_runtime_suspended(dev)) >> - return 0; >> + goto clk_unprepare; >> >> - return arm_smmu_runtime_suspend(dev); >> + ret = arm_smmu_runtime_suspend(dev); >> + if (ret) >> + return ret; >> + >> +clk_unprepare: >> + clk_bulk_unprepare(smmu->num_clks, smmu->clks); >> + return ret; >> } >> >> static const struct dev_pm_ops arm_smmu_pm_ops = { >> -- >> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a >> member >> of Code Aurora Forum, hosted by The Linux Foundation >> -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation