Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3812229imm; Mon, 1 Oct 2018 05:03:18 -0700 (PDT) X-Google-Smtp-Source: ACcGV639iw2Jv5OUhKUJEVJMsR75W0BfCcZipgmlTMkyXrz8wfoC+352HobKrqf1PaObMA2t1Zpf X-Received: by 2002:a17:902:4103:: with SMTP id e3-v6mr6755pld.236.1538395398560; Mon, 01 Oct 2018 05:03:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538395398; cv=none; d=google.com; s=arc-20160816; b=RHm3kETpyg9t2RKz+93hXI4siGE9pUoY9PNQ1qqa/kUMLA1yyY1HaPM/yilHzHnHZ3 bm8Fi/7p2PM1ih4s5IHTqUNhjreBUN8PE7mf+8Kd8HXpihlodQVucV482zz7Vf12PjWq tW7hpqtU7dKwh7iUeTjgBQOVzT3krU99eKxMelN95QGLwKQJrCrzAns3kkALvJ+rJE00 wndeL8uordrTzitkZkZ0Kv1gaTTIugRU9EXfsNBe2hKP5ilq8Vk3BA/4lvmoMg81szIx Ig5cu6lWNoDxzyz7F5h6Chin91o47tXIwRXZE9vazToGIhz24WUqIsPSDs+qUH995e/0 Arfw== 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=+BFsasdfgWa2uNaN+YYk2GM5/zNh77X4JcT+Otj08CI=; b=g5kcKXES4hixdIhTY3oOG+094l7SrteCcXjgczQsXFPnSluAhI7R+sosxu4EjFNCB5 NHFox6exmyrQOzr90hhgWjMzdgedM2ypAoPmG9XhPeIQyaCaOgwdPTF8Ge78MazWm3qw F4t9TSSFNbMkxHFST/ifrTBhDTQR5VUQ9mvqQvEGauSQthByl4Wm2PBDsmaTPqzd7VYF Lku/r6thqQNLBdAZ1OeFdWCouBMz00VSJ47Ih7m7lgiIWGhs0wxstTddFek9M9K7oLC4 lQC17UYHggYCDfNNv+R8YVQdpyRKIP2CLffhszYka5oNtKrecJv7riwndPV9ttbbwJI+ LGOw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kjXPLla+; 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 x3-v6si12516888pln.232.2018.10.01.05.03.00; Mon, 01 Oct 2018 05:03:18 -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=kjXPLla+; 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 S1729240AbeJASkV (ORCPT + 99 others); Mon, 1 Oct 2018 14:40:21 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:41895 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728921AbeJASkU (ORCPT ); Mon, 1 Oct 2018 14:40:20 -0400 Received: by mail-io1-f68.google.com with SMTP id q4-v6so9132797iob.8 for ; Mon, 01 Oct 2018 05:02:52 -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=+BFsasdfgWa2uNaN+YYk2GM5/zNh77X4JcT+Otj08CI=; b=kjXPLla+Oc5i/KukVUSF/mM95kM0Y7nrP1HpaiY9Wu+Iip75Xv8vYEYb6XhGsmAWKV GEI3hONKZsXG/pCCFlIojlq9UtxNJ1kskaB/CQwgw+y6QpB1Qd0oDLOwBMGQ/9OU8BTv Kg0a3ywGrlMvb+UY9H/Bpaj4SGqAl+7AKPkEU= 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=+BFsasdfgWa2uNaN+YYk2GM5/zNh77X4JcT+Otj08CI=; b=RkipeRjv+hJ7oXzApba57Zs/gDmq284EogLUGN1Hn9J4ybEbWrl5cVzQ2tjtlKnaxY 2KxsrV0I+eipnLJ0ytTOdt8vKi23Q8J7h8FJ0KzJj/wXH4K0gFpgXMuls389yZ1avG3J 0TCqWM/KeK0KyceW8fOj0Opx8yVfzcIgc0CoLDrkLe5DlK8FOwzcMJsieufaPjvRqUOD PBexISyLlF71R37GltV6Uj3Dv1mxZ42JFIFkLQIuMEBNLzlZwBQx0G1ZJBj94qkvVfn/ 87WKysfIMopqvsvwk+H+O/wqL05IGfr5UKLCgdb9R9sstv+o88Zf/+M0jB5WpQFwlK7T 2ZqA== X-Gm-Message-State: ABuFfojCdSOfA35o9Xtn0Uxq6iXIHjyS1SBTEg2ifsq+H8vRaxYVZtck +Ra+gW0ZkANDoUk1E9TdeL2kZFgABdqmDIuL4vJ2VQ== X-Received: by 2002:a6b:203:: with SMTP id 3-v6mr6498611ioc.131.1538395372043; Mon, 01 Oct 2018 05:02:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:3941:0:0:0:0:0 with HTTP; Mon, 1 Oct 2018 05:02:11 -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 14:02:11 +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 12:32, Vivek Gautam wrote: > On Mon, Oct 1, 2018 at 11:19 AM 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. > > Coming back at this - actually Rafael suggested _not_ to use > pm_runtime_force_suspend/resume() when Marek had suggested > the same [1]. I see. > He also mentioned few caveats/limitations of using these APIs > for system sleep ops. > Let me know your opinion. Thanks. > > [1] https://lkml.org/lkml/2018/7/11/978 > [2] https://lkml.org/lkml/2018/7/23/334 Me and Rafael have been discussing these topics historically as well. I don't want to get that discussion started again here. If your device is attached to the PCI bus or the ACPI PM domain (and also gets runtime PM enabled), then I suggest you to stick to the currently suggested approach. Otherwise it should be perfectly fine to switch to the *force helpers. Kind regards Uffe