Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp667385imm; Fri, 28 Sep 2018 05:01:31 -0700 (PDT) X-Google-Smtp-Source: ACcGV63nIqOQl8D/yD9xXEBIDk7RgKtxiBxM6fV22gUQQe9QGit6b99OTsBJF7BC+ktq67ZAFeH2 X-Received: by 2002:a63:d70c:: with SMTP id d12-v6mr9912367pgg.110.1538136091348; Fri, 28 Sep 2018 05:01:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538136091; cv=none; d=google.com; s=arc-20160816; b=syf2UWSiPLogO9ZauD/Zt7+g/4JfJiQ0OAWKNkrGJ8z4u0FiGK2L6d9L/1sEAAdTu6 A/gUFJAUX3mN352nGckJP9FlfTcPvEoiRwsWJi7lJRaLZaXcqfMWoycZXtSfWCD+P1TP 2qLw2MqabmXpUPNifT9Y3iIoQ4GseqEjOuDIHltipBAaameqTtolqDnFWyrpyg2dgX5x YxPIwttn//y0kOmouHzDrBHwmSZzgMkJKbpFpG5qoDwdjttp7Xniti4qMXwCdqmb0h8K Y1QEaFxHrM46inUkKPPldj2QOQb7XR6DUXZV0V8y3QWyDWTDk3cLu5diMwie44GU6zI7 77Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=cfAi6cLY5StfphmrK8e7JbfFGi0q2KFfmMHsIsRg4TI=; b=Yr/5tcyGMEOCWkgMm5UaLQJtH8p4yXUhqlIRXbDgLV0VZdGH5df6H53+3eoHJoXh57 Hrw+ZiR5Mha5lwUwnqDY1aE2HV7tg1d7UBliE0UgO5L/B18JUXXwzcqkhEmDZ7ER2pP5 RFvYy0xfudv7gq2tWS+M68/o1uqYpLiolwRaoSm3THO/zA8qFjLYk0ZVnvsr532+7Jwp PD7eNgmPJGLWr2SlOTv6UiHZi1re4Hh6Bz00enBun1o8E/hiBBuKjVguT+zhtSY6ZXqA S5XGZb79cAVM6osOugZaUaX4oN3sdwibVUUmtxeY2HExwTJnLs0NqdvJEhgqp+il6v+w 3Zxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Zuv4+wfy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c2-v6si4469548pgm.236.2018.09.28.05.01.13; Fri, 28 Sep 2018 05:01:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Zuv4+wfy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728451AbeI1SXn (ORCPT + 99 others); Fri, 28 Sep 2018 14:23:43 -0400 Received: from mail-it1-f194.google.com ([209.85.166.194]:33209 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726603AbeI1SXn (ORCPT ); Fri, 28 Sep 2018 14:23:43 -0400 Received: by mail-it1-f194.google.com with SMTP id h6-v6so38951ith.0 for ; Fri, 28 Sep 2018 05:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cfAi6cLY5StfphmrK8e7JbfFGi0q2KFfmMHsIsRg4TI=; b=Zuv4+wfyvnmFHJZl7dHaphFMIA3lE7rcTe4qFDxae5HowADo2MFcigzgoq++udzuJ9 WsXcLtfstVFQtIdncDHSZFSQLq3L9wGokSUlOcbI7KcTdkU++a9Mrr0pbbJgRA6HgA3B lUsxAhTexyYT5PP7emOdEp5hFFUtKw4v+q5Po= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cfAi6cLY5StfphmrK8e7JbfFGi0q2KFfmMHsIsRg4TI=; b=fcoSH3vSH7q66BLZWl6u99z+HyEFqab3LuVof4pzr3fjJg10sMWbZ1JCUE4GAD4OcL +5ZaLkYACtNn1g5LG1lEo71eBckmELp6Aer62yPDyYKiUCd9tpTlGikPdbNOIkbG8iFc W/aQBravexxlnfuYvwUXdAuhIIti9YxdbagwatkwPFSj7fU+JAQ6TnMosdDHn5XFfTyl 1jpyvvf3d0qgJWBs/kCS6Ki1Iem/BihfG4EdKf187/4lMRmq1l1wX2Bqc6rt+cHKXyh3 WEJCuV0Y6uq4SZ9JxjV3re9facRslwdDMTP68rL3O5Ejjdx1BakRO1OULsURS6nWLZ1B EPqg== X-Gm-Message-State: ABuFfohOdNIfS2Iiec1PE4N9jhRop9WcYRN063Q2wzkv/y3XNN51qVH5 SB4cZkb2t2E9l2k1cHrc5ImIPagMmUFp7oeNGp3IGA== X-Received: by 2002:a24:8045:: with SMTP id g66-v6mr1303690itd.45.1538136015830; Fri, 28 Sep 2018 05:00:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:6a18:0:0:0:0:0 with HTTP; Fri, 28 Sep 2018 04:59:35 -0700 (PDT) In-Reply-To: <20180830144541.17740-2-vivek.gautam@codeaurora.org> References: <20180830144541.17740-1-vivek.gautam@codeaurora.org> <20180830144541.17740-2-vivek.gautam@codeaurora.org> From: Ulf Hansson Date: Fri, 28 Sep 2018 13:59:35 +0200 Message-ID: Subject: Re: [PATCH v16 1/5] iommu/arm-smmu: Add pm_runtime/sleep ops To: Vivek Gautam Cc: Joerg Roedel , Rob Herring , Robin Murphy , Will Deacon , iommu@lists.linux-foundation.org, DTML , Linux Kernel Mailing List , Alex Williamson , Mark Rutland , "Rafael J. Wysocki" , robdclark@gmail.com, Linux PM , freedreno@lists.freedesktop.org, Stephen Boyd , Tomasz Figa , Jordan Crouse , Sricharan , Marek Szyprowski , architt@codeaurora.org, linux-arm-msm Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30 August 2018 at 16:45, Vivek Gautam wrote: > From: Sricharan R > > The smmu needs to be functional only when the respective > master's using it are active. The device_link feature > helps to track such functional dependencies, so that the > iommu gets powered when the master device enables itself > using pm_runtime. So by adapting the smmu driver for > runtime pm, above said dependency can be addressed. > > This patch adds the pm runtime/sleep callbacks to the > driver and also the functions to parse the smmu clocks > from DT and enable them in resume/suspend. > > Also, while we enable the runtime pm add a pm sleep suspend > callback that pushes devices to low power state by turning > the clocks off in a system sleep. > Also add corresponding clock enable path in resume callback. > > Signed-off-by: Sricharan R > Signed-off-by: Archit Taneja > [vivek: rework for clock and pm ops] > Signed-off-by: Vivek Gautam > Reviewed-by: Tomasz Figa > Tested-by: Srinivas Kandagatla > --- > drivers/iommu/arm-smmu.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 74 insertions(+), 3 deletions(-) > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c [...] > -static int __maybe_unused arm_smmu_pm_resume(struct device *dev) > +static int __maybe_unused arm_smmu_runtime_resume(struct device *dev) > { > struct arm_smmu_device *smmu = dev_get_drvdata(dev); > + int ret; > + > + ret = clk_bulk_enable(smmu->num_clks, smmu->clks); > + if (ret) > + return ret; > > arm_smmu_device_reset(smmu); > + > return 0; > } > > -static SIMPLE_DEV_PM_OPS(arm_smmu_pm_ops, NULL, arm_smmu_pm_resume); > +static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev) > +{ > + struct arm_smmu_device *smmu = dev_get_drvdata(dev); > + > + clk_bulk_disable(smmu->num_clks, smmu->clks); > + > + return 0; > +} > + > +static int __maybe_unused arm_smmu_pm_resume(struct device *dev) > +{ > + if (pm_runtime_suspended(dev)) > + return 0; Looks like you should be able use pm_runtime_force_resume(), instead of using this local trick. Unless I am missing something, of course. In other words, just assign the system sleep callbacks for resume, to pm_runtime_force_resume(). And vice verse for the system suspend callbacks, pm_runtime_force_suspend(), of course. > + > + return arm_smmu_runtime_resume(dev); > +} > + > +static int __maybe_unused arm_smmu_pm_suspend(struct device *dev) > +{ > + if (pm_runtime_suspended(dev)) > + return 0; > + > + return arm_smmu_runtime_suspend(dev); > +} > + > +static const struct dev_pm_ops arm_smmu_pm_ops = { > + SET_SYSTEM_SLEEP_PM_OPS(arm_smmu_pm_suspend, arm_smmu_pm_resume) I am wondering if using the ->suspend|resume() callback is really "late/early" enough in the device suspend phase? Others is using the noirq phase and some is even using the syscore ops. Of course it depends on the behavior of the consumers of iommu device, and I guess not everyone is using device links, which for sure improves things in this regards as well. > + SET_RUNTIME_PM_OPS(arm_smmu_runtime_suspend, > + arm_smmu_runtime_resume, NULL) > +}; > > static struct platform_driver arm_smmu_driver = { > .driver = { > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation > BTW, apologize for very late review comments. Besides the above comments, the series looks good to me. Kind regards Uffe