Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp346958imm; Wed, 11 Jul 2018 03:37:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc4vkhh7p8AW0t/gwVq1ZNeM5dogROwy452MadBlo2d50NsOcZcr6PvY9kB878zm4hAM9qb X-Received: by 2002:a63:b047:: with SMTP id z7-v6mr26338977pgo.335.1531305432803; Wed, 11 Jul 2018 03:37:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531305432; cv=none; d=google.com; s=arc-20160816; b=NIauOzWeXSHAIv+ZM8fIxklfCPt/RIEh8PUxrkDXZRS/8GwrtvHapURWfqOZsQAvTP GKjHySzBLmodlVIkYCBuVO0K0EHJMuHnNGMuOnJLaFQSSzVJX1coBlH/l/Dm5H0nG6VU B+SUn1dsS1VtqmRfZYSPuxqNNcrdFN0iEmYn+uqPi30d7NlCbvKRZlGXizLUXeK/oJeH 5Oxv97Xg7H1+egw2lfboTudCurn5dvVbgQa505Th/FiN50cx9mL2PpPoQMbgy1XM8SKv gJ4oLoG21kdwMUcOEkFxt1CdrqPGJWrBGN4s9+QgQMeQ0DUGH34xifE+tUUXfpn0HFal 8fuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=wkolS9PHFUuicPNXDkxNzL+mFuowUNrEERw2G61reOM=; b=csam08j2yNjI0fQW1R7jo8SjlII3CpIepuj5LtyV6f47GIU1dHJ6S1G5NN/FT/GB7B KvrW/IN1mn7m3sdkLTjllFIh30j4aZkue7IdFJBOOO14zn0vrYa9Iyse3PjP7zlO0RMx nf5O4Eav9fokumXBCN0/2mwb3+3UmzmWMFl5T7vId6qLwbHTsQlI5qDtG+zR8lPlABXx 2z0mp7lLxKShZP1JzeEHI+cPytKIA8g2Jf9+vPlWZooTxh5wWQDe+6+dGLydpXJvsiK+ yReZ+zjUtpsjcIPYh238JIBd6Qd8ENwS518cetSDdsQwALagr8MG/etixz3meujBYjD/ E+ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=WpXHsceS; dkim=pass header.i=@codeaurora.org header.s=default header.b=TfPPoEUd; 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 q28-v6si11501641pgm.362.2018.07.11.03.36.57; Wed, 11 Jul 2018 03:37:12 -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=WpXHsceS; dkim=pass header.i=@codeaurora.org header.s=default header.b=TfPPoEUd; 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 S1726835AbeGKKkC (ORCPT + 99 others); Wed, 11 Jul 2018 06:40:02 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:49630 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726460AbeGKKkC (ORCPT ); Wed, 11 Jul 2018 06:40:02 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 851C660591; Wed, 11 Jul 2018 10:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1531305381; bh=B0AoWLUHxbP27BimviinUWlX+aoQV9JEDiBNdGGYtWc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WpXHsceSZK7SC5E8rthLg+pam7J/wr0nVrAoXh275R4XvHqQSL9KMnhn8C+kYv3BR FnA7zzsD3/G4TFAhQ0XIiLTaqLohajOeRz7fmv8GBdyFbRN99VerRG2IMSR39WOKXj r+FzHBZF9a53HowR7MD3vMAE+0yCJOheRYfwfKd0= 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.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.79.40.147] (blr-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.18.19]) (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 726386078C; Wed, 11 Jul 2018 10:36:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1531305380; bh=B0AoWLUHxbP27BimviinUWlX+aoQV9JEDiBNdGGYtWc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TfPPoEUd+uGlFDNZKLvfcgtM1pC3MOLLlQYucjDG0XjBXNLu2pMBJy5GnXVgusHm8 C9mBCYcM1gusEAqWwE2Ud78fdxeOU2KkVDQmaP/wcuMy3O1XFAK0mk3r/+gK44Dsvr t1Ag97/iGx7eXlp6B26MZz26J3AMtizwtrR4Ghjs= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 726386078C 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 Subject: Re: [PATCH v12 3/4] iommu/arm-smmu: Add the device_link between masters and smmu To: "Rafael J. Wysocki" Cc: joro@8bytes.org, robh+dt@kernel.org, mark.rutland@arm.com, robin.murphy@arm.com, will.deacon@arm.com, iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, alex.williamson@redhat.com, robdclark@gmail.com, linux-pm@vger.kernel.org, freedreno@lists.freedesktop.org, sboyd@kernel.org, tfiga@chromium.org, sricharan@codeaurora.org, m.szyprowski@samsung.com, architt@codeaurora.org, linux-arm-msm@vger.kernel.org, jcrouse@codeaurora.org, Lukas Wunner References: <20180708173413.1965-1-vivek.gautam@codeaurora.org> <20180708173413.1965-4-vivek.gautam@codeaurora.org> <5179668.PHK6S3sxLu@aspire.rjw.lan> From: Vivek Gautam Message-ID: <741cc78b-59a7-5289-e42f-1511ebedb15d@codeaurora.org> Date: Wed, 11 Jul 2018 16:06:14 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5179668.PHK6S3sxLu@aspire.rjw.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rafael, On 7/11/2018 3:23 PM, Rafael J. Wysocki wrote: > On Sunday, July 8, 2018 7:34:12 PM CEST Vivek Gautam wrote: >> From: Sricharan R >> >> Finally add the device link between the master device and >> smmu, so that the smmu gets runtime enabled/disabled only when the >> master needs it. This is done from add_device callback which gets >> called once when the master is added to the smmu. >> >> Signed-off-by: Sricharan R >> Signed-off-by: Vivek Gautam >> Reviewed-by: Tomasz Figa >> Cc: Rafael J. Wysocki >> Cc: Lukas Wunner >> --- >> >> - Change since v11 >> * Replaced DL_FLAG_AUTOREMOVE flag with DL_FLAG_AUTOREMOVE_SUPPLIER. >> >> drivers/iommu/arm-smmu.c | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) >> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c >> index 09265e206e2d..916cde4954d2 100644 >> --- a/drivers/iommu/arm-smmu.c >> +++ b/drivers/iommu/arm-smmu.c >> @@ -1461,8 +1461,20 @@ static int arm_smmu_add_device(struct device *dev) >> >> iommu_device_link(&smmu->iommu, dev); >> >> + if (pm_runtime_enabled(smmu->dev) && > Why does the creation of the link depend on whether or not runtime PM > is enabled for the MMU device? The main purpose of this device link is to handle the runtime PM synchronization between the supplier (iommu) and consumer (client devices, such as GPU/display). Moreover, the runtime pm is conditionally enabled for smmu devices that support such [1]. > > What about system-wide PM and system shutdown? Are they always guaranteed > to happen in the right order without the link? When there's no runtime PM, there's no clocks, and other resources to be handled. So, we don't need device link for system-wide PM and system shutdown to work correctly. That's the case with current arm-smmu driver. Is it something that i am missing here? [1] https://lkml.org/lkml/2018/3/8/775 Thanks Vivek >> + !device_link_add(dev, smmu->dev, >> + DL_FLAG_PM_RUNTIME | DL_FLAG_AUTOREMOVE_SUPPLIER)) { >> + dev_err(smmu->dev, "Unable to add link to the consumer %s\n", >> + dev_name(dev)); >> + ret = -ENODEV; >> + goto out_unlink; >> + } >> + >> return 0; >> >> +out_unlink: >> + iommu_device_unlink(&smmu->iommu, dev); >> + arm_smmu_master_free_smes(fwspec); >> out_cfg_free: >> kfree(cfg); >> out_free: >> >