Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3726579imm; Mon, 1 Oct 2018 03:33:08 -0700 (PDT) X-Google-Smtp-Source: ACcGV61DgggP7DNFsGJFJN4WflGJ5SjzfFgRjSCaamG4AEkfQfd+WeW10ot8S2NOw6sjrY0geSz8 X-Received: by 2002:a63:170b:: with SMTP id x11-v6mr9397451pgl.364.1538389988924; Mon, 01 Oct 2018 03:33:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538389988; cv=none; d=google.com; s=arc-20160816; b=cM4UPe0t4WISnkh8jjDHXDXAV3qiDQlwn/5DNIhvN81e4/qjlO43hR3di1f1ffOLHL IOSk6I9SOIAX/RZXulBLCZ6iTj0po00fi0hF5Uh+upXmUvxWG1mupZgJPKEtLDByGYIT p0WoKV31kXJOrHvd5cdVunkYiaoiRIrIjZ9sR1BLKSsF07B+fRJ9cBXJBgwTkH0ZgtFU sieVANCo2MfY/vyQZz6G+SCbMJrIpYWPKtcYNIUyKyiA106Xt8WwRZs8MAiBNgark/tA pwEeEvZ0pQ15oxFy/d+R3gs3kAevLnaCDEBoi7meWHqIbFDPyCrMc6R0vwMA1Afw1IHq WXFg== 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 :in-reply-to:references:mime-version:dmarc-filter:dkim-signature :dkim-signature; bh=VPKQEb+Xu799OOFE5Bm1/msLriRC9uRQcJ47XBqwYlk=; b=lzjWT32wgVWgVh1ok1zO0xtjR09wWd9zOVZjjRC4mth3lmqulBiDBE2Fnk4AwYtBNu 6wSvoHXh0ypiZ0VyD00apLJRam0bRCrpQ/Zgp+aEJYWIzGHX7BC8ZbAdSjErFzfACMIH BfX6zTe2x3ZXCcRfuyHXRPWRQHv5dpmbYee061v4KhZ4PTjxBp+JeYJkpQh0WUgiawZr npyhuLgPyuAalLyzcME42HRJ+mCSACNDM3wSDYL8Ub8jpvMS8Fk2kLvPKMsypRU9n8sp Efw50tcpq2UlNeHUGWDIuaWM+83bqrP37v73aNLJu3ZraWVeEJSVguQ27WN4ihNTIM40 RZNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=UbW6DOv9; dkim=pass header.i=@codeaurora.org header.s=default header.b=jXVqhiMB; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si11920577plk.379.2018.10.01.03.32.54; Mon, 01 Oct 2018 03:33:08 -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=@codeaurora.org header.s=default header.b=UbW6DOv9; dkim=pass header.i=@codeaurora.org header.s=default header.b=jXVqhiMB; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729439AbeJARJl (ORCPT + 99 others); Mon, 1 Oct 2018 13:09:41 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:43930 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729394AbeJARJk (ORCPT ); Mon, 1 Oct 2018 13:09:40 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id C9D9860C54; Mon, 1 Oct 2018 10:32:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1538389951; bh=Oo5isZtCvLKRVfkbYzOjBJKmxWpiGgsBu+QLrg2QKzM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=UbW6DOv96+DwRK8lbZ2wL5XFpFuBUnPA+U6bqoQ/63QEyK8Z61dLlWJI68EqGCaun y6mAqnAYMTGfHg7ZMaIEwZtKZHRUs4b1R9yGJT+MnF1oBLaFBvDqbOWlnlb0LnibSM dZTyDHA87j+5Ypr4spexbKqDsYakidebEJbNRvMQ= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.0 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vivek.gautam@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 4FA7060C5F; Mon, 1 Oct 2018 10:32:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1538389950; bh=Oo5isZtCvLKRVfkbYzOjBJKmxWpiGgsBu+QLrg2QKzM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jXVqhiMBgOzkhcXmMjzd8x7dZzGXKLL3rEUxsw2SjmNw/eXbSjUbLmZLN8ZnapcJ8 wG28TzF/b/ZwERpriE55qnYmsPWaRroJHtlzZzSvSi0SgZNYayRc3jw9Plww0IOZPg /slYAutvtjSg33K5y5LcLo9ppwfdsY93kUiO2w8E= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 4FA7060C5F Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=vivek.gautam@codeaurora.org Received: by mail-qt1-f182.google.com with SMTP id z8-v6so13288918qto.9; Mon, 01 Oct 2018 03:32:30 -0700 (PDT) X-Gm-Message-State: ABuFfoiQt8NNoyzNxcHdkmtfFRA6gCKwTn0V16T9meVlqleWd2t8vIxR G/4/BzZsSyNI4oNY7b/xDJ+kbGrnlcJkyoDHLI8= X-Received: by 2002:a0c:8563:: with SMTP id n90-v6mr7835378qva.93.1538389949468; Mon, 01 Oct 2018 03:32:29 -0700 (PDT) MIME-Version: 1.0 References: <20180830144541.17740-1-vivek.gautam@codeaurora.org> <20180830144541.17740-2-vivek.gautam@codeaurora.org> In-Reply-To: From: Vivek Gautam Date: Mon, 1 Oct 2018 16:02:17 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v16 1/5] iommu/arm-smmu: Add pm_runtime/sleep ops To: Ulf Hansson Cc: Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , alex.williamson@redhat.com, Linux PM , sboyd@kernel.org, "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 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]. 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 Best regards Vivek -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation