From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [RESEND PATCH v17 2/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device Date: Wed, 21 Nov 2018 17:37:57 +0000 Message-ID: <20181121173757.GA9801@arm.com> References: <20181116112430.31248-1-vivek.gautam@codeaurora.org> <20181116112430.31248-3-vivek.gautam@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <20181116112430.31248-3-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: freedreno-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "Freedreno" To: Vivek Gautam Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sboyd-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org, rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, robin.murphy-5wv7dgnIgG8@public.gmane.org, m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org List-Id: linux-arm-msm@vger.kernel.org T24gRnJpLCBOb3YgMTYsIDIwMTggYXQgMDQ6NTQ6MjdQTSArMDUzMCwgVml2ZWsgR2F1dGFtIHdy b3RlOgo+IEZyb206IFNyaWNoYXJhbiBSIDxzcmljaGFyYW5AY29kZWF1cm9yYS5vcmc+Cj4gCj4g VGhlIHNtbXUgZGV2aWNlIHByb2JlL3JlbW92ZSBhbmQgYWRkL3JlbW92ZSBtYXN0ZXIgZGV2aWNl IGNhbGxiYWNrcwo+IGdldHMgY2FsbGVkIHdoZW4gdGhlIHNtbXUgaXMgbm90IGxpbmtlZCB0byBp dHMgbWFzdGVyLCB0aGF0IGlzIHdpdGhvdXQKPiB0aGUgY29udGV4dCBvZiB0aGUgbWFzdGVyIGRl dmljZS4gU28gY2FsbGluZyBydW50aW1lIGFwaXMgaW4gdGhvc2UgcGxhY2VzCj4gc2VwYXJhdGVs eS4KPiBHbG9iYWwgbG9ja3MgYXJlIGFsc28gaW5pdGlhbGl6ZWQgYmVmb3JlIGVuYWJsaW5nIHJ1 bnRpbWUgcG0gYXMgdGhlCj4gcnVudGltZV9yZXN1bWUoKSBjYWxscyBkZXZpY2VfcmVzZXQoKSB3 aGljaCBkb2VzIHRsYl9zeW5jX2dsb2JhbCgpCj4gdGhhdCB1bHRpbWF0ZWx5IHJlcXVpcmVzIGxv Y2tzIHRvIGJlIGluaXRpYWxpemVkLgo+IAo+IFNpZ25lZC1vZmYtYnk6IFNyaWNoYXJhbiBSIDxz cmljaGFyYW5AY29kZWF1cm9yYS5vcmc+Cj4gW3ZpdmVrOiBDbGVhbnVwIHBtIHJ1bnRpbWUgY2Fs bHNdCj4gU2lnbmVkLW9mZi1ieTogVml2ZWsgR2F1dGFtIDx2aXZlay5nYXV0YW1AY29kZWF1cm9y YS5vcmc+Cj4gUmV2aWV3ZWQtYnk6IFRvbWFzeiBGaWdhIDx0ZmlnYUBjaHJvbWl1bS5vcmc+Cj4g VGVzdGVkLWJ5OiBTcmluaXZhcyBLYW5kYWdhdGxhIDxzcmluaXZhcy5rYW5kYWdhdGxhQGxpbmFy by5vcmc+Cj4gUmV2aWV3ZWQtYnk6IFJvYmluIE11cnBoeSA8cm9iaW4ubXVycGh5QGFybS5jb20+ Cj4gLS0tCj4gIGRyaXZlcnMvaW9tbXUvYXJtLXNtbXUuYyB8IDEwMSArKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLQo+ICAxIGZpbGUgY2hhbmdlZCwgOTEgaW5z ZXJ0aW9ucygrKSwgMTAgZGVsZXRpb25zKC0pCgpHaXZlbiB0aGF0IHlvdSdyZSBkb2luZyB0aGUg Z2V0L3B1dCBpbiB0aGUgVExCSSBvcHMgdW5jb25kaXRpb25hbGx5OgoKPiAgc3RhdGljIHZvaWQg YXJtX3NtbXVfZmx1c2hfaW90bGJfYWxsKHN0cnVjdCBpb21tdV9kb21haW4gKmRvbWFpbikKPiAg ewo+ICAJc3RydWN0IGFybV9zbW11X2RvbWFpbiAqc21tdV9kb21haW4gPSB0b19zbW11X2RvbWFp bihkb21haW4pOwo+ICsJc3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSA9IHNtbXVfZG9tYWlu LT5zbW11Owo+ICAKPiAtCWlmIChzbW11X2RvbWFpbi0+dGxiX29wcykKPiArCWlmIChzbW11X2Rv bWFpbi0+dGxiX29wcykgewo+ICsJCWFybV9zbW11X3JwbV9nZXQoc21tdSk7Cj4gIAkJc21tdV9k b21haW4tPnRsYl9vcHMtPnRsYl9mbHVzaF9hbGwoc21tdV9kb21haW4pOwo+ICsJCWFybV9zbW11 X3JwbV9wdXQoc21tdSk7Cj4gKwl9Cj4gIH0KPiAgCj4gIHN0YXRpYyB2b2lkIGFybV9zbW11X2lv dGxiX3N5bmMoc3RydWN0IGlvbW11X2RvbWFpbiAqZG9tYWluKQo+ICB7Cj4gIAlzdHJ1Y3QgYXJt X3NtbXVfZG9tYWluICpzbW11X2RvbWFpbiA9IHRvX3NtbXVfZG9tYWluKGRvbWFpbik7Cj4gKwlz dHJ1Y3QgYXJtX3NtbXVfZGV2aWNlICpzbW11ID0gc21tdV9kb21haW4tPnNtbXU7Cj4gIAo+IC0J aWYgKHNtbXVfZG9tYWluLT50bGJfb3BzKQo+ICsJaWYgKHNtbXVfZG9tYWluLT50bGJfb3BzKSB7 Cj4gKwkJYXJtX3NtbXVfcnBtX2dldChzbW11KTsKPiAgCQlzbW11X2RvbWFpbi0+dGxiX29wcy0+ dGxiX3N5bmMoc21tdV9kb21haW4pOwo+ICsJCWFybV9zbW11X3JwbV9wdXQoc21tdSk7Cj4gKwl9 CgpXaHkgZG8geW91IG5lZWQgdGhlbSBhcm91bmQgdGhlIG1hcC91bm1hcCBjYWxscyBhcyB3ZWxs PwoKV2lsbApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpG cmVlZHJlbm8gbWFpbGluZyBsaXN0CkZyZWVkcmVub0BsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0 cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlZHJlbm8K From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E470C43441 for ; Wed, 21 Nov 2018 17:37:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4C9112151B for ; Wed, 21 Nov 2018 17:37:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C9112151B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732342AbeKVENC (ORCPT ); Wed, 21 Nov 2018 23:13:02 -0500 Received: from foss.arm.com ([217.140.101.70]:55836 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727787AbeKVENC (ORCPT ); Wed, 21 Nov 2018 23:13:02 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 73FC33616; Wed, 21 Nov 2018 09:37:42 -0800 (PST) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 42D1D3F5AF; Wed, 21 Nov 2018 09:37:42 -0800 (PST) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 05FF51AE100A; Wed, 21 Nov 2018 17:37:57 +0000 (GMT) Date: Wed, 21 Nov 2018 17:37:57 +0000 From: Will Deacon To: Vivek Gautam Cc: joro@8bytes.org, robh+dt@kernel.org, robin.murphy@arm.com, iommu@lists.linux-foundation.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, alex.williamson@redhat.com, mark.rutland@arm.com, rjw@rjwysocki.net, robdclark@gmail.com, linux-pm@vger.kernel.org, freedreno@lists.freedesktop.org, sboyd@kernel.org, tfiga@chromium.org, jcrouse@codeaurora.org, sricharan@codeaurora.org, m.szyprowski@samsung.com, architt@codeaurora.org, linux-arm-msm@vger.kernel.org Subject: Re: [RESEND PATCH v17 2/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device Message-ID: <20181121173757.GA9801@arm.com> References: <20181116112430.31248-1-vivek.gautam@codeaurora.org> <20181116112430.31248-3-vivek.gautam@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181116112430.31248-3-vivek.gautam@codeaurora.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Will