Received: by 10.213.65.68 with SMTP id h4csp1481454imn; Thu, 15 Mar 2018 00:19:52 -0700 (PDT) X-Google-Smtp-Source: AG47ELskEjbHIqb2vlI0XFzRCnM7LnXIJL+Yo1drSQbTA5K5pY2fTUTxjVtMtiOP6DOJ16oAU5xi X-Received: by 10.98.86.15 with SMTP id k15mr6892721pfb.187.1521098392371; Thu, 15 Mar 2018 00:19:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521098392; cv=none; d=google.com; s=arc-20160816; b=TAOd+/35x5bCPNNaB1ReuQ2/cBcsL11BZ9Eo9o0jZtvFM4fdQMpKcQoBFz/q+mHpcZ kNKQmYajJvXnXj8qN4gJoviii6ihoT/bqE18q+9l1IWbeLBixq3xgpXngHnJRBtzSu+u tksgZVE6d5dp9DhyxYjsyP4xIRiLZTKEMX3vdRkVEx7yCx/yAxdkC2/UK2/PXln0cAsP Yj7bkXiv6q5C3QZ6nxyYrvo/YfuOFE05KWjC+MlaP8sDgwhetJAAhXWfGFSTXpo3X06T ljZT5RtmkOLDzW29XpOyQ4StrCV7Yfko6N8qTLig/IQUAEljvq5VxzSnIf8T2FIZQXpf LkIQ== 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 :arc-authentication-results; bh=VvNX1CpEXgpLV/qABMIlZOr8zuLBghXR9mPVi4LLjSE=; b=tutGsljNhF0SZl6DGYvkjxLSeLiImrVxgn1VniEoimHAzNgz7e5+mRL/47I51wPHI+ Hxgfl6Jvvpu95DEpW7hL3RlrAN5ssn8VpJ/R3HRJp/d63fFFgC14Obw7yymqWyJNkf6z HEIu3H5C2G61S4U3nCELfcCxA6Ir6qChnKm7L866agkMDPTWpF+qILz97KxG8IYuC9PM br3tPIIHBN0LSdjFhejDqGLRmRmxdFt8U/yn17FvFzV1Jm2mrBjLbSc1LveubdsUa6PA FvA2AUa96aVadP8yGqzSdIK21Y+/28enOerqUQ398VnrGo8CHThmd2FD0EUQLXmaews/ T60Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=K6ZPRM95; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z1-v6si1008603pll.302.2018.03.15.00.19.38; Thu, 15 Mar 2018 00:19:52 -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=@chromium.org header.s=google header.b=K6ZPRM95; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751691AbeCOHSH (ORCPT + 99 others); Thu, 15 Mar 2018 03:18:07 -0400 Received: from mail-vk0-f66.google.com ([209.85.213.66]:35249 "EHLO mail-vk0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751681AbeCOHSE (ORCPT ); Thu, 15 Mar 2018 03:18:04 -0400 Received: by mail-vk0-f66.google.com with SMTP id r197so2832903vke.2 for ; Thu, 15 Mar 2018 00:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VvNX1CpEXgpLV/qABMIlZOr8zuLBghXR9mPVi4LLjSE=; b=K6ZPRM95bd8ecTCCdTMqNEjIx1vPl/BK+0oeVwDMr0LbJhaNNG3Ek9K/ZQbdE4zq+W KXS7J6OFmWXiH0RUXlSBCS1ipbflcWXFigbLyuV07tVydzSTd+PvXEEtkgQH2jNjIy8n OEULSNMsz4gnScYaa6ZURI6vQKmZCHl3Cc5Ak= 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=VvNX1CpEXgpLV/qABMIlZOr8zuLBghXR9mPVi4LLjSE=; b=P+keN96KG+KQFIK+P+ZwFSlP5k9PMIRCtu/5ARf8C/VoUxblXjGqj2U0XFburPMsnj a5rT6kvJyslRkffTxfaaZek/t5EInSeA93l/fTJ49Ixw900WAsL4veep4PhcGrRTEhVH nBz91dSpk4sYTA/bwu1ixPSFnh2lBh3QbyO66u9j9HbRLCz+j8C4goo9gqFzZGTvVzmT qf7fE5Gh9jZyCBqgr9JBVhN762B3nQw21V0ty2JvKXQsz9hKbPII1cjKl02U5ywe4L3r DaaIovWgLuFvcCh1eBu7RwoPwW15M5RdW+uDJ4IAH5/InT3S+WQesTPhrTED+VOdjYro fFSw== X-Gm-Message-State: AElRT7GY/gdZuCJSJtLqQhHFEJrUmoZH73lZIyV76D+wst944aF8MlNI c2H13qLVTVbPhiqHLAkFA2MzRupbwlk= X-Received: by 10.31.188.139 with SMTP id m133mr5321921vkf.86.1521098282963; Thu, 15 Mar 2018 00:18:02 -0700 (PDT) Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com. [209.85.217.182]) by smtp.gmail.com with ESMTPSA id u4sm933117uaa.4.2018.03.15.00.18.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Mar 2018 00:18:01 -0700 (PDT) Received: by mail-ua0-f182.google.com with SMTP id n24so3715310ual.12 for ; Thu, 15 Mar 2018 00:18:01 -0700 (PDT) X-Received: by 10.159.52.101 with SMTP id s37mr5475350uab.24.1521098280877; Thu, 15 Mar 2018 00:18:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.0.99 with HTTP; Thu, 15 Mar 2018 00:17:40 -0700 (PDT) In-Reply-To: <77ed3675-0af0-b36a-5f76-b920d7a4c8e0@arm.com> References: <20180313085534.11650-1-vivek.gautam@codeaurora.org> <20180313085534.11650-4-vivek.gautam@codeaurora.org> <77ed3675-0af0-b36a-5f76-b920d7a4c8e0@arm.com> From: Tomasz Figa Date: Thu, 15 Mar 2018 16:17:40 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v9 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device To: Robin Murphy Cc: Vivek Gautam , Joerg Roedel , Rob Herring , "open list:IOMMU DRIVERS" , devicetree@vger.kernel.org, Linux Kernel Mailing List , Mark Rutland , Will Deacon , Rob Clark , Sricharan R , Marek Szyprowski , Archit Taneja , 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 Thu, Mar 15, 2018 at 2:46 AM, Robin Murphy wrote: > On 13/03/18 08:55, Vivek Gautam wrote: >> >> From: Sricharan R >> >> The smmu device probe/remove and add/remove master device callbacks >> gets called when the smmu is not linked to its master, that is without >> the context of the master device. So calling runtime apis in those places >> separately. >> >> Signed-off-by: Sricharan R >> [vivek: Cleanup pm runtime calls] >> Signed-off-by: Vivek Gautam >> Reviewed-by: Tomasz Figa >> --- >> drivers/iommu/arm-smmu.c | 95 >> ++++++++++++++++++++++++++++++++++++++++++++---- >> 1 file changed, 87 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >> index d5873d545024..56a04ae80bf3 100644 >> --- a/drivers/iommu/arm-smmu.c >> +++ b/drivers/iommu/arm-smmu.c >> @@ -268,6 +268,20 @@ static struct arm_smmu_option_prop arm_smmu_options[] >> = { >> { 0, NULL}, >> }; >> +static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu) >> +{ >> + if (pm_runtime_enabled(smmu->dev)) >> + return pm_runtime_get_sync(smmu->dev); >> + >> + return 0; >> +} >> + >> +static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu) >> +{ >> + if (pm_runtime_enabled(smmu->dev)) >> + pm_runtime_put(smmu->dev); >> +} >> + >> static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom) >> { >> return container_of(dom, struct arm_smmu_domain, domain); >> @@ -913,11 +927,15 @@ static void arm_smmu_destroy_domain_context(struct >> iommu_domain *domain) >> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >> struct arm_smmu_device *smmu = smmu_domain->smmu; >> struct arm_smmu_cfg *cfg = &smmu_domain->cfg; >> - int irq; >> + int ret, irq; >> if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY) >> return; >> + ret = arm_smmu_rpm_get(smmu); >> + if (ret < 0) >> + return; >> + >> /* >> * Disable the context bank and free the page tables before >> freeing >> * it. >> @@ -932,6 +950,8 @@ static void arm_smmu_destroy_domain_context(struct >> iommu_domain *domain) >> free_io_pgtable_ops(smmu_domain->pgtbl_ops); >> __arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx); >> + >> + arm_smmu_rpm_put(smmu); >> } >> static struct iommu_domain *arm_smmu_domain_alloc(unsigned type) >> @@ -1213,10 +1233,15 @@ static int arm_smmu_attach_dev(struct iommu_domain >> *domain, struct device *dev) >> return -ENODEV; >> smmu = fwspec_smmu(fwspec); >> + >> + ret = arm_smmu_rpm_get(smmu); >> + if (ret < 0) >> + return ret; >> + >> /* Ensure that the domain is finalised */ >> ret = arm_smmu_init_domain_context(domain, smmu); >> if (ret < 0) >> - return ret; >> + goto rpm_put; >> /* >> * Sanity check the domain. We don't support domains across >> @@ -1230,29 +1255,47 @@ static int arm_smmu_attach_dev(struct iommu_domain >> *domain, struct device *dev) >> } >> /* Looks ok, so add the device to the domain */ >> - return arm_smmu_domain_add_master(smmu_domain, fwspec); >> + ret = arm_smmu_domain_add_master(smmu_domain, fwspec); >> + >> +rpm_put: >> + arm_smmu_rpm_put(smmu); >> + return ret; >> } >> static int arm_smmu_map(struct iommu_domain *domain, unsigned long >> iova, >> phys_addr_t paddr, size_t size, int prot) >> { >> struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops; >> + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >> + struct arm_smmu_device *smmu = smmu_domain->smmu; > > > Nit: please use arm_smmu_domain for ops as well (as it was before > 523d7423e21b), or consistently elide it for smmu - the mixture of both > methods is just a horrible mess (here and in unmap). > > >> + int ret; >> if (!ops) >> return -ENODEV; >> - return ops->map(ops, iova, paddr, size, prot); >> + arm_smmu_rpm_get(smmu); >> + ret = ops->map(ops, iova, paddr, size, prot); >> + arm_smmu_rpm_put(smmu); >> + >> + return ret; >> } >> static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned >> long iova, >> size_t size) >> { >> struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops; >> + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >> + struct arm_smmu_device *smmu = smmu_domain->smmu; >> + size_t ret; >> if (!ops) >> return 0; >> - return ops->unmap(ops, iova, size); >> + arm_smmu_rpm_get(smmu); >> + ret = ops->unmap(ops, iova, size); >> + arm_smmu_rpm_put(smmu); >> + >> + return ret; >> } >> static void arm_smmu_iotlb_sync(struct iommu_domain *domain) >> @@ -1407,14 +1450,22 @@ static int arm_smmu_add_device(struct device *dev) >> while (i--) >> cfg->smendx[i] = INVALID_SMENDX; >> + ret = arm_smmu_rpm_get(smmu); >> + if (ret < 0) >> + goto out_cfg_free; >> + >> ret = arm_smmu_master_alloc_smes(dev); > > > Nit: it would be easier to just do the rpm_put here; then you don't need to > mess with the cleanup path. > > >> if (ret) >> - goto out_cfg_free; >> + goto out_rpm_put; >> iommu_device_link(&smmu->iommu, dev); >> + arm_smmu_rpm_put(smmu); >> + >> return 0; >> +out_rpm_put: >> + arm_smmu_rpm_put(smmu); >> out_cfg_free: >> kfree(cfg); >> out_free: >> @@ -1427,7 +1478,7 @@ static void arm_smmu_remove_device(struct device >> *dev) >> struct iommu_fwspec *fwspec = dev->iommu_fwspec; >> struct arm_smmu_master_cfg *cfg; >> struct arm_smmu_device *smmu; >> - >> + int ret; >> if (!fwspec || fwspec->ops != &arm_smmu_ops) >> return; >> @@ -1435,8 +1486,15 @@ static void arm_smmu_remove_device(struct device >> *dev) >> cfg = fwspec->iommu_priv; >> smmu = cfg->smmu; >> + ret = arm_smmu_rpm_get(smmu); >> + if (ret < 0) >> + return; >> + >> iommu_device_unlink(&smmu->iommu, dev); >> arm_smmu_master_free_smes(fwspec); >> + >> + arm_smmu_rpm_put(smmu); >> + >> iommu_group_remove_device(dev); >> kfree(fwspec->iommu_priv); >> iommu_fwspec_free(dev); >> @@ -2124,6 +2182,8 @@ static int arm_smmu_device_probe(struct >> platform_device *pdev) >> smmu->irqs[i] = irq; >> } >> + platform_set_drvdata(pdev, smmu); >> + >> err = devm_clk_bulk_get(smmu->dev, smmu->num_clks, smmu->clks); >> if (err) >> return err; >> @@ -2132,6 +2192,19 @@ static int arm_smmu_device_probe(struct >> platform_device *pdev) >> if (err) >> return err; >> + /* >> + * We want to avoid touching dev->power.lock in fastpaths unless >> + * it's really going to do something useful - pm_runtime_enabled() >> + * can serve as an ideal proxy for that decision. So, >> conditionally >> + * enable pm_runtime. >> + */ >> + if (dev->pm_domain) >> + pm_runtime_enable(dev); >> + >> + err = arm_smmu_rpm_get(smmu); >> + if (err < 0) >> + return err; >> + >> err = arm_smmu_device_cfg_probe(smmu); >> if (err) >> return err; >> @@ -2173,10 +2246,11 @@ static int arm_smmu_device_probe(struct >> platform_device *pdev) >> return err; >> } >> - platform_set_drvdata(pdev, smmu); >> arm_smmu_device_reset(smmu); >> arm_smmu_test_smr_masks(smmu); >> + arm_smmu_rpm_put(smmu); >> + >> /* >> * For ACPI and generic DT bindings, an SMMU will be probed before >> * any device which might need it, so we want the bus ops in place >> @@ -2212,8 +2286,13 @@ static int arm_smmu_device_remove(struct >> platform_device *pdev) >> if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS)) >> dev_err(&pdev->dev, "removing device with active >> domains!\n"); >> + arm_smmu_rpm_get(smmu); >> /* Turn the thing off */ >> writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0); >> + arm_smmu_rpm_put(smmu); >> + >> + if (pm_runtime_enabled(smmu->dev)) >> + pm_runtime_disable(smmu->dev); >> clk_bulk_unprepare(smmu->num_clks, smmu->clks); >> > > > I don't know how runtime and system PM interact - does the reset in > arm_smmu_pm_resume need special treatment as well, or is the device > guaranteed to be powered up at that point by other means? Actually, it's quite complicated... 1) device_prepare(), prevents suspending active devices by getting a runtime enable count [1] and then, depending on whether there is a prepare callback that could be called for this device [2] or the device doesn't have any PM callbacks [3], it might set the "direct_complete" flag [4]. 2) Later, when device_suspend() is called, if "direct_complete" is set (and disabling runtime PM ends up with the device still runtime-suspended) [5], the .suspend callback will be skipped. If "direct_complete" is not set (or direct complete fails), the suspend callback (if one exists) would be called regardless of runtime PM state of the device [6]. 3) During system resume, if "direct_complete" was set, the resume callback would be completely skipped [7]. Otherwise it would be called without any special conditions [8]. 4) At the end of the whole process, device_complete() would put the remaining reference count and potentially trigger a runtime idle and suspend, if the device was active. [9] Now, the behavior of what happens past 2) and before 3) is affected by PM domain callbacks, namely prepare, suspend_noirq and resume_noirq. For genpd, genpd_prepare() never returns a positive value, so "direct_complete" would never happen [10]. genpd_finish_suspend() [11], called from genpd_suspend_noirq(), attempts to cut off the power, while genpd_resume_noirq() restore it [12], so it looks like the power would be on during the SMMU resume callback. [1] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L1671 [2] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L1688 [3] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L1683 [4] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L1719 [5] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L1492 [6] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L1506 [7] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L833 [8] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L888 [9] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/main.c#L1012 [10] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/domain.c#L1019 [11] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/domain.c#L1032 [12] https://elixir.bootlin.com/linux/latest/source/drivers/base/power/domain.c#L1085 Phew. This is still with skipped wake up capability handling, since SMMU doesn't have such. Best regards, Tomasz