From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers Date: Thu, 22 Feb 2018 13:45:34 +0000 Message-ID: <28466b36-b5d3-4f60-a45e-b75d79c2a3cb@arm.com> References: <1517999482-17317-1-git-send-email-vivek.gautam@codeaurora.org> <7406f1ce-c2c9-a6bd-2886-5a34de45add6@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: en-GB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: freedreno-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "Freedreno" To: Tomasz Figa Cc: Mark Rutland , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Linux PM , David Airlie , "Rafael J. Wysocki" , Joerg Roedel , Will Deacon , "list-Y9sIeH5OGRo@public.gmane.org:IOMMU DRIVERS" , dri-devel , Linux Kernel Mailing List , Rob Clark , Rob Herring , Vivek Gautam , Greg KH , freedreno , Stephen Boyd , linux-arm-msm List-Id: linux-arm-msm@vger.kernel.org W3NvcnJ5LCBJIGhhZCBpbnRlbmRlZCB0byByZXBseSBzb29uZXIgYnV0IGNsZWFybHkgZm9yZ290 XQoKT24gMTYvMDIvMTggMDA6MTMsIFRvbWFzeiBGaWdhIHdyb3RlOgo+IE9uIEZyaSwgRmViIDE2 LCAyMDE4IGF0IDI6MTQgQU0sIFJvYmluIE11cnBoeSA8cm9iaW4ubXVycGh5QGFybS5jb20+IHdy b3RlOgo+PiBPbiAxNS8wMi8xOCAwNDoxNywgVG9tYXN6IEZpZ2Egd3JvdGU6Cj4+IFsuLi5dCj4+ Pj4KPj4+PiBDb3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQga2luZCBvZiBsb2NraW5nIHlvdSBh cmUgY29uY2VybmVkIGFib3V0Pwo+Pj4+IEFzIEkgZXhwbGFpbmVkIGJlZm9yZSwgdGhlIG5vcm1h bGx5IGhhcHBlbmluZyBmYXN0IHBhdGggd291bGQgbG9jawo+Pj4+IGRldi0+cG93ZXJfbG9jayBv bmx5IGZvciB0aGUgYnJpZWYgbW9tZW50IG9mIGluY3JlbWVudGluZyB0aGUgcnVudGltZQo+Pj4+ IFBNIHVzYWdlIGNvdW50ZXIuCj4+Pgo+Pj4KPj4+IE15IGJhZCwgdGhhdCdzIG5vdCBldmVuIGl0 Lgo+Pj4KPj4+IFRoZSBhdG9taWMgdXNhZ2UgY291bnRlciBpcyBpbmNyZW1lbnRlZCBiZWZvcmVo YW5kcywgd2l0aG91dCBhbnkKPj4+IGxvY2tpbmcgWzFdIGFuZCB0aGUgc3BpbmxvY2sgaXMgYWNx dWlyZWQgb25seSBmb3IgdGhlIHNha2Ugb2YKPj4+IHZhbGlkYXRpbmcgdGhhdCBkZXZpY2UncyBy dW50aW1lIFBNIHN0YXRlIHJlbWFpbmVkIHZhbGlkIGluZGVlZCBbMl0sCj4+PiB3aGljaCB3b3Vs ZCBiZSB0aGUgY2FzZSBpbiB0aGUgZmFzdCBwYXRoIG9mIHRoZSBzYW1lIGRyaXZlciBkb2luZyB0 d28KPj4+IG1hcHBpbmdzIGluIHBhcmFsbGVsLCB3aXRoIHRoZSBtYXN0ZXIgcG93ZXJlZCBvbiAo YW5kIHNvIHRoZSBTTU1VLAo+Pj4gdGhyb3VnaCBkZXZpY2UgbGlua3M7IGlmIG1hc3RlciB3YXMg bm90IHBvd2VyZWQgb24gYWxyZWFkeSwgcG93ZXJpbmcKPj4+IG9uIHRoZSBTTU1VIGlzIHVuYXZv aWRhYmxlIGFueXdheSBhbmQgaXQgd291bGQgYWRkIG11Y2ggbW9yZSBsYXRlbmN5Cj4+PiB0aGFu IHRoZSBzcGlubG9jayBpdHNlbGYpLgo+Pgo+Pgo+PiBXZSBub3cgaGF2ZSBubyBsb2NraW5nIGF0 IGFsbCBpbiB0aGUgbWFwIHBhdGgsIGFuZCBvbmx5IGEgcGVyLWRvbWFpbiBsb2NrCj4+IGFyb3Vu ZCBUTEIgc3luYyBpbiB1bm1hcCB3aGljaCBpcyB1bmZvcnR1bmF0ZWx5IG5lY2Vzc2FyeSBmb3Ig Y29ycmVjdG5lc3M7Cj4+IHRoZSBsYXR0ZXIgaXNuJ3QgdG9vIHRlcnJpYmxlLCBzaW5jZSBpbiAi c2VyaW91cyIgaGFyZHdhcmUgaXQgc2hvdWxkIG9ubHkgYmUKPj4gc2VyaWFsaXNpbmcgYSBmZXcg Y3B1cyBzZXJ2aW5nIHRoZSBzYW1lIGRldmljZSBhZ2FpbnN0IGVhY2ggb3RoZXIgKGUuZy4gZm9y Cj4+IG11bHRpcGxlIHF1ZXVlcyBvbiBhIHNpbmdsZSBOSUMpLgo+Pgo+PiBQdXR0aW5nIGluIGEg Z2xvYmFsIGxvY2sgd2hpY2ggc2VyaWFsaXNlcyAqYWxsKiBjb25jdXJyZW50IG1hcCBhbmQgdW5t YXAKPj4gY2FsbHMgZm9yICphbGwqIHVucmVsYXRlZCBkZXZpY2VzIG1ha2VzIHRoaW5ncyB3b3Jz ZS4gUGVyaW9kLiBFdmVuIGlmIHRoZQo+PiBsb2NrIGl0c2VsZiB3ZXJlIGhlbGQgZm9yIHRoZSBt aW5pbXVtIHBvc3NpYmxlIHRpbWUsIGkuZS4gdHJpdmlhbGx5Cj4+ICJzcGluX2xvY2soJmxvY2sp OyBzcGluX3VubG9jaygmbG9jaykiLCB0aGUgY29zdCBvZiByZXBlYXRlZGx5IGJvdW5jaW5nIHRo YXQKPj4gb25lIGNhY2hlIGxpbmUgYXJvdW5kIGJldHdlZW4gOTYgQ1BVcyBhY3Jvc3MgdHdvIHNv Y2tldHMgaXMgbm90IG5lZ2xpZ2libGUuCj4gCj4gRmFpciBlbm91Z2guIE5vdGUgdGhhdCB3ZSdy ZSBpbiBhIHF1aXRlIGludGVyZXN0aW5nIHNpdHVhdGlvbiBub3c6Cj4gICBhKSBXZSBuZWVkIHRv IGhhdmUgcnVudGltZSBQTSBlbmFibGVkIG9uIFF1YWxjb21tIFNvQyB0byBoYXZlIHBvd2VyCj4g cHJvcGVybHkgbWFuYWdlZCwKPiAgIGIpIFdlIG5lZWQgdG8gaGF2ZSBsb2NrLWZyZWUgbWFwL3Vu bWFwIG9uIHN1Y2ggZGlzdHJpYnV0ZWQgc3lzdGVtcywKPiAgIGMpIElmIHJ1bnRpbWUgUE0gaXMg ZW5hYmxlZCwgd2UgbmVlZCB0byBjYWxsIGludG8gcnVudGltZSBQTSBmcm9tIGFueQo+IGNvZGUg dGhhdCBkb2VzIGhhcmR3YXJlIGFjY2Vzc2VzLCBvdGhlcndpc2UgdGhlIElPTU1VIEFQSSAoYW5k IHNvIERNQQo+IEFQSSBhbmQgdGhlbiBhbnkgVjRMMiBkcml2ZXIpIGJlY29tZXMgdW51c2FibGUu Cj4gCj4gSSBjYW4gc2VlIG9uZSBtb3JlIHdheSB0aGF0IGNvdWxkIHBvdGVudGlhbGx5IGxldCB1 cyBoYXZlIGFsbCB0aGUKPiB0aHJlZS4gSG93IGFib3V0IGVuYWJsaW5nIHJ1bnRpbWUgUE0gb25s eSBvbiBzZWxlY3RlZCBpbXBsZW1lbnRhdGlvbnMKPiAoZS5nLiBxY29tLHNtbXUpIGFuZCB0aGVu IGhhdmluZyBhbGwgdGhlIHJ1bnRpbWUgUE0gY2FsbHMgc3Vycm91bmRlZAo+IHdpdGggaWYgKHBt X3J1bnRpbWVfZW5hYmxlZCgpKSwgd2hpY2ggaXMgbG9ja2xlc3M/CgpZZXMsIHRoYXQncyB0aGUg a2luZCBvZiB0aGluZyBJIHdhcyBncmF2aXRhdGluZyB0b3dhcmRzIC0gbXkgdmFndWUgCnRob3Vn aHQgd2FzIGFkZGluZyBzb21lIGZsYWcgdG8gdGhlIHNtbXVfZG9tYWluLCBidXQgCnBtX3J1bnRp bWVfZW5hYmxlZCgpIGRvZXMgbG9vayBjb25jZXB0dWFsbHkgYSBsb3QgY2xlYW5lci4KCj4+Cj4+ PiBbMV0KPj4+IGh0dHA6Ly9lbGl4aXIuZnJlZS1lbGVjdHJvbnMuY29tL2xpbnV4L3Y0LjE2LXJj MS9zb3VyY2UvZHJpdmVycy9iYXNlL3Bvd2VyL3J1bnRpbWUuYyNMMTAyOAo+Pj4gWzJdCj4+PiBo dHRwOi8vZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92NC4xNi1yYzEvc291cmNlL2Ry aXZlcnMvYmFzZS9wb3dlci9ydW50aW1lLmMjTDYxMwo+Pj4KPj4+IEluIGFueSBjYXNlLCBJIGNh bid0IGltYWdpbmUgdGhpcyB3b3JraW5nIHdpdGggVjRMMiBvciBhbnl0aGluZyBlbHNlCj4+PiBy ZWx5aW5nIG9uIGFueSBtZW1vcnkgbWFuYWdlbWVudCBtb3JlIGdlbmVyaWMgdGhhbiBjYWxsaW5n IElPTU1VIEFQSQo+Pj4gZGlyZWN0bHkgZnJvbSB0aGUgZHJpdmVyLCB3aXRoIHRoZSBJT01NVSBk ZXZpY2UgaGF2aW5nIHJ1bnRpbWUgUE0KPj4+IGVuYWJsZWQsIGJ1dCB3aXRob3V0IG1hbmFnaW5n IHRoZSBydW50aW1lIFBNIGZyb20gdGhlIElPTU1VIGRyaXZlcidzCj4+PiBjYWxsYmFja3MgdGhh dCBuZWVkIGFjY2VzcyB0byB0aGUgaGFyZHdhcmUuIEFzIEkgbWVudGlvbmVkIGJlZm9yZSwKPj4+ IG9ubHkgdGhlIElPTU1VIGRyaXZlciBrbm93cyB3aGVuIGV4YWN0bHkgdGhlIHJlYWwgaGFyZHdh cmUgYWNjZXNzCj4+PiBuZWVkcyB0byBiZSBkb25lIChlLmcuIFJvY2tjaGlwL0V4eW5vcyBkb24n dCBuZWVkIHRvIGRvIHRoYXQgZm9yCj4+PiBtYXAvdW5tYXAgaWYgdGhlIHBvd2VyIGlzIGRvd24s IGJ1dCBzb21lIGltcGxlbWVudGF0aW9ucyBvZiBTTU1VIHdpdGgKPj4+IFRMQiBwb3dlcmVkIHNl cGFyYXRlbHkgbWlnaHQgbmVlZCB0byBkbyBzbykuCj4+Cj4+Cj4+IEl0J3Mgd29ydGggbm90aW5n IHRoYXQgRXh5bm9zIGFuZCBSb2NrY2hpcCBhcmUgcmVsYXRpdmVseSBzbWFsbAo+PiBzZWxmLWNv bnRhaW5lZCBJUCBibG9ja3MgaW50ZWdyYXRlZCBjbG9zZWx5IHdpdGggdGhlIGludGVyZmFjZXMg b2YgdGhlaXIKPj4gcmVsZXZhbnQgbWFzdGVyIGRldmljZXM7IFNNTVUgaXMgYW4gYXJjaGl0ZWN0 dXJlLCBpbXBsZW1lbnRhdGlvbnMgb2Ygd2hpY2gKPj4gbWF5IGJlIGxhcmdlLCBkaXN0cmlidXRl ZCwgYW5kIGhhdmUgY29tcGxleCBhbmQgd2lsZGx5IGRpZmZlcmluZyBpbnRlcm5hbAo+PiB0b3Bv bG9naWVzLiBBcyBzdWNoLCBpdCdzIGEgbG90IGhhcmRlciB0byBtYWtlIGhhcmR3YXJlLXNwZWNp ZmljIGFzc3VtcHRpb25zCj4+IGFuZC9vciBiZSBjb3JyZWN0IGZvciBhbGwgcG9zc2libGUgY2Fz ZXMuCj4+Cj4+IERvbid0IGdldCBtZSB3cm9uZywgSSBkbyB1bHRpbWF0ZWx5IGFncmVlIHRoYXQg dGhlIElPTU1VIGRyaXZlciBpcyB0aGUgb25seQo+PiBhZ2VudCB3aG8gdWx0aW1hdGVseSBrbm93 cyB3aGF0IGNhbGxzIGFyZSBnb2luZyB0byBiZSBuZWNlc3NhcnkgZm9yIHdoYXRldmVyCj4+IG9w ZXJhdGlvbiBpdCdzIHBlcmZvcm1pbmcgb24gaXRzIG93biBoYXJkd2FyZSo7IGl0J3MganVzdCB0 aGF0IGZvciBTTU1VIGl0Cj4+IG5lZWRzIHRvIGJlIGltcGxlbWVudGVkIGluIGEgd2F5IHRoYXQg aGFzIHplcm8gaW1wYWN0IG9uIHRoZSBjYXNlcyB3aGVyZSBpdAo+PiBkb2Vzbid0IG1hdHRlciwg YmVjYXVzZSBpdCdzIG5vdCB2aWFibGUgdG8gc3BlY2lhbGlzZSB0aGF0IGRyaXZlciBmb3IgYW55 Cj4+IHBhcnRpY3VsYXIgSVAgaW1wbGVtZW50YXRpb24vdXNlLWNhc2UuCj4gCj4gU3RpbGwsIGV4 YWN0bHkgdGhlIHNhbWUgaG9sZHMgZm9yIHRoZSBsb3cgcG93ZXIgZW1iZWRkZWQgdXNlIGNhc2Vz LAo+IHdoZXJlIHdlIHN0cml2ZSBmb3IgdGhlIGxvd2VzdCBwb3NzaWJsZSBwb3dlciBjb25zdW1w dGlvbiwgd2hpbGUKPiBtYWludGFpbmluZyBwZXJmb3JtYW5jZSBsZXZlbHMgaGlnaCBhcyB3ZWxs LiBBbmQgc28gdGhlIFNNTVUgY29kZSBpcwo+IGV4cGVjdGVkIHRvIGFsc28gd29yayB3aXRoIG91 ciB1c2UgY2FzZXMsIHN1Y2ggYXMgVjRMMiBvciBEUk0gZHJpdmVycy4KPiBTaW5jZSB0aGVzZSBw b2ludHMgZG9uJ3QgaG9sZCBmb3IgY3VycmVudCBTTU1VIGNvZGUsIEkgY291bGQgc2F5IHRoYXQK PiB0aGUgaXQgaGFzIGJlZW4gYWxyZWFkeSBzcGVjaWFsaXplZCBmb3IgbGFyZ2UsIGRpc3RyaWJ1 dGVkCj4gaW1wbGVtZW50YXRpb25zLgoKSGVoLCByZWFsbHkgaXQncyBzcGVjaWFsaXNlZCBmb3Ig ZWFzZSBvZiBtYWludGVuYW5jZSBpbiB0ZXJtcyBvZiBkb2luZyAKYXMgbGl0dGxlIGFzIHdlIGNh biBnZXQgYXdheSB3aXRoLCBidXQgZm9yIHdoYXQgd2UgaGF2ZSBpbXBsZW1lbnRlZCwgCmZhc3Qg Y29kZSBkb2VzIHNhdmUgQ1BVIGN5Y2xlcyBhbmQgcG93ZXIgb24gZW1iZWRkZWQgc3lzdGVtcyB0 b28gOykKClJvYmluLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpGcmVlZHJlbm8gbWFpbGluZyBsaXN0CkZyZWVkcmVub0BsaXN0cy5mcmVlZGVza3RvcC5v cmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlZHJl bm8K From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AG47ELu2aJ8u2Mrqkm4kBM9X+ZzE6XTf3+hZORP/NH24E7Q+GGQd4A9eFF0xXTpWU4ZxxJo2GU6F ARC-Seal: i=1; a=rsa-sha256; t=1519307140; cv=none; d=google.com; s=arc-20160816; b=Jt9Oc9CbnXpbylv+7lYPdCEtsuHg35yTX/kULheklZq3K4Riimt8iFCshvgtBbfDfP zxVb0FHukljdiyEirNc677xQFuw9eTLiZr2a9KiYOsvWZvIn0wtyHrllnk9lN2vGTECM tWviv8jOd6yK3AzQT0ipmchBiCQjUSdeBXI6ll0V88THHAwdwTYp6/sEnI9I6Rfc1ymS TqQT2pvw56rBIpWA1V++8J8Z/bdwLCJiviJyWVbujwI/+CPzw0xU40fTJ7B0fcW9XsqS k+gktK1Fx7zFiDs7lMjuV9Ha+dDTTcZgTWXxF5y1kOhzHVQr2FD6I2T6o4iPnHeK+sT+ 1fGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :arc-authentication-results; bh=G7BcZMLPJwB/L6Vy+dmxGpkwTmkjCMlNF+8BedMl8HM=; b=hnNQ/4HnMlzOUKPXjM5Qrj38VZ3bJ7PloWT1WJWY7ci9z/doe70pHdbLUbD9Swm7ng PCHmCliF0lyiMTa4lmHL9+jdCmJ/RK4h94HGfFsECNJOgILjKXBMcxjHJ+ELEvijIykc 2Dtc5lPzUD5psiZyB+s5Lpx2eLKZxKsV/HHvzUdNZBEoKz1PPsbUBgnP0S5WAB56Pbih qWJTbGnm8fe2iefAabAtaM3qu9dk/BOgo9XPtmPZlwJmyq0oMe3QXlWZJYGqAJQRKzV0 Lx7pEBbqSzJJPIKqYgopUO1iJr/b+4g1mFmoqbhoWi4obQVBXjxvo3JICBxOcSt+NiF5 V5SQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of robin.murphy@arm.com designates 217.140.101.70 as permitted sender) smtp.mailfrom=robin.murphy@arm.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of robin.murphy@arm.com designates 217.140.101.70 as permitted sender) smtp.mailfrom=robin.murphy@arm.com Subject: Re: [PATCH v7 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers To: Tomasz Figa Cc: Vivek Gautam , Will Deacon , Rob Clark , "list@263.net:IOMMU DRIVERS" , Joerg Roedel , Rob Herring , Mark Rutland , "Rafael J. Wysocki" , devicetree@vger.kernel.org, Linux Kernel Mailing List , Linux PM , dri-devel , freedreno , David Airlie , Greg KH , Stephen Boyd , linux-arm-msm , jcrouse@codeaurora.org References: <1517999482-17317-1-git-send-email-vivek.gautam@codeaurora.org> <7406f1ce-c2c9-a6bd-2886-5a34de45add6@arm.com> From: Robin Murphy Message-ID: <28466b36-b5d3-4f60-a45e-b75d79c2a3cb@arm.com> Date: Thu, 22 Feb 2018 13:45:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1591737886832187485?= X-GMAIL-MSGID: =?utf-8?q?1593109003600525983?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: [sorry, I had intended to reply sooner but clearly forgot] On 16/02/18 00:13, Tomasz Figa wrote: > On Fri, Feb 16, 2018 at 2:14 AM, Robin Murphy wrote: >> On 15/02/18 04:17, Tomasz Figa wrote: >> [...] >>>> >>>> Could you elaborate on what kind of locking you are concerned about? >>>> As I explained before, the normally happening fast path would lock >>>> dev->power_lock only for the brief moment of incrementing the runtime >>>> PM usage counter. >>> >>> >>> My bad, that's not even it. >>> >>> The atomic usage counter is incremented beforehands, without any >>> locking [1] and the spinlock is acquired only for the sake of >>> validating that device's runtime PM state remained valid indeed [2], >>> which would be the case in the fast path of the same driver doing two >>> mappings in parallel, with the master powered on (and so the SMMU, >>> through device links; if master was not powered on already, powering >>> on the SMMU is unavoidable anyway and it would add much more latency >>> than the spinlock itself). >> >> >> We now have no locking at all in the map path, and only a per-domain lock >> around TLB sync in unmap which is unfortunately necessary for correctness; >> the latter isn't too terrible, since in "serious" hardware it should only be >> serialising a few cpus serving the same device against each other (e.g. for >> multiple queues on a single NIC). >> >> Putting in a global lock which serialises *all* concurrent map and unmap >> calls for *all* unrelated devices makes things worse. Period. Even if the >> lock itself were held for the minimum possible time, i.e. trivially >> "spin_lock(&lock); spin_unlock(&lock)", the cost of repeatedly bouncing that >> one cache line around between 96 CPUs across two sockets is not negligible. > > Fair enough. Note that we're in a quite interesting situation now: > a) We need to have runtime PM enabled on Qualcomm SoC to have power > properly managed, > b) We need to have lock-free map/unmap on such distributed systems, > c) If runtime PM is enabled, we need to call into runtime PM from any > code that does hardware accesses, otherwise the IOMMU API (and so DMA > API and then any V4L2 driver) becomes unusable. > > I can see one more way that could potentially let us have all the > three. How about enabling runtime PM only on selected implementations > (e.g. qcom,smmu) and then having all the runtime PM calls surrounded > with if (pm_runtime_enabled()), which is lockless? Yes, that's the kind of thing I was gravitating towards - my vague thought was adding some flag to the smmu_domain, but pm_runtime_enabled() does look conceptually a lot cleaner. >> >>> [1] >>> http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L1028 >>> [2] >>> http://elixir.free-electrons.com/linux/v4.16-rc1/source/drivers/base/power/runtime.c#L613 >>> >>> In any case, I can't imagine this working with V4L2 or anything else >>> relying on any memory management more generic than calling IOMMU API >>> directly from the driver, with the IOMMU device having runtime PM >>> enabled, but without managing the runtime PM from the IOMMU driver's >>> callbacks that need access to the hardware. As I mentioned before, >>> only the IOMMU driver knows when exactly the real hardware access >>> needs to be done (e.g. Rockchip/Exynos don't need to do that for >>> map/unmap if the power is down, but some implementations of SMMU with >>> TLB powered separately might need to do so). >> >> >> It's worth noting that Exynos and Rockchip are relatively small >> self-contained IP blocks integrated closely with the interfaces of their >> relevant master devices; SMMU is an architecture, implementations of which >> may be large, distributed, and have complex and wildly differing internal >> topologies. As such, it's a lot harder to make hardware-specific assumptions >> and/or be correct for all possible cases. >> >> Don't get me wrong, I do ultimately agree that the IOMMU driver is the only >> agent who ultimately knows what calls are going to be necessary for whatever >> operation it's performing on its own hardware*; it's just that for SMMU it >> needs to be implemented in a way that has zero impact on the cases where it >> doesn't matter, because it's not viable to specialise that driver for any >> particular IP implementation/use-case. > > Still, exactly the same holds for the low power embedded use cases, > where we strive for the lowest possible power consumption, while > maintaining performance levels high as well. And so the SMMU code is > expected to also work with our use cases, such as V4L2 or DRM drivers. > Since these points don't hold for current SMMU code, I could say that > the it has been already specialized for large, distributed > implementations. Heh, really it's specialised for ease of maintenance in terms of doing as little as we can get away with, but for what we have implemented, fast code does save CPU cycles and power on embedded systems too ;) Robin.