Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp203592pxb; Thu, 30 Sep 2021 04:27:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxd39Q36rvs5S83ePmaEbuilM3F63c4KdFYdQ4wjnGlCR5V+Gi4Wr08P0FaBSCsNNCgJoZ X-Received: by 2002:aa7:9ac3:0:b0:440:4a66:50b5 with SMTP id x3-20020aa79ac3000000b004404a6650b5mr3789795pfp.73.1633001274078; Thu, 30 Sep 2021 04:27:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633001274; cv=none; d=google.com; s=arc-20160816; b=P2Dd5+O5hgBmCPpOTojv7MkmJzjUuSxb8zPuS/UcX+X0wD7fw3pcaTR3uEW55oYQO6 nA5P7uNyWv6vLpmTjrfkTmwJWTrxz+MX6KipsBeL3C6dXVUXceyVxNCx72gaJo6nOTJv fzkFZ8/+fzQpJZ3k/vrRblCrb18FpK+ev5/AeXKHB6YfrynKJAZkfnO8+sJd/YSfG9lH QVKUR+RWzp4uLmGGjD8JHO3tMngPipr5wMOliLRZ3IIaFNxESLyK6d4LLGwsMaQZoWqN vh4mvd9F447g7drQSHdSHzbdp4xQ720Hoi4m03RvWM7YwPVmaZFq4KtYYa1ybq7uNhCG tTkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=zH/wlZIYLzAkJaqr71Fy/C3aj9rS8jP7xZezxv0EK4g=; b=lGnkFayrDRLRQzBH9GcEws8mXZo+1LQWzDoud4NBWLB/I7lqLYsH/v1BdxtG7HiIDS NOTgbFqYLagxi6IQ+G/SghNhM3wRlExlr5pZ56DG38Yn27Q3o4AP97VZ/6D6BBrRKSqj 4bx7Yud6BL+uKR9SKEtAtSyY5M0VaZv0BjPFmP8LO5GDDHW1h03NuZ20Y/j/+ePWIlZf YPTKFso38K8lmrcxzc6+Js7YDqaU2todGLveDRngqnbTvjWP4VrWazsVgL9EVzwECQUZ SREjiani1607sS3XP/ZTc8MJvoLRjlh1I6IC8l8mR5LqoTCBURxamBT8WVkrvvC3sih7 MoXg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t34si4224776pfg.231.2021.09.30.04.27.40; Thu, 30 Sep 2021 04:27:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350493AbhI3L1z (ORCPT + 99 others); Thu, 30 Sep 2021 07:27:55 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:60440 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350488AbhI3L1y (ORCPT ); Thu, 30 Sep 2021 07:27:54 -0400 Received: from [IPv6:2a02:810a:880:f54:fd5c:7cb1:aaa8:78b1] (unknown [IPv6:2a02:810a:880:f54:fd5c:7cb1:aaa8:78b1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dafna) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id E54671F44AE1; Thu, 30 Sep 2021 12:26:09 +0100 (BST) Subject: Re: [PATCH v2 11/29] iommu/mediatek: Always pm_runtime_get while tlb flush To: Yong Wu , Joerg Roedel , Rob Herring , Matthias Brugger , Will Deacon , Robin Murphy Cc: Krzysztof Kozlowski , Evan Green , Tomasz Figa , Tomasz Figa , linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, youlin.pei@mediatek.com, Nicolas Boichat , anan.sun@mediatek.com, chao.hao@mediatek.com References: <20210813065324.29220-1-yong.wu@mediatek.com> <20210813065324.29220-12-yong.wu@mediatek.com> From: Dafna Hirschfeld Message-ID: <11fe281d-4873-245b-f506-452900f33d3b@collabora.com> Date: Thu, 30 Sep 2021 13:26:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210813065324.29220-12-yong.wu@mediatek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13.08.21 08:53, Yong Wu wrote: > Prepare for 2 HWs that sharing pgtable in different power-domains. > > The previous SoC don't have PM. Only mt8192 has power-domain, > and it is display's power-domain which nearly always is enabled. hi, I see that in mt1873.dtsi, many devices that uses the iommu have the 'power-domains' property. > > When there are 2 M4U HWs, it may has problem. > In this function, we get the pm_status via the m4u dev, but it don't > reflect the real power-domain status of the HW since there may be other > HW also use that power-domain. > > Currently we could not get the real power-domain status, thus always > pm_runtime_get here. > > Prepare for mt8195, thus, no need fix tags here. > > This patch may drop the performance, we expect the user could > pm_runtime_get_sync before dma_alloc_attrs which need tlb ops. > Could you explain this sentence a bit? should the user call pm_runtime_get_sync before calling dma_alloc_attrs? Thanks, Dafna > Signed-off-by: Yong Wu > --- > drivers/iommu/mtk_iommu.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > index add23a36a5e2..abc721a1da21 100644 > --- a/drivers/iommu/mtk_iommu.c > +++ b/drivers/iommu/mtk_iommu.c > @@ -238,8 +238,11 @@ static void mtk_iommu_tlb_flush_range_sync(unsigned long iova, size_t size, > > for_each_m4u(data, head) { > if (has_pm) { > - if (pm_runtime_get_if_in_use(data->dev) <= 0) > + ret = pm_runtime_resume_and_get(data->dev); > + if (ret < 0) { > + dev_err(data->dev, "tlb flush: pm get fail %d.\n", ret); > continue; > + } > } > > spin_lock_irqsave(&data->tlb_lock, flags); >