From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Hansson Subject: Re: [PATCH v16 1/5] iommu/arm-smmu: Add pm_runtime/sleep ops Date: Mon, 1 Oct 2018 11:38:02 +0200 Message-ID: References: <20180830144541.17740-1-vivek.gautam@codeaurora.org> <20180830144541.17740-2-vivek.gautam@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: 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 , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux PM , Stephen Boyd , Will Deacon , "Rafael J. Wysocki" , open list , "list-Y9sIeH5OGRo@public.gmane.org:IOMMU DRIVERS , Joerg Roedel , " , Alex Williamson , robh+dt , linux-arm-msm , freedreno , Robin Murphy List-Id: linux-arm-msm@vger.kernel.org T24gMSBPY3RvYmVyIDIwMTggYXQgMDc6NDksIFZpdmVrIEdhdXRhbSA8dml2ZWsuZ2F1dGFtQGNv ZGVhdXJvcmEub3JnPiB3cm90ZToKPiBISSBVbGYsCj4KPiBPbiBGcmksIFNlcCAyOCwgMjAxOCBh dCA1OjMwIFBNIFVsZiBIYW5zc29uIDx1bGYuaGFuc3NvbkBsaW5hcm8ub3JnPiB3cm90ZToKPj4K Pj4gT24gMzAgQXVndXN0IDIwMTggYXQgMTY6NDUsIFZpdmVrIEdhdXRhbSA8dml2ZWsuZ2F1dGFt QGNvZGVhdXJvcmEub3JnPiB3cm90ZToKPj4gPiBGcm9tOiBTcmljaGFyYW4gUiA8c3JpY2hhcmFu QGNvZGVhdXJvcmEub3JnPgo+PiA+Cj4+ID4gVGhlIHNtbXUgbmVlZHMgdG8gYmUgZnVuY3Rpb25h bCBvbmx5IHdoZW4gdGhlIHJlc3BlY3RpdmUKPj4gPiBtYXN0ZXIncyB1c2luZyBpdCBhcmUgYWN0 aXZlLiBUaGUgZGV2aWNlX2xpbmsgZmVhdHVyZQo+PiA+IGhlbHBzIHRvIHRyYWNrIHN1Y2ggZnVu Y3Rpb25hbCBkZXBlbmRlbmNpZXMsIHNvIHRoYXQgdGhlCj4+ID4gaW9tbXUgZ2V0cyBwb3dlcmVk IHdoZW4gdGhlIG1hc3RlciBkZXZpY2UgZW5hYmxlcyBpdHNlbGYKPj4gPiB1c2luZyBwbV9ydW50 aW1lLiBTbyBieSBhZGFwdGluZyB0aGUgc21tdSBkcml2ZXIgZm9yCj4+ID4gcnVudGltZSBwbSwg YWJvdmUgc2FpZCBkZXBlbmRlbmN5IGNhbiBiZSBhZGRyZXNzZWQuCj4+ID4KPj4gPiBUaGlzIHBh dGNoIGFkZHMgdGhlIHBtIHJ1bnRpbWUvc2xlZXAgY2FsbGJhY2tzIHRvIHRoZQo+PiA+IGRyaXZl ciBhbmQgYWxzbyB0aGUgZnVuY3Rpb25zIHRvIHBhcnNlIHRoZSBzbW11IGNsb2Nrcwo+PiA+IGZy b20gRFQgYW5kIGVuYWJsZSB0aGVtIGluIHJlc3VtZS9zdXNwZW5kLgo+PiA+Cj4+ID4gQWxzbywg d2hpbGUgd2UgZW5hYmxlIHRoZSBydW50aW1lIHBtIGFkZCBhIHBtIHNsZWVwIHN1c3BlbmQKPj4g PiBjYWxsYmFjayB0aGF0IHB1c2hlcyBkZXZpY2VzIHRvIGxvdyBwb3dlciBzdGF0ZSBieSB0dXJu aW5nCj4+ID4gdGhlIGNsb2NrcyBvZmYgaW4gYSBzeXN0ZW0gc2xlZXAuCj4+ID4gQWxzbyBhZGQg Y29ycmVzcG9uZGluZyBjbG9jayBlbmFibGUgcGF0aCBpbiByZXN1bWUgY2FsbGJhY2suCj4+ID4K Pj4gPiBTaWduZWQtb2ZmLWJ5OiBTcmljaGFyYW4gUiA8c3JpY2hhcmFuQGNvZGVhdXJvcmEub3Jn Pgo+PiA+IFNpZ25lZC1vZmYtYnk6IEFyY2hpdCBUYW5lamEgPGFyY2hpdHRAY29kZWF1cm9yYS5v cmc+Cj4+ID4gW3ZpdmVrOiByZXdvcmsgZm9yIGNsb2NrIGFuZCBwbSBvcHNdCj4+ID4gU2lnbmVk LW9mZi1ieTogVml2ZWsgR2F1dGFtIDx2aXZlay5nYXV0YW1AY29kZWF1cm9yYS5vcmc+Cj4+ID4g UmV2aWV3ZWQtYnk6IFRvbWFzeiBGaWdhIDx0ZmlnYUBjaHJvbWl1bS5vcmc+Cj4+ID4gVGVzdGVk LWJ5OiBTcmluaXZhcyBLYW5kYWdhdGxhIDxzcmluaXZhcy5rYW5kYWdhdGxhQGxpbmFyby5vcmc+ Cj4+ID4gLS0tCj4+ID4gIGRyaXZlcnMvaW9tbXUvYXJtLXNtbXUuYyB8IDc3ICsrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLQo+PiA+ICAxIGZpbGUgY2hhbmdl ZCwgNzQgaW5zZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkKPj4gPiBkaWZmIC0tZ2l0IGEvZHJp dmVycy9pb21tdS9hcm0tc21tdS5jIGIvZHJpdmVycy9pb21tdS9hcm0tc21tdS5jCj4+Cj4+IFsu Li5dCj4+Cj4+ID4gLXN0YXRpYyBpbnQgX19tYXliZV91bnVzZWQgYXJtX3NtbXVfcG1fcmVzdW1l KHN0cnVjdCBkZXZpY2UgKmRldikKPj4gPiArc3RhdGljIGludCBfX21heWJlX3VudXNlZCBhcm1f c21tdV9ydW50aW1lX3Jlc3VtZShzdHJ1Y3QgZGV2aWNlICpkZXYpCj4+ID4gIHsKPj4gPiAgICAg ICAgIHN0cnVjdCBhcm1fc21tdV9kZXZpY2UgKnNtbXUgPSBkZXZfZ2V0X2RydmRhdGEoZGV2KTsK Pj4gPiArICAgICAgIGludCByZXQ7Cj4+ID4gKwo+PiA+ICsgICAgICAgcmV0ID0gY2xrX2J1bGtf ZW5hYmxlKHNtbXUtPm51bV9jbGtzLCBzbW11LT5jbGtzKTsKPj4gPiArICAgICAgIGlmIChyZXQp Cj4+ID4gKyAgICAgICAgICAgICAgIHJldHVybiByZXQ7Cj4+ID4KPj4gPiAgICAgICAgIGFybV9z bW11X2RldmljZV9yZXNldChzbW11KTsKPj4gPiArCj4+ID4gICAgICAgICByZXR1cm4gMDsKPj4g PiAgfQo+PiA+Cj4+ID4gLXN0YXRpYyBTSU1QTEVfREVWX1BNX09QUyhhcm1fc21tdV9wbV9vcHMs IE5VTEwsIGFybV9zbW11X3BtX3Jlc3VtZSk7Cj4+ID4gK3N0YXRpYyBpbnQgX19tYXliZV91bnVz ZWQgYXJtX3NtbXVfcnVudGltZV9zdXNwZW5kKHN0cnVjdCBkZXZpY2UgKmRldikKPj4gPiArewo+ PiA+ICsgICAgICAgc3RydWN0IGFybV9zbW11X2RldmljZSAqc21tdSA9IGRldl9nZXRfZHJ2ZGF0 YShkZXYpOwo+PiA+ICsKPj4gPiArICAgICAgIGNsa19idWxrX2Rpc2FibGUoc21tdS0+bnVtX2Ns a3MsIHNtbXUtPmNsa3MpOwo+PiA+ICsKPj4gPiArICAgICAgIHJldHVybiAwOwo+PiA+ICt9Cj4+ ID4gKwo+PiA+ICtzdGF0aWMgaW50IF9fbWF5YmVfdW51c2VkIGFybV9zbW11X3BtX3Jlc3VtZShz dHJ1Y3QgZGV2aWNlICpkZXYpCj4+ID4gK3sKPj4gPiArICAgICAgIGlmIChwbV9ydW50aW1lX3N1 c3BlbmRlZChkZXYpKQo+PiA+ICsgICAgICAgICAgICAgICByZXR1cm4gMDsKPj4KPj4gTG9va3Mg bGlrZSB5b3Ugc2hvdWxkIGJlIGFibGUgdXNlIHBtX3J1bnRpbWVfZm9yY2VfcmVzdW1lKCksIGlu c3RlYWQKPj4gb2YgdXNpbmcgdGhpcyBsb2NhbCB0cmljay4gVW5sZXNzIEkgYW0gbWlzc2luZyBz b21ldGhpbmcsIG9mIGNvdXJzZS4KPj4KPj4gSW4gb3RoZXIgd29yZHMsIGp1c3QgYXNzaWduIHRo ZSBzeXN0ZW0gc2xlZXAgY2FsbGJhY2tzIGZvciByZXN1bWUsIHRvCj4+IHBtX3J1bnRpbWVfZm9y Y2VfcmVzdW1lKCkuIEFuZCB2aWNlIHZlcnNlIGZvciB0aGUgc3lzdGVtIHN1c3BlbmQKPj4gY2Fs bGJhY2tzLCBwbV9ydW50aW1lX2ZvcmNlX3N1c3BlbmQoKSwgb2YgY291cnNlLgo+Cj4gVGhhbmtz IGZvciB0aGUgcmV2aWV3LiBJIHdpbGwgY2hhbmdlIHRoaXMgYXMgc3VnZ2VzdGVkLgo+Cj4+Cj4+ ID4gKwo+PiA+ICsgICAgICAgcmV0dXJuIGFybV9zbW11X3J1bnRpbWVfcmVzdW1lKGRldik7Cj4+ ID4gK30KPj4gPiArCj4+ID4gK3N0YXRpYyBpbnQgX19tYXliZV91bnVzZWQgYXJtX3NtbXVfcG1f c3VzcGVuZChzdHJ1Y3QgZGV2aWNlICpkZXYpCj4+ID4gK3sKPj4gPiArICAgICAgIGlmIChwbV9y dW50aW1lX3N1c3BlbmRlZChkZXYpKQo+PiA+ICsgICAgICAgICAgICAgICByZXR1cm4gMDsKPj4g PiArCj4+ID4gKyAgICAgICByZXR1cm4gYXJtX3NtbXVfcnVudGltZV9zdXNwZW5kKGRldik7Cj4+ ID4gK30KPj4gPiArCj4+ID4gK3N0YXRpYyBjb25zdCBzdHJ1Y3QgZGV2X3BtX29wcyBhcm1fc21t dV9wbV9vcHMgPSB7Cj4+ID4gKyAgICAgICBTRVRfU1lTVEVNX1NMRUVQX1BNX09QUyhhcm1fc21t dV9wbV9zdXNwZW5kLCBhcm1fc21tdV9wbV9yZXN1bWUpCj4+Cj4+IEkgYW0gd29uZGVyaW5nIGlm IHVzaW5nIHRoZSAtPnN1c3BlbmR8cmVzdW1lKCkgY2FsbGJhY2sgaXMgcmVhbGx5Cj4+ICJsYXRl L2Vhcmx5IiBlbm91Z2ggaW4gdGhlIGRldmljZSBzdXNwZW5kIHBoYXNlPwo+Pgo+PiBPdGhlcnMg aXMgdXNpbmcgdGhlIG5vaXJxIHBoYXNlIGFuZCBzb21lIGlzIGV2ZW4gdXNpbmcgdGhlIHN5c2Nv cmUKPj4gb3BzLiBPZiBjb3Vyc2UgaXQgZGVwZW5kcyBvbiB0aGUgYmVoYXZpb3Igb2YgdGhlIGNv bnN1bWVycyBvZiBpb21tdQo+PiBkZXZpY2UsIGFuZCBJIGd1ZXNzIG5vdCBldmVyeW9uZSBpcyB1 c2luZyBkZXZpY2UgbGlua3MsIHdoaWNoIGZvciBzdXJlCj4+IGltcHJvdmVzIHRoaW5ncyBpbiB0 aGlzIHJlZ2FyZHMgYXMgd2VsbC4KPgo+IFdlbGwgeWVzLCBhcyB5b3Ugc2FpZCB0aGUgZGV2aWNl IGxpbmtzIHNob3VsZCBiZSBhYmxlIHRvIHRha2UgY2FyZSBvZgo+IG1haW50YWluaW5nIHRoZSBj b3JyZWN0IHN1c3BlbmQvcmVzdW1lIG9yZGVyIG9mIHNtbXUgYW5kIGl0cyBjbGllbnRzLAo+IG9y IGFtIEkgbWlzc2luZyB5b3VyIHBvaW50IGhlcmU/Cj4gTGV0IG1lIGtub3cgYW5kIEkgd2lsbCBi ZSBoYXBweSB0byBpbmNvcnBvcmF0ZSBhbnkgc3VnZ2VzdGlvbnMuCj4gVGhhbmtzCgpJZiBpdCB3 b3JrcyBmaW5lLCB0aGVuIHlvdSBtYXkga2VlcCBpdCBhcyBpcy4KCkp1c3Qgd2FudGVkIHRvIHBv aW50IG91dCB0aGF0IGlmIGFueSBjb25zdW1lcnMgcmVsaWVzIG9uIHRoZSBpb21tdSB0bwpvcGVy YXRpb25hbCB0byBzYXkgdW50aWwgdGhlIHN1c3BlbmQtbGF0ZSBwaGFzZSwgdGhlbiB0aGlzIGRv ZXNuJ3QKcGxheS4gVGhlbiB5b3UgbmVlZCB0byBtb3ZlIHlvdXIgY2FsbGJhY2tzIHRvIHRoZSBj b3JyZXNwb25kaW5nIHNhbWUKcGhhc2UuCgpbLi4uXQoKS2luZCByZWdhcmRzClVmZmUKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRnJlZWRyZW5vIG1haWxp bmcgbGlzdApGcmVlZHJlbm9AbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJl ZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWRyZW5vCg== 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=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED 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 4E1E1C43143 for ; Mon, 1 Oct 2018 09:38:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CF6AA2084C for ; Mon, 1 Oct 2018 09:38:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linaro.org header.i=@linaro.org header.b="Uwb+w+Pu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF6AA2084C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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 S1729133AbeJAQPi (ORCPT ); Mon, 1 Oct 2018 12:15:38 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:41215 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726648AbeJAQPh (ORCPT ); Mon, 1 Oct 2018 12:15:37 -0400 Received: by mail-io1-f67.google.com with SMTP id q4-v6so8829519iob.8 for ; Mon, 01 Oct 2018 02:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xanetU4/5HagGtkISNZ1t3wsrG5htnWymXlhbIcV6OU=; b=Uwb+w+Pu2Dz6M0puLAQW6acp+Dta9W8zMzVenK2F7svafrJnj7l/F1CRP83GNB3GZH 34U2JMPjABVjoi1lMh735gC955YDyxsFmViQmgKN/Z09xE06e8MClThJF5iLazH/yezc 3aUhjZ9XIulz6h9XURQa7pTCdZVK9a7dq9XhI= 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=xanetU4/5HagGtkISNZ1t3wsrG5htnWymXlhbIcV6OU=; b=Xm+GvdTbuLyRQo3MDs+ESxuBlDL2WOgf8r7yx1gQI6v9PbOW9ELufdL/euix5eEtIf IV9vPpWlPktEXe6ZDV2NExzRAcjAUU6XM2ZZHNov39MAw/1lB0Fmmtt6mQe7AMry0FOL e8y6bwUW7+UBa4KjWLcketpzXjCHEr+t6A2tVzyNCiRLZRGptzMbbJWmOcgQidSj2WYk 0wXbSYvLPFSk582CsZzUXD3ZWGuLqkYOyU/Qvvq6wIlP0o10upKBBjRhJa2uF1QCCMpg DY1wC2HpHRUczeRr8qqzf696f94IMbaUEDEpeI3Rc97tzb953CQcMHdJk10iY7ODQ6kA Vs8w== X-Gm-Message-State: ABuFfoi59t3/U9BPyfXbI8KBxl6rNHk8LiFdWT0c9SleK8Ry7+4MAKtK sKvKX0WZ7Z5hV5aMaDuZxPN63BP9nYxa4gHYXlCUpA== X-Google-Smtp-Source: ACcGV63hLu33zNZ5nULLepf4/xdvOl/1FOK9Ibv42hmiRbUTWwg47MkVRvdahyUQRkgWX0AXEtQLVWnLtnnMfHWSgIU= X-Received: by 2002:a6b:203:: with SMTP id 3-v6mr6172975ioc.131.1538386723079; Mon, 01 Oct 2018 02:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:3941:0:0:0:0:0 with HTTP; Mon, 1 Oct 2018 02:38:02 -0700 (PDT) In-Reply-To: References: <20180830144541.17740-1-vivek.gautam@codeaurora.org> <20180830144541.17740-2-vivek.gautam@codeaurora.org> From: Ulf Hansson Date: Mon, 1 Oct 2018 11:38:02 +0200 Message-ID: Subject: Re: [PATCH v16 1/5] iommu/arm-smmu: Add pm_runtime/sleep ops To: Vivek Gautam Cc: Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Alex Williamson , Linux PM , Stephen Boyd , "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 1 October 2018 at 07:49, 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. > >> >> > + >> > + return arm_smmu_runtime_resume(dev); >> > +} >> > + >> > +static int __maybe_unused arm_smmu_pm_suspend(struct device *dev) >> > +{ >> > + if (pm_runtime_suspended(dev)) >> > + return 0; >> > + >> > + return arm_smmu_runtime_suspend(dev); >> > +} >> > + >> > +static const struct dev_pm_ops arm_smmu_pm_ops = { >> > + SET_SYSTEM_SLEEP_PM_OPS(arm_smmu_pm_suspend, arm_smmu_pm_resume) >> >> I am wondering if using the ->suspend|resume() callback is really >> "late/early" enough in the device suspend phase? >> >> Others is using the noirq phase and some is even using the syscore >> ops. Of course it depends on the behavior of the consumers of iommu >> device, and I guess not everyone is using device links, which for sure >> improves things in this regards as well. > > Well yes, as you said the device links should be able to take care of > maintaining the correct suspend/resume order of smmu and its clients, > or am I missing your point here? > Let me know and I will be happy to incorporate any suggestions. > Thanks If it works fine, then you may keep it as is. Just wanted to point out that if any consumers relies on the iommu to operational to say until the suspend-late phase, then this doesn't play. Then you need to move your callbacks to the corresponding same phase. [...] Kind regards Uffe