From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754587AbcKUNL2 (ORCPT ); Mon, 21 Nov 2016 08:11:28 -0500 Received: from mailout3.w1.samsung.com ([210.118.77.13]:58683 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754393AbcKUNLZ (ORCPT ); Mon, 21 Nov 2016 08:11:25 -0500 X-AuditID: cbfec7f4-f791c6d000006eac-09-5832f278a65e Subject: Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to control runtime pm To: Lukas Wunner Cc: "Luis R. Rodriguez" , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, linux-samsung-soc@vger.kernel.org, Joerg Roedel , Inki Dae , Kukjin Kim , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , "Rafael J. Wysocki" , Mark Brown , Greg Kroah-Hartman , Tomeu Vizoso , Kevin Hilman , Tobias Jakobi , Tomasz Figa , Grant Likely , Laurent Pinchart , Lars-Peter Clausen , Andrzej Hajda , Mauro Carvalho Chehab , Dmitry Torokhov From: Marek Szyprowski Message-id: <188bfb9a-ce06-23d4-8d2f-d0189fb3bd3a@samsung.com> Date: Mon, 21 Nov 2016 14:11:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-version: 1.0 In-reply-to: <20161119111157.GA364@wunner.de> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHO7uvSrPb1HoqTVgEZmkpCgeVMOjDDfvQhygpI0ddrHyLXRXt Q4hh6qpNXeWclktnkVbzLVszslYopLkyG6WtEl/TlMigIrE27wK//Z7/8z/Pc/6HwxKKcno9 ezIzW1BnqtKVtC/Z0f27Pzzve1TSjj8PY/DQvX4KtxgsFL4yMkbjZ3VTCE/3tdD4XL2FxhWf ykhs6orDpdXNDNaNzhB4vG1Uhh0Od2nW11K4tNzM4De2GhrPX3qOsMHxWIanJjfgd2XjCDdN 5OG+3gEKn2/6RuFG2wLC2rsDdALwY0+vy3iry4z4h0YXw1eXVFF8a2MpzXddu8Pw+ne3EL/Y zfDmr3aKb9e5He1vi0le296I+N9ftvHzrRt5Q3EHtW/VId/440L6yVxBvX1niu+JcWcneXo4 MK/T8Z4pQIucBvmwwEWDbmQYSbwGXn200Brkyyq4BgSDfd+QVMwjMJp05P8T8+Y52sMK7iYC Q7mPZJpE8KTz55LJnzsCJtsLxsMBnBIKL8/JPCaCq2eg6cEfmadBc5GgmdUsTZJzO8GhH1zS SW4zdFqthIcDuWQYvuwkJM9q+KX/uLTAhwuHx7ZRysMEFwsTi0VeDoG2O7OEdNPPLNwYSdQg 1s3B0PrEK++Goplibxh/mO5pZyQOgjf6C15dh6CwaKvEBgT9s3KJ4+BZz2vvKj+o6KgkpPFy KDmvkJAHV8teyb0LqvudpPQ8wzJoriuhy1CIcVkY47IAxmUBTIhoRAFCjpiRKojREaIqQ8zJ TI04lpXRitwftXex54cV1XfH2hHHIuVKecHtqCQFpcoV8zPsCFhCGSDfP+eW5MdV+WcEddZR dU66INrRBpZUrpU/Mg0eVHCpqmwhTRBOC+r/XRnrs74AEW9fa6MXYiqG7m8VQj81OAy21NqL N50u59/gorSBXa6qiKktB2pGEvf8vRu7cEhhcSj9twdq1/nFDalV+YlJlyovFidnpW1afbWv MOuUGNwQ1qUM+xAUsX+q6uD1qoTalymH4y3N51bEn7WGXp0osWt3t5H5g8kJ6XbcjZIjc44q SfGEKjKMUIuqf8xqTVakAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA12SbUhTURjHO7u7987R6Da3OtiLdqMvkebWiycqiYJ1IxJpitILdtHLlNyM zS3NwFVgKWTTJdjM0hpFU7N0hGmtWmZg2UIr33BWNnWZQ7JCy6xNDaTz6fd/+P05PPAIMLEd DxGkaTI5rYZNpwkh/8X087fhSV/liZHdUxLUc/sVju6W1uKo5MMnAj29NgzQ55d3CXTmei2B ivtNfFTxaCvKL7tDogsDIxjy1A/wkMvlj1bzVRzlF1lJ1NF4mUDj55sBKnU5eGh4aBnqMnkA qhrMQi9ftOMor2oMR7bGKYAKa9qJHZD59OQKj2noswLmvqWPZMrOXcKZOls+wTwqryYZc9dN wEy3kIz1ixNn7Bf8hv3tWT5TaLcBZtK7jhmvW8mUnr2Hxy46oNiWyrEpnDaM0yRnpKRpVNvp +DhFOKLDNKya204nhu+L20+HGdh0vT/JI/97O3bF7lbS66OPKFI975r4x3qlWU2ubtIIpqkC ECSA1EY4bvURs7wEvnbX+lkoEFNWAKtqhrDZMASgvXWMF7CCqcOworGVDLCEouHpi76ZuZjq 5cGfD5WBAkbdJOH1PyMzEkHJYMFowcwXIioausxvZgp8ag1samjAAiylDsHOwY9zzmI4YXbz AxxEhUNH4wAeYIzaDL95n85xKKyvHsVMgLLMq1jmaZZ5WgXAbEDC6XVqlVonj9Cxap1eo4pI zlDXAf/F3GuZtDeAAp/SCSgBoBeKjLfkiWKcNeiy1U4ABRgtEcX5/CNRCpt9gtNmJGn16ZzO CTb5lyjCQqTJGf7702QmyTbKorbI5BsQipLL6aWikrE3CWJKxWZyRznuGKf91+MJgkKM4OCZ iOXN/Xujj69oW1F+MCHYrfKFjlfmlAzvqsxb3f/sl+Sx+1pUTNWEqLwH/tjWw7/x4N0mxUlD veyUUNlL5gZ7cwoX/hZ6YoyrJpcEYblKxyFTWW8IITNK66Z25nm7yjq1Hn1fe5tsj7dt/2ND sSO+w237/l744M8Cq5cwOGm+LpWVrcW0OvYv2PhYHkcDAAA= X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161121131120eucas1p16b658948854790f956dee4d309ba4944 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: 20161020072336eucas1p24a2b020f69b6ae1f55e1760e6e0e94f9 X-RootMTR: 20161020072336eucas1p24a2b020f69b6ae1f55e1760e6e0e94f9 References: <1476948173-21093-1-git-send-email-m.szyprowski@samsung.com> <1476948173-21093-8-git-send-email-m.szyprowski@samsung.com> <20161107214747.GJ1764@wotan.suse.de> <4bc652ce-6cf9-f4df-4793-e126cf81079d@samsung.com> <20161119111157.GA364@wunner.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lukas, On 2016-11-19 12:11, Lukas Wunner wrote: > On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote: >> On 2016-11-07 22:47, Luis R. Rodriguez wrote: >>> If so >>> why? If this issue is present also on systems that only use ACPI is >>> this possibly due to an ACPI firmware bug or the lack of some semantics >>> in ACPI to express ordering in a better way? If the issue is device >>> tree related only is this due to the lack of semantics in device tree >>> to express some more complex dependency ? >> The main feature of device links that is used in this patch is enabling >> runtime pm dependency between Exynos SYSMMU controller (called it client >> device) and the device, for which it implements DMA address translation >> (called master device). The assumptions are following: >> 1. master device driver is completely unaware of the Exynos SYSMMU presence, >> IOMMU is transparently hooked up and managed by DMA-mapping framework >> 2. SYSMMU belongs to the same power domain as it's master device >> 3. SYSMMU is optional, master device can fully operate without it, with >> simple DMA address translation (DMA address == physical address) >> 4. Master device implements runtime pm, what in turn causes respective >> power domain to be turned on/off >> 5. DMA-mapping and IOMMU frameworks provides no calls to notify SYSMMU >> when its master device is performing DMA operations, so SYSMMU has >> to be runtime active >> 6. Currently SYSMMU always sets its runtime pm status to active after >> attaching to its master device to ensure proper hardware state. This >> prevents power domain to be turned off, even when master device sets >> its runtime pm status to suspended. >> 7. Exynos SYSMMU has to be runtime active at the same time when its >> master device is runtime active to it to perform DMA operations and >> allow the power domain to be turned off, when master device is >> runtime suspended. >> 8. The terms of device links, Exynos SYSMMU is a 'consumer' and master >> device is a 'supplier'. > You seem to have mixed up the consumer and supplier in point 8 above. > Your code is such that the SYSMMU is the supplier and the master device > is the consumer: > > device_link_add(dev, data->sysmmu, DL_FLAG_PM_RUNTIME); > > Prototype of device_link_add: > > struct device_link *device_link_add(struct device *consumer, > struct device *supplier, > u32 flags); > > Your code is correct, only point 8 above is wrong. Thanks for checking this. You are right that I mixed up consumer and supplier in point 8. I'm sorry for the confusion. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Szyprowski Subject: Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to control runtime pm Date: Mon, 21 Nov 2016 14:11:18 +0100 Message-ID: <188bfb9a-ce06-23d4-8d2f-d0189fb3bd3a@samsung.com> References: <1476948173-21093-1-git-send-email-m.szyprowski@samsung.com> <1476948173-21093-8-git-send-email-m.szyprowski@samsung.com> <20161107214747.GJ1764@wotan.suse.de> <4bc652ce-6cf9-f4df-4793-e126cf81079d@samsung.com> <20161119111157.GA364@wunner.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <20161119111157.GA364@wunner.de> Sender: linux-samsung-soc-owner@vger.kernel.org To: Lukas Wunner Cc: "Luis R. Rodriguez" , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, linux-samsung-soc@vger.kernel.org, Joerg Roedel , Inki Dae , Kukjin Kim , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , "Rafael J. Wysocki" , Mark Brown , Greg Kroah-Hartman , Tomeu Vizoso , Kevin Hilman , Tobias Jakobi , Tomasz Figa , Grant Likely , Laurent Pinchart , Lars-Peter Clausen List-Id: linux-pm@vger.kernel.org Hi Lukas, On 2016-11-19 12:11, Lukas Wunner wrote: > On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote: >> On 2016-11-07 22:47, Luis R. Rodriguez wrote: >>> If so >>> why? If this issue is present also on systems that only use ACPI is >>> this possibly due to an ACPI firmware bug or the lack of some semantics >>> in ACPI to express ordering in a better way? If the issue is device >>> tree related only is this due to the lack of semantics in device tree >>> to express some more complex dependency ? >> The main feature of device links that is used in this patch is enabling >> runtime pm dependency between Exynos SYSMMU controller (called it client >> device) and the device, for which it implements DMA address translation >> (called master device). The assumptions are following: >> 1. master device driver is completely unaware of the Exynos SYSMMU presence, >> IOMMU is transparently hooked up and managed by DMA-mapping framework >> 2. SYSMMU belongs to the same power domain as it's master device >> 3. SYSMMU is optional, master device can fully operate without it, with >> simple DMA address translation (DMA address == physical address) >> 4. Master device implements runtime pm, what in turn causes respective >> power domain to be turned on/off >> 5. DMA-mapping and IOMMU frameworks provides no calls to notify SYSMMU >> when its master device is performing DMA operations, so SYSMMU has >> to be runtime active >> 6. Currently SYSMMU always sets its runtime pm status to active after >> attaching to its master device to ensure proper hardware state. This >> prevents power domain to be turned off, even when master device sets >> its runtime pm status to suspended. >> 7. Exynos SYSMMU has to be runtime active at the same time when its >> master device is runtime active to it to perform DMA operations and >> allow the power domain to be turned off, when master device is >> runtime suspended. >> 8. The terms of device links, Exynos SYSMMU is a 'consumer' and master >> device is a 'supplier'. > You seem to have mixed up the consumer and supplier in point 8 above. > Your code is such that the SYSMMU is the supplier and the master device > is the consumer: > > device_link_add(dev, data->sysmmu, DL_FLAG_PM_RUNTIME); > > Prototype of device_link_add: > > struct device_link *device_link_add(struct device *consumer, > struct device *supplier, > u32 flags); > > Your code is correct, only point 8 above is wrong. Thanks for checking this. You are right that I mixed up consumer and supplier in point 8. I'm sorry for the confusion. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland