linux-kernel - Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to control runtime pm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 08 Nov 2016 08:27:12 +0100
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        iommu@...ts.linux-foundation.org,
        linux-samsung-soc@...r.kernel.org, Joerg Roedel <joro@...tes.org>,
        Inki Dae <inki.dae@...sung.com>, Kukjin Kim <kgene@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Mark Brown <broonie@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Lukas Wunner <lukas@...ner.de>,
        Kevin Hilman <khilman@...nel.org>,
        Tobias Jakobi <tjakobi@...h.uni-bielefeld.de>,
        Tomasz Figa <tomasz.figa@...il.com>,
        Grant Likely <grant.likely@...retlab.ca>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Mauro Carvalho Chehab <mchehab@....samsung.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH v5 7/7] iommu/exynos: Use device dependency links to
 control runtime pm

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