Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2288642imu; Fri, 23 Nov 2018 07:09:16 -0800 (PST) X-Google-Smtp-Source: AFSGD/X6o5KUC/wn8DH0T4sNZ61YJ9hyvH/gtj8mRBjfN1LhUqqcFOyQ9PY55CjniOGaQk7H1PM9 X-Received: by 2002:a63:fe48:: with SMTP id x8mr14713027pgj.261.1542985756678; Fri, 23 Nov 2018 07:09:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542985756; cv=none; d=google.com; s=arc-20160816; b=zNAJEwu6AcJJ8PUsyQi5DlTBE1+FvWdgUa7M5w1Pk6+nHp//VeMPtBA6Nv+X5viMG7 N+U9wlTQfAM7KjsQNQp3ZI8sD/SKRHHC3AQWMjqZl6F0KZgQ2gIjoM/VAeXA09Pn8Qkr TNnjwyA406utS4KsgSAo1+g1fXAqTzaLClU5FCasS5qf7664PTBI63td+Z3R/Ca6Y2Jm lDv9PPgP2RchQHgjLqTKt4Q1pu4Rst10HE5+9nbQReH4j2J3Huch/I4wtsrI9YG8zunq 8iNKMJxOjgqh4KKmqpXS9nG8dXnOWBAMu9nGPYCjF/vfghAzkQWSkPAJC8LR+FhA+U4U Yn3w== 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=SVxpsV9JqRykPrEUhGcjjS4dHF3BhgoVjS4vNb1k4gs=; b=bvXrr1KUuo1UkOkbq5adg+So4JwLTzGKXG6KFuZbC0mSD78DdWyAYKdWu/OxWyqB3G su1SKXTxwJNH05lY69/j2hnpZ83mt56h1qVFc9ST77+0z5XS5aL7UuXY+63o7d/kPwLq ZUcglewv/yucyv2TbeMhbIpupqfArkKamfSx1kHrazmQdyUlLrccNsnd1QK4p1H59U8C Rz0Xu7FtsSbXKg9xMpZWrClpVZhTkLkM5DevuP1CsTHKbDjaee2mTYKCBdSQUOCX+b/E CEH8twTzKGKE5uC2adQpWovqQp7XNmXBzXkSHHSmNmm4aWe7+fcoVIonhIBqwqlTX8W0 Hp9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=FhLaD3xp; dkim=pass header.i=@codeaurora.org header.s=default header.b=bhrVgwiJ; 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 g22si46123813pfj.222.2018.11.23.07.08.34; Fri, 23 Nov 2018 07:09:16 -0800 (PST) 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=FhLaD3xp; dkim=pass header.i=@codeaurora.org header.s=default header.b=bhrVgwiJ; 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 S2436586AbeKVWlr (ORCPT + 99 others); Thu, 22 Nov 2018 17:41:47 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:52034 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730337AbeKVWlr (ORCPT ); Thu, 22 Nov 2018 17:41:47 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id F141360710; Thu, 22 Nov 2018 12:02:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1542888161; bh=gmZwPK792OsEBQCLpAfUmDtrynLU/JgtlXthlx+rVnA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FhLaD3xptDI0Ox/F9T2T8f1Hj/dTKrrrveKVcr8Ro0JkBtbiqhBCSISgrGgW2OHj9 9iRyM7HM0DUQB1O0vfi1gtLg3jYZkHD/WKVToMyCM2M9J/CysZ5t+7mAfy3Au2xHA9 GI5iebdhH6KU1C5U78M9L9xAjOztJOw9v1BI6OKw= 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-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (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 B3132607B5; Thu, 22 Nov 2018 12:02:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1542888159; bh=gmZwPK792OsEBQCLpAfUmDtrynLU/JgtlXthlx+rVnA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=bhrVgwiJ1OHG3i2jj9f2nW9uDlNqzlhSv97pTgJFYxZSCgR4ZlO1mHsLttaKnYRo6 7Ax3q1v5YVF6MFgHdDnPZetehfpSvj88pp6wMx5evN8Zqvrqq7H4ZKJHElTaskWxxY YiVTdVcxrKNAyA2THvGelPyCYoyVMotzFiYR+u7w= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org B3132607B5 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-f169.google.com with SMTP id n21so7154640qtl.6; Thu, 22 Nov 2018 04:02:38 -0800 (PST) X-Gm-Message-State: AGRZ1gLqTAuZ05mv5HepWnleop74dJHZca+xxMCLcn/c8vO32ZGFLHcq I51m6TXd8HY1d9R1pwLpta6pWI1uqaGYtgEkXiw= X-Received: by 2002:ac8:7353:: with SMTP id q19mr9514802qtp.265.1542888157373; Thu, 22 Nov 2018 04:02:37 -0800 (PST) MIME-Version: 1.0 References: <20181116112430.31248-1-vivek.gautam@codeaurora.org> <20181116112430.31248-3-vivek.gautam@codeaurora.org> <20181121173757.GA9801@arm.com> In-Reply-To: <20181121173757.GA9801@arm.com> From: Vivek Gautam Date: Thu, 22 Nov 2018 17:32:24 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RESEND PATCH v17 2/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device To: Will Deacon Cc: Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , alex.williamson@redhat.com, Linux PM , sboyd@kernel.org, freedreno , "Rafael J. Wysocki" , open list , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , "robh+dt" , linux-arm-msm , 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 Hi Will, On Wed, Nov 21, 2018 at 11:09 PM Will Deacon wrote: > > On Fri, Nov 16, 2018 at 04:54:27PM +0530, 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. > > Global locks are also initialized before enabling runtime pm as the > > runtime_resume() calls device_reset() which does tlb_sync_global() > > that ultimately requires locks to be initialized. > > > > Signed-off-by: Sricharan R > > [vivek: Cleanup pm runtime calls] > > Signed-off-by: Vivek Gautam > > Reviewed-by: Tomasz Figa > > Tested-by: Srinivas Kandagatla > > Reviewed-by: Robin Murphy > > --- > > drivers/iommu/arm-smmu.c | 101 ++++++++++++++++++++++++++++++++++++++++++----- > > 1 file changed, 91 insertions(+), 10 deletions(-) > > Given that you're doing the get/put in the TLBI ops unconditionally: > > > static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain) > > { > > struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); > > + struct arm_smmu_device *smmu = smmu_domain->smmu; > > > > - if (smmu_domain->tlb_ops) > > + if (smmu_domain->tlb_ops) { > > + arm_smmu_rpm_get(smmu); > > smmu_domain->tlb_ops->tlb_flush_all(smmu_domain); > > + arm_smmu_rpm_put(smmu); > > + } > > } > > > > static void arm_smmu_iotlb_sync(struct iommu_domain *domain) > > { > > struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); > > + struct arm_smmu_device *smmu = smmu_domain->smmu; > > > > - if (smmu_domain->tlb_ops) > > + if (smmu_domain->tlb_ops) { > > + arm_smmu_rpm_get(smmu); > > smmu_domain->tlb_ops->tlb_sync(smmu_domain); > > + arm_smmu_rpm_put(smmu); > > + } > > Why do you need them around the map/unmap calls as well? We still have .tlb_add_flush path? Thanks Vivek > > Will > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation