From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Szyprowski Subject: Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device Date: Thu, 13 Jul 2017 14:23:54 +0200 Message-ID: <4f2b6272-d938-767f-6ea3-0b515374d1a1@samsung.com> References: <1499333825-7658-1-git-send-email-vivek.gautam@codeaurora.org> <1499333825-7658-4-git-send-email-vivek.gautam@codeaurora.org> <20170712225459.GZ22780@codeaurora.org> <5ee0bacd-e557-a6c4-a897-844fb12ea6ae@codeaurora.org> <4dbc938c-ac88-9bd4-cf00-458008ae24c1@codeaurora.org> <939f8745-6f72-522c-1216-70e424740b62@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-reply-to: Content-language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Rob Clark Cc: Mark Rutland , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Stephen Boyd , Linux Kernel Mailing List , Will Deacon , Stanimir Varbanov , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Rob Herring , Vivek Gautam , linux-arm-msm , linux-clk , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: linux-arm-msm@vger.kernel.org Hi Rob, On 2017-07-13 14:10, Rob Clark wrote: > On Thu, Jul 13, 2017 at 8:02 AM, Marek Szyprowski > wrote: >> On 2017-07-13 13:50, Rob Clark wrote: >>> On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R >>> wrote: >>>> On 7/13/2017 10:43 AM, Vivek Gautam wrote: >>>>> On 07/13/2017 04:24 AM, Stephen Boyd wrote: >>>>>> On 07/06, Vivek Gautam wrote: >>>>>>> @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain >>>>>>> *domain, unsigned long iova, >>>>>>> static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned >>>>>>> long iova, >>>>>>> size_t size) >>>>>>> { >>>>>>> - struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops; >>>>>>> + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >>>>>>> + struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops; >>>>>>> + size_t ret; >>>>>>> if (!ops) >>>>>>> return 0; >>>>>>> - return ops->unmap(ops, iova, size); >>>>>>> + pm_runtime_get_sync(smmu_domain->smmu->dev); >>>>>> Can these map/unmap ops be called from an atomic context? I seem >>>>>> to recall that being a problem before. >>>>> That's something which was dropped in the following patch merged in >>>>> master: >>>>> 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock >>>>> >>>>> Looks like we don't need locks here anymore? >>>> Apart from the locking, wonder why a explicit pm_runtime is needed >>>> from unmap. Somehow looks like some path in the master using that >>>> should have enabled the pm ? >>>> >>> Yes, there are a bunch of scenarios where unmap can happen with >>> disabled master (but not in atomic context). On the gpu side we >>> opportunistically keep a buffer mapping until the buffer is freed >>> (which can happen after gpu is disabled). Likewise, v4l2 won't unmap >>> an exported dmabuf while some other driver holds a reference to it >>> (which can be dropped when the v4l2 device is suspended). >>> >>> Since unmap triggers tbl flush which touches iommu regs, the iommu >>> driver *definitely* needs a pm_runtime_get_sync(). >> >> Afair unmap might be called from atomic context as well, for example as >> a result of dma_unmap_page(). In exynos IOMMU I simply check the runtime >> PM state of IOMMU device. TLB flush is performed only when IOMMU is in >> active >> state. If it is suspended, I assume that the IOMMU controller's context >> is already lost and its respective power domain might be already turned off, >> so there is no point in touching IOMMU registers. >> > that seems like an interesting approach.. although I wonder if there > can be some race w/ new device memory access once clks are enabled > before tlb flush completes? That would be rather bad, since this > approach is letting the backing pages of memory be freed before tlb > flush. Exynos IOMMU has spinlock for ensuring that there is no race between PM runtime suspend and unmap/tlb flush. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751868AbdGMMYD (ORCPT ); Thu, 13 Jul 2017 08:24:03 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:18297 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157AbdGMMYA (ORCPT ); Thu, 13 Jul 2017 08:24:00 -0400 X-AuditID: cbfec7f2-f797e6d000004438-bc-5967665c6b7b Subject: Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device To: Rob Clark Cc: Sricharan R , Vivek Gautam , Stephen Boyd , Joerg Roedel , Robin Murphy , Rob Herring , Mark Rutland , Will Deacon , "iommu@lists.linux-foundation.org" , "devicetree@vger.kernel.org" , Linux Kernel Mailing List , linux-clk , linux-arm-msm , Stanimir Varbanov , Archit Taneja , "linux-arm-kernel@lists.infradead.org" From: Marek Szyprowski Message-id: <4f2b6272-d938-767f-6ea3-0b515374d1a1@samsung.com> Date: Thu, 13 Jul 2017 14:23:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit Content-language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA03Se0hTURwHcM/uvbt3w8VxWv4wK1lEZC+lqNNLCvzj/mMI9YevyqF36zEt d1Uygpap+UrTUeayzSgzbFAuFTPLfNCkfCQjK/IFSfZgmJVgRpbbNfC/D+f8fud3vofDUeov TBB3LDVdMKZqDRq5km56/qtvY4JOHxtWPrqBZOe7GWLr6mNIddsuUnD9AUscHwYZUtbWy5Kp 4hGGuFqq5KTmzYCMTNycoUjuky6WtH8bZ8hMTxFNfpbl0yQnr0tGun81U+TzVDe9148fb7fK eLvVjnhXySUZ/8gyzPKOugI5PzTYKucf3j7Hm9/WIv6HY2W0Ik65O1kwHMsUjJsjEpVHO4t7 0KkGOD1WkWZCj/wLkYIDvBX6hwvkkpfBq5H781ZyalyDYOyZnfZsqPEPBFd7D/9vmBy+wEpF dxD0NblkUtEEAqctymN/fASaP0x41wPwaqhrbKM9DRT+zcCtQZd3nByHQ6G7cN4cp8IR0HIv 1LNM4zXQZu2nPF6KE+BGdQ7rsQr7wYx5xHshBT4AdVXlXlN4J3ycy2Ukr4KHdjclORAu5L7z zgV8g4P6oRbaMwvwCnA8o6QwkTBlrmYl+8MXZ8OCg8FlLqIllyLIzl0v+dp8YLdK8i7odA4s zF0C5U0VlHS8CvLz1FIJD8UddxnJ+8BsPc9I79ZKQ6nJxl5GIZZF0SyL4lgWxbEsilON6DoU IGSIKXpB3LJJ1KaIGan6TUknUxxo/ge+nHN+b0bT3Ts7EOaQxlfFrdPFqhltppiV0oGAozQB qpp4faxalazNOiMYTx4xZhgEsQMt52hNoEr5YjBGjfXadOGEIJwSjP93ZZwiyIR8da1b/c5l /z5TFfp47Z+lprIdvfWOydie/X99Aiq0jov7bM7KtOiDEUkl9cljNeuS348W8SEln+z3E0VW 1z5eqegcaJ5d/9ouzCakZ9giz+oaw+Kj3NtLwsOP39oxscdu8L8enxh3ZTbI8vhQzLbVIV8n ZwOTaoNNoT450+mlT/UaWjyqDQ+ljKL2HwChDlV9AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42I5/e/4Nd3otPRIg1XtlhZNHW9ZLeYfOcdq sWC/tUXn7A3sFpseX2O1mLj/LLvFx557rBaXd81hs1h6/SKTxfOFP5gtWvceYbc4+OEJq8WP M90sFl8mdrBYtLQdYbI48XMHs8XLjydYHAQ9nhycx+SxZt4aRo/Lfb1MHjtn3WX32LSqk83j zrU9bB6bl9R7TL6xnNHj8ya5AM4oN5uM1MSU1CKF1Lzk/JTMvHRbpdAQN10LJYW8xNxUW6UI Xd+QICWFssScUiDPyAANODgHuAcr6dsluGUc7jnDWLBFouLB9MIGxp3CXYycHBICJhLv7zaz Q9hiEhfurWfrYuTiEBJYwijxYclXVgjnOaPEq6f3mEGqhAXiJXY8fs4EYosIKEus2rqfBaSI WeAvq8TXI8+ZITr2sEhsu3sTrINNwFCi620X0FwODl4BO4ldq7VAwiwCqhL7550HKxEViJG4 NvMOK4jNKyAo8WPyPRYQm1MgWGLKl/1g5zELmEl8eXmYFcKWl9i85i0zhC0u0dx6k2UCo+As JO2zkLTMQtIyC0nLAkaWVYwiqaXFuem5xUZ6xYm5xaV56XrJ+bmbGIFJYduxn1t2MHa9Cz7E KMDBqMTDu0EtLVKINbGsuDL3EKMEB7OSCO/S6PRIId6UxMqq1KL8+KLSnNTiQ4ymQM9NZJYS Tc4HJqy8knhDE0NzS0MjYwsLcyMjJXHeqR+uhAsJpCeWpGanphakFsH0MXFwSjUwNivvmMav +oTrz4Vbdw5v/nJe48q1gx47L33p1VjBvz5S9M3t0mkMZ5aub3b7ENb/OXGPkE5+Yauct2XR ynkuMzSm+2q+Uy7atU3vSpT2+fmt687zXxCtFbhtsn133dSshMi6jNyd0nrn7t3dMn22+5S0 S3Ne1+4RiK5e1nOlOZPlqVB+vm3iJCWW4oxEQy3mouJEAHhkkCEgAwAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170713122356eucas1p1007b70b9471c39c7603780668d72a5d0 X-Msg-Generator: CA X-Sender-IP: 182.198.249.180 X-Local-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRs=?= =?UTF-8?B?7IK87ISx7KCE7J6QG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Global-Sender: =?UTF-8?B?TWFyZWsgU3p5cHJvd3NraRtTUlBPTC1LZXJuZWwgKFRQKRtT?= =?UTF-8?B?YW1zdW5nIEVsZWN0cm9uaWNzG1NlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcg==?= X-Sender-Code: =?UTF-8?B?QzEwG0VIURtDMTBDRDAyQ0QwMjczOTI=?= CMS-TYPE: 201P X-HopCount: 7 X-CMS-RootMailID: 20170713115036epcas1p250113e9009dbf92487d258a90fffc66a X-RootMTR: 20170713115036epcas1p250113e9009dbf92487d258a90fffc66a References: <1499333825-7658-1-git-send-email-vivek.gautam@codeaurora.org> <1499333825-7658-4-git-send-email-vivek.gautam@codeaurora.org> <20170712225459.GZ22780@codeaurora.org> <5ee0bacd-e557-a6c4-a897-844fb12ea6ae@codeaurora.org> <4dbc938c-ac88-9bd4-cf00-458008ae24c1@codeaurora.org> <939f8745-6f72-522c-1216-70e424740b62@samsung.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On 2017-07-13 14:10, Rob Clark wrote: > On Thu, Jul 13, 2017 at 8:02 AM, Marek Szyprowski > wrote: >> On 2017-07-13 13:50, Rob Clark wrote: >>> On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R >>> wrote: >>>> On 7/13/2017 10:43 AM, Vivek Gautam wrote: >>>>> On 07/13/2017 04:24 AM, Stephen Boyd wrote: >>>>>> On 07/06, Vivek Gautam wrote: >>>>>>> @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain >>>>>>> *domain, unsigned long iova, >>>>>>> static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned >>>>>>> long iova, >>>>>>> size_t size) >>>>>>> { >>>>>>> - struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops; >>>>>>> + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >>>>>>> + struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops; >>>>>>> + size_t ret; >>>>>>> if (!ops) >>>>>>> return 0; >>>>>>> - return ops->unmap(ops, iova, size); >>>>>>> + pm_runtime_get_sync(smmu_domain->smmu->dev); >>>>>> Can these map/unmap ops be called from an atomic context? I seem >>>>>> to recall that being a problem before. >>>>> That's something which was dropped in the following patch merged in >>>>> master: >>>>> 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock >>>>> >>>>> Looks like we don't need locks here anymore? >>>> Apart from the locking, wonder why a explicit pm_runtime is needed >>>> from unmap. Somehow looks like some path in the master using that >>>> should have enabled the pm ? >>>> >>> Yes, there are a bunch of scenarios where unmap can happen with >>> disabled master (but not in atomic context). On the gpu side we >>> opportunistically keep a buffer mapping until the buffer is freed >>> (which can happen after gpu is disabled). Likewise, v4l2 won't unmap >>> an exported dmabuf while some other driver holds a reference to it >>> (which can be dropped when the v4l2 device is suspended). >>> >>> Since unmap triggers tbl flush which touches iommu regs, the iommu >>> driver *definitely* needs a pm_runtime_get_sync(). >> >> Afair unmap might be called from atomic context as well, for example as >> a result of dma_unmap_page(). In exynos IOMMU I simply check the runtime >> PM state of IOMMU device. TLB flush is performed only when IOMMU is in >> active >> state. If it is suspended, I assume that the IOMMU controller's context >> is already lost and its respective power domain might be already turned off, >> so there is no point in touching IOMMU registers. >> > that seems like an interesting approach.. although I wonder if there > can be some race w/ new device memory access once clks are enabled > before tlb flush completes? That would be rather bad, since this > approach is letting the backing pages of memory be freed before tlb > flush. Exynos IOMMU has spinlock for ensuring that there is no race between PM runtime suspend and unmap/tlb flush. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device To: Rob Clark Cc: Sricharan R , Vivek Gautam , Stephen Boyd , Joerg Roedel , Robin Murphy , Rob Herring , Mark Rutland , Will Deacon , "iommu@lists.linux-foundation.org" , "devicetree@vger.kernel.org" , Linux Kernel Mailing List , linux-clk , linux-arm-msm , Stanimir Varbanov , Archit Taneja , "linux-arm-kernel@lists.infradead.org" From: Marek Szyprowski Message-id: <4f2b6272-d938-767f-6ea3-0b515374d1a1@samsung.com> Date: Thu, 13 Jul 2017 14:23:54 +0200 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed References: <1499333825-7658-1-git-send-email-vivek.gautam@codeaurora.org> <1499333825-7658-4-git-send-email-vivek.gautam@codeaurora.org> <20170712225459.GZ22780@codeaurora.org> <5ee0bacd-e557-a6c4-a897-844fb12ea6ae@codeaurora.org> <4dbc938c-ac88-9bd4-cf00-458008ae24c1@codeaurora.org> <939f8745-6f72-522c-1216-70e424740b62@samsung.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: Hi Rob, On 2017-07-13 14:10, Rob Clark wrote: > On Thu, Jul 13, 2017 at 8:02 AM, Marek Szyprowski > wrote: >> On 2017-07-13 13:50, Rob Clark wrote: >>> On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R >>> wrote: >>>> On 7/13/2017 10:43 AM, Vivek Gautam wrote: >>>>> On 07/13/2017 04:24 AM, Stephen Boyd wrote: >>>>>> On 07/06, Vivek Gautam wrote: >>>>>>> @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain >>>>>>> *domain, unsigned long iova, >>>>>>> static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned >>>>>>> long iova, >>>>>>> size_t size) >>>>>>> { >>>>>>> - struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops; >>>>>>> + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >>>>>>> + struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops; >>>>>>> + size_t ret; >>>>>>> if (!ops) >>>>>>> return 0; >>>>>>> - return ops->unmap(ops, iova, size); >>>>>>> + pm_runtime_get_sync(smmu_domain->smmu->dev); >>>>>> Can these map/unmap ops be called from an atomic context? I seem >>>>>> to recall that being a problem before. >>>>> That's something which was dropped in the following patch merged in >>>>> master: >>>>> 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock >>>>> >>>>> Looks like we don't need locks here anymore? >>>> Apart from the locking, wonder why a explicit pm_runtime is needed >>>> from unmap. Somehow looks like some path in the master using that >>>> should have enabled the pm ? >>>> >>> Yes, there are a bunch of scenarios where unmap can happen with >>> disabled master (but not in atomic context). On the gpu side we >>> opportunistically keep a buffer mapping until the buffer is freed >>> (which can happen after gpu is disabled). Likewise, v4l2 won't unmap >>> an exported dmabuf while some other driver holds a reference to it >>> (which can be dropped when the v4l2 device is suspended). >>> >>> Since unmap triggers tbl flush which touches iommu regs, the iommu >>> driver *definitely* needs a pm_runtime_get_sync(). >> >> Afair unmap might be called from atomic context as well, for example as >> a result of dma_unmap_page(). In exynos IOMMU I simply check the runtime >> PM state of IOMMU device. TLB flush is performed only when IOMMU is in >> active >> state. If it is suspended, I assume that the IOMMU controller's context >> is already lost and its respective power domain might be already turned off, >> so there is no point in touching IOMMU registers. >> > that seems like an interesting approach.. although I wonder if there > can be some race w/ new device memory access once clks are enabled > before tlb flush completes? That would be rather bad, since this > approach is letting the backing pages of memory be freed before tlb > flush. Exynos IOMMU has spinlock for ensuring that there is no race between PM runtime suspend and unmap/tlb flush. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From mboxrd@z Thu Jan 1 00:00:00 1970 From: m.szyprowski@samsung.com (Marek Szyprowski) Date: Thu, 13 Jul 2017 14:23:54 +0200 Subject: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device In-Reply-To: References: <1499333825-7658-1-git-send-email-vivek.gautam@codeaurora.org> <1499333825-7658-4-git-send-email-vivek.gautam@codeaurora.org> <20170712225459.GZ22780@codeaurora.org> <5ee0bacd-e557-a6c4-a897-844fb12ea6ae@codeaurora.org> <4dbc938c-ac88-9bd4-cf00-458008ae24c1@codeaurora.org> <939f8745-6f72-522c-1216-70e424740b62@samsung.com> Message-ID: <4f2b6272-d938-767f-6ea3-0b515374d1a1@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Rob, On 2017-07-13 14:10, Rob Clark wrote: > On Thu, Jul 13, 2017 at 8:02 AM, Marek Szyprowski > wrote: >> On 2017-07-13 13:50, Rob Clark wrote: >>> On Thu, Jul 13, 2017 at 1:35 AM, Sricharan R >>> wrote: >>>> On 7/13/2017 10:43 AM, Vivek Gautam wrote: >>>>> On 07/13/2017 04:24 AM, Stephen Boyd wrote: >>>>>> On 07/06, Vivek Gautam wrote: >>>>>>> @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain >>>>>>> *domain, unsigned long iova, >>>>>>> static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned >>>>>>> long iova, >>>>>>> size_t size) >>>>>>> { >>>>>>> - struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops; >>>>>>> + struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); >>>>>>> + struct io_pgtable_ops *ops = smmu_domain->pgtbl_ops; >>>>>>> + size_t ret; >>>>>>> if (!ops) >>>>>>> return 0; >>>>>>> - return ops->unmap(ops, iova, size); >>>>>>> + pm_runtime_get_sync(smmu_domain->smmu->dev); >>>>>> Can these map/unmap ops be called from an atomic context? I seem >>>>>> to recall that being a problem before. >>>>> That's something which was dropped in the following patch merged in >>>>> master: >>>>> 523d7423e21b iommu/arm-smmu: Remove io-pgtable spinlock >>>>> >>>>> Looks like we don't need locks here anymore? >>>> Apart from the locking, wonder why a explicit pm_runtime is needed >>>> from unmap. Somehow looks like some path in the master using that >>>> should have enabled the pm ? >>>> >>> Yes, there are a bunch of scenarios where unmap can happen with >>> disabled master (but not in atomic context). On the gpu side we >>> opportunistically keep a buffer mapping until the buffer is freed >>> (which can happen after gpu is disabled). Likewise, v4l2 won't unmap >>> an exported dmabuf while some other driver holds a reference to it >>> (which can be dropped when the v4l2 device is suspended). >>> >>> Since unmap triggers tbl flush which touches iommu regs, the iommu >>> driver *definitely* needs a pm_runtime_get_sync(). >> >> Afair unmap might be called from atomic context as well, for example as >> a result of dma_unmap_page(). In exynos IOMMU I simply check the runtime >> PM state of IOMMU device. TLB flush is performed only when IOMMU is in >> active >> state. If it is suspended, I assume that the IOMMU controller's context >> is already lost and its respective power domain might be already turned off, >> so there is no point in touching IOMMU registers. >> > that seems like an interesting approach.. although I wonder if there > can be some race w/ new device memory access once clks are enabled > before tlb flush completes? That would be rather bad, since this > approach is letting the backing pages of memory be freed before tlb > flush. Exynos IOMMU has spinlock for ensuring that there is no race between PM runtime suspend and unmap/tlb flush. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland