Thread (57 messages) 57 messages, 5 authors, 2021-02-09

Re: [PATCH v5 18/27] iommu/mediatek: Add power-domain operation

From: Tomasz Figa <tfiga@chromium.org>
Date: 2021-01-08 09:55:44
Also in: linux-devicetree, linux-iommu, linux-mediatek, lkml

On Tue, Dec 29, 2020 at 8:06 PM Yong Wu [off-list ref] wrote:
On Wed, 2020-12-23 at 17:36 +0900, Tomasz Figa wrote:
quoted
On Wed, Dec 09, 2020 at 04:00:53PM +0800, Yong Wu wrote:
quoted
In the previous SoC, the M4U HW is in the EMI power domain which is
always on. the latest M4U is in the display power domain which may be
turned on/off, thus we have to add pm_runtime interface for it.

When the engine work, the engine always enable the power and clocks for
smi-larb/smi-common, then the M4U's power will always be powered on
automatically via the device link with smi-common.

Note: we don't enable the M4U power in iommu_map/unmap for tlb flush.
If its power already is on, of course it is ok. if the power is off,
the main tlb will be reset while M4U power on, thus the tlb flush while
m4u power off is unnecessary, just skip it.

There will be one case that pm runctime status is not expected when tlb
flush. After boot, the display may call dma_alloc_attrs before it call
pm_runtime_get(disp-dev), then the m4u's pm status is not active inside
the dma_alloc_attrs. Since it only happens after boot, the tlb is clean
at that time, I also think this is ok.

Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
 drivers/iommu/mtk_iommu.c | 41 +++++++++++++++++++++++++++++++++------
 1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6fe3ee2b2bf5..0e9c03cbab32 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -184,6 +184,8 @@ static void mtk_iommu_tlb_flush_all(void *cookie)
    struct mtk_iommu_data *data = cookie;

    for_each_m4u(data) {
+           if (!pm_runtime_active(data->dev))
+                   continue;
Is it guaranteed that the status is active in the check above, but then
the process is preempted and it goes down here?

Shouldn't we do something like below?

        ret = pm_runtime_get_if_active();
        if (!ret)
                continue;
        if (ret < 0)
                // handle error

        // Flush

        pm_runtime_put();
Make sense. Thanks. There is a comment in arm_smmu.c "avoid touching
dev->power.lock in fastpaths". To avoid this here too(we have many SoC
don't have power-domain). then the code will be like:

        bool has_pm = !!data->dev->pm_domain;

        if (has_pm) {
                if (pm_runtime_get_if_in_use(data->dev) <= 0)
                        continue;
        }

        xxxx

        if (has_pm)
                pm_runtime_put(data->dev);
Looks good to me, thanks.
quoted
Similar comment to the other places being changed by this patch.
quoted
            writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
                           data->base + data->plat_data->inv_sel_reg);
            writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
@@ -200,6 +202,10 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size,
    u32 tmp;

    for_each_m4u(data) {
+           /* skip tlb flush when pm is not active. */
+           if (!pm_runtime_active(data->dev))
+                   continue;
+
            spin_lock_irqsave(&data->tlb_lock, flags);
            writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
                           data->base + data->plat_data->inv_sel_reg);
[snip]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help