From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752684AbcKHH1X (ORCPT ); Tue, 8 Nov 2016 02:27:23 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:53840 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750938AbcKHH1V (ORCPT ); Tue, 8 Nov 2016 02:27:21 -0500 X-AuditID: cbfec7f1-f79f46d0000008eb-c4-58217e54c50e Subject: Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to control runtime pm To: "Luis R. Rodriguez" Cc: 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 , Lukas Wunner , 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: <4bc652ce-6cf9-f4df-4793-e126cf81079d@samsung.com> Date: Tue, 08 Nov 2016 08:27:12 +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: <20161107214747.GJ1764@wotan.suse.de> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+XYuO5qr47R608ocRGR20frjQ8OMIk4QXTDIIqlRh2k5jR0t 7UZkXrZITQ3XrFymBd6dJmZmtbxUlqamlKUVuWmXdbNIMa25Y+B/v+d7n/d9v+fjYwh5Bu3B RETF8JooZaSCdiarm0Zal24/6R26onFMjntKWylcoS+j8IV3/TR+kDeI8McnFTROuFZG44w3 6SQ23g3E2pxyKU57/4nAlsr3EtzWZpf5mbkU1p7Pl+LO2ks0HjrXgLC+rV6CBwc88Yt0C8JF 1jj8pKWDwklF3yhcWPsH4dSSDjoYuP77VyRcTW8+4m4ZeqVcTspFijMVamnu7uViKZf54gbi xpukXP5nM8VVpdkdVV3JJJdaVYi4kQ++3JBpPqdPrqa2ztjlvHo/HxlxmNcsD9rrHN4w2oUO 3Zwd9/pRHjqFzHIdcmKAXQW/nw1QIs+CZ31ltA45M3K2AMFwYjkhiiEEZks2/b/j4pm/SCxc R6DN6ZSIYgBB8o9cNOFyY8PAWPtYOsHu7BJIGBRNBGuQQknZT3KiQLN+oLPpHGNlbBDUWzsk E0yyC2EsfcTRPJPdDa+yugnR4wrDmX2OXifWH+5osx3nBBsA1vFESmQvqCy2Oe4NbD8DjXlX 7UMZu5gHpnuEiOvBWhoipnGDj81VUpHnQmfmWVLkNASnE5eIrEfQapOJHAgPmtsnV02HjOrs yZEySEmSi8hBb8Um0b0Wclq7SfF5EiRgKW2XpCMvw5QwhikBDFMCGBFRiNz5WEGt4gX/ZYJS LcRGqZbti1abkP2ntow3f69BXx8GmBHLIIWLbDBtQaicUh4W4tVmBAyhcJdNO+YdKpftV8Yf 5TXRezSxkbxgRp4MqZgtqzM+3yFnVcoY/iDPH+I1/6sSxsnjFEIFH3697VPVNdn8wm4JJ3qE 6K53vjY+3FLgoz6wMt6rQHE2ZfOclpkQ4G2q7+5zWc5sCDuWus7I7mQrSf2a7p8rbYFucRuF pMVLfadps/KyLqieJm/zaB992fPmC7h4mY77NrcdWWT1G6v71TtWedv14IwtL/Uhwae/npmu i1DcUZBCuNLPh9AIyn96aRTapQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsVy+t/xa7qmdYoRBqta9C1urTvHarFxxnpW i6kPn7BZHF70gtHi1ZmNbBbNi9ezWUy6P4HFYsF+a4vO2RvYLfofv2a2eLr5MZPF+fNA7pLJ 81ktOicuYbe4vGsOm8Xn3iOMFjPO72OyePFc2uLGhKeMFqufVVicOX2J1aJt9QdWi1W7/jBa 9K29xOYg4fHk4Dwmjx13lzB67Jx1l91jdsdMVo9NqzrZPPbPXcPuMfnGckaPf8fYPZa8OcTq saUfqGLL1XYWj74tqxg9fr7U8fi8Sc5jRvs21gD+KDebjNTElNQihdS85PyUzLx0W6XQEDdd CyWFvMTcVFulCF3fkCAlhbLEnFIgz8gADTg4B7gHK+nbJbhlHPl9lbFgq3jFnZOLGBsYDwl1 MXJySAiYSMxs+c8IYYtJXLi3nq2LkYtDSGAJo8SrY31MEM5zRolDVxewgFQJC8RKLNh1ih3E FhHQlmh+cRmqqJlJ4urSjYwgDrPAPHaJvScWgXWwCRhKdL3tYgOxeQXsJPY9u8QEYrMIqEr8 nfATbJKoQIzE9WePoGoEJX5MvgfWyylgJLG3czoziM0sYCbx5eVhVghbXmLzmrfMExgFZiFp mYWkbBaSsgWMzKsYRVJLi3PTc4uN9IoTc4tL89L1kvNzNzECk8y2Yz+37GDsehd8iFGAg1GJ h/dFv0KEEGtiWXFl7iFGCQ5mJRFe7mrFCCHelMTKqtSi/Pii0pzU4kOMpkBPTGSWEk3OBybA vJJ4QxNDc0tDI2MLC3MjIyVx3qkfroQLCaQnlqRmp6YWpBbB9DFxcEo1MCpP0mGfqF1nYhvw u2Hx2dnP/RZ8XdzQJla6YorwRW6mjS/mz5rzbKKeQenqbveVmqxWa6qfPfnjbiinJBu6OKPo 3/s3i2a1yLzNiFnp56e6R6Mz7vHif9ds1CW+z95rtEp13hKvskXfKqc/XaF3NGBx1S+1T8VF hWbXym7pfN62r1TuQ9LKjjQlluKMREMt5qLiRACuTGsnSAMAAA== X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161108072715eucas1p1ea8bfe716f5ea675c3d5020ba4670a02 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> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Luis, On 2016-11-07 22:47, Luis R. Rodriguez wrote: > On Thu, Oct 20, 2016 at 09:22:53AM +0200, Marek Szyprowski wrote: >> This patch uses recently introduced device dependency links to track the >> runtime pm state of the master's device. This way each SYSMMU controller >> is set to runtime active only when its master's device is active and can >> restore or save its state instead of being activated all the time when >> attached to the given master device. This way SYSMMU controllers no longer >> prevents respective power domains to be turned off when master's device >> is not being used. > Its unclear why you need this based on this commit log -- is this > needed only on platforms that lack ACPI and use device tree ? Nope, it has nothing to device tree nor ACPI. The dependency is a direct result of the way the devices operate. > 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'. > Has there been any review of the existing similar solutions out there > such as the DRM / audio component framework? Would that help ? Nope, none of that solution deals with runtime pm. 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: Tue, 08 Nov 2016 08:27:12 +0100 Message-ID: <4bc652ce-6cf9-f4df-4793-e126cf81079d@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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-reply-to: <20161107214747.GJ1764@wotan.suse.de> Sender: linux-samsung-soc-owner@vger.kernel.org To: "Luis R. Rodriguez" Cc: 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 , Lukas Wunner , Kevin Hilman , Tobias Jakobi , Tomasz Figa , Grant Likely , Laurent Pinchart , Lars-Peter Clausen List-Id: linux-pm@vger.kernel.org Hi Luis, On 2016-11-07 22:47, Luis R. Rodriguez wrote: > On Thu, Oct 20, 2016 at 09:22:53AM +0200, Marek Szyprowski wrote: >> This patch uses recently introduced device dependency links to track the >> runtime pm state of the master's device. This way each SYSMMU controller >> is set to runtime active only when its master's device is active and can >> restore or save its state instead of being activated all the time when >> attached to the given master device. This way SYSMMU controllers no longer >> prevents respective power domains to be turned off when master's device >> is not being used. > Its unclear why you need this based on this commit log -- is this > needed only on platforms that lack ACPI and use device tree ? Nope, it has nothing to device tree nor ACPI. The dependency is a direct result of the way the devices operate. > 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'. > Has there been any review of the existing similar solutions out there > such as the DRM / audio component framework? Would that help ? Nope, none of that solution deals with runtime pm. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland