Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3679052imm; Mon, 1 Oct 2018 02:40:24 -0700 (PDT) X-Google-Smtp-Source: ACcGV61l6UnhYkNL3vxZP9d1X042oLgyft6zc4NyFdKC9eefyXHLfmgJm3vMAqpWpE6fiBKgp46z X-Received: by 2002:a62:8559:: with SMTP id u86-v6mr10651711pfd.32.1538386824676; Mon, 01 Oct 2018 02:40:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538386824; cv=none; d=google.com; s=arc-20160816; b=Cltm2KetBz1zJQfdYj0fJD8t5lefxrWBuQncs+9zr+vMneXIdf+LgcnbAS8HFpc77y M9ml1U4zHP16+o9BdzsELQTmsXOsi5iYxcG8H/aDQNBPkdPRHcC8BqzPPVTt4bkfewg5 vtj+eX8UExgmy30oz190+6hW/PdMOfyfR3MSwIekQH98e1+NMnKplCqXp9Nszu0R3r+l No9sEFJBCKxwJRWoQupBmnMEpxOjkgiQsKBqGjRQyULYKcEbWAqbMbEhxZdHNzXAuIh4 70hYLA0ki6BfqeK3FtafwyEU1rvcFMNqgtyTPnJEXz0Q3ehlaGU4fAq3FLtMRtmiqtlh vrBg== 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=xanetU4/5HagGtkISNZ1t3wsrG5htnWymXlhbIcV6OU=; b=mwoNtDbPjE9MYZulBG/XGXV+YMrIyG+fD4Z1FvWT5QZunNlHtO6uJobXjj/mlTtoaj BVzk0Fvu/iBnizCl+tPyPacQu7LkHn7EIx1WR1nGAU1iP7PCofVMCg3ZXU728BuZA5qp Z/I9+xRW2hhU3UR+416gcEChTpNbyjks8BqNrit+/8ommsWFL2Qfc6mpdIO64niyCXob bz+fVKhozVFl4RLNYeZbyOA9gNT0BM5zeKrLYn1fjswUIJfjKAZhNtPUHeD+aCiSx/v/ 7fugSYmRebm3Z/E1lYLia6rVjVlEDw3iJ6oiFhUk6iXp7aR7ZympaUV3iqH1X1WOuagt mGoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Uwb+w+Pu; 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 d5-v6si12494457pla.439.2018.10.01.02.40.09; Mon, 01 Oct 2018 02:40:24 -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=Uwb+w+Pu; 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 S1729122AbeJAQPi (ORCPT + 99 others); Mon, 1 Oct 2018 12:15:38 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:41215 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726648AbeJAQPh (ORCPT ); Mon, 1 Oct 2018 12:15:37 -0400 Received: by mail-io1-f67.google.com with SMTP id q4-v6so8829519iob.8 for ; Mon, 01 Oct 2018 02:38:43 -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=xanetU4/5HagGtkISNZ1t3wsrG5htnWymXlhbIcV6OU=; b=Uwb+w+Pu2Dz6M0puLAQW6acp+Dta9W8zMzVenK2F7svafrJnj7l/F1CRP83GNB3GZH 34U2JMPjABVjoi1lMh735gC955YDyxsFmViQmgKN/Z09xE06e8MClThJF5iLazH/yezc 3aUhjZ9XIulz6h9XURQa7pTCdZVK9a7dq9XhI= 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=xanetU4/5HagGtkISNZ1t3wsrG5htnWymXlhbIcV6OU=; b=Xm+GvdTbuLyRQo3MDs+ESxuBlDL2WOgf8r7yx1gQI6v9PbOW9ELufdL/euix5eEtIf IV9vPpWlPktEXe6ZDV2NExzRAcjAUU6XM2ZZHNov39MAw/1lB0Fmmtt6mQe7AMry0FOL e8y6bwUW7+UBa4KjWLcketpzXjCHEr+t6A2tVzyNCiRLZRGptzMbbJWmOcgQidSj2WYk 0wXbSYvLPFSk582CsZzUXD3ZWGuLqkYOyU/Qvvq6wIlP0o10upKBBjRhJa2uF1QCCMpg DY1wC2HpHRUczeRr8qqzf696f94IMbaUEDEpeI3Rc97tzb953CQcMHdJk10iY7ODQ6kA Vs8w== X-Gm-Message-State: ABuFfoi59t3/U9BPyfXbI8KBxl6rNHk8LiFdWT0c9SleK8Ry7+4MAKtK sKvKX0WZ7Z5hV5aMaDuZxPN63BP9nYxa4gHYXlCUpA== X-Received: by 2002:a6b:203:: with SMTP id 3-v6mr6172975ioc.131.1538386723079; Mon, 01 Oct 2018 02:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:3941:0:0:0:0:0 with HTTP; Mon, 1 Oct 2018 02:38:02 -0700 (PDT) In-Reply-To: References: <20180830144541.17740-1-vivek.gautam@codeaurora.org> <20180830144541.17740-2-vivek.gautam@codeaurora.org> From: Ulf Hansson Date: Mon, 1 Oct 2018 11:38:02 +0200 Message-ID: Subject: Re: [PATCH v16 1/5] iommu/arm-smmu: Add pm_runtime/sleep ops To: Vivek Gautam Cc: Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Alex Williamson , Linux PM , Stephen Boyd , "Rafael J. Wysocki" , Will Deacon , open list , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , "robh+dt" , linux-arm-msm , freedreno , Robin Murphy 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 1 October 2018 at 07:49, Vivek Gautam wrote: > HI Ulf, > > On Fri, Sep 28, 2018 at 5:30 PM Ulf Hansson wrote: >> >> 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. > > Thanks for the review. I will change this as suggested. > >> >> > + >> > + 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. > > Well yes, as you said the device links should be able to take care of > maintaining the correct suspend/resume order of smmu and its clients, > or am I missing your point here? > Let me know and I will be happy to incorporate any suggestions. > Thanks If it works fine, then you may keep it as is. Just wanted to point out that if any consumers relies on the iommu to operational to say until the suspend-late phase, then this doesn't play. Then you need to move your callbacks to the corresponding same phase. [...] Kind regards Uffe