From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C74A9C433F5 for ; Wed, 10 Nov 2021 02:20:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A34FD611BF for ; Wed, 10 Nov 2021 02:20:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229652AbhKJCXY (ORCPT ); Tue, 9 Nov 2021 21:23:24 -0500 Received: from mailgw02.mediatek.com ([210.61.82.184]:53886 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S229630AbhKJCXY (ORCPT ); Tue, 9 Nov 2021 21:23:24 -0500 X-UUID: 856a6dbc4c6341eca4ca1e898b447dc0-20211110 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=h6o8crzH0QQXPSjg4BmL9i5l114/7v3dfLGSUMXg6lQ=; b=pu1+LqOeJ5IzE1w+yl088gqqRaOXP3f1DjYslC7BeDPQLvV02UHhhWX3FbEr7CzoXmGI43dLpsXURFoD1IDGNJ6RqruW9vUOlSpnkzvCNKO/RoBDtqkEy74B5vLQFaXSDCnNh4pnaBxZzWAjFrLR9eVJADb3igUhQPtjAJKAbm8=; X-UUID: 856a6dbc4c6341eca4ca1e898b447dc0-20211110 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1352684706; Wed, 10 Nov 2021 10:20:35 +0800 Received: from mtkmbs10n2.mediatek.inc (172.21.101.183) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 10 Nov 2021 10:20:33 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkmbs10n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.3 via Frontend Transport; Wed, 10 Nov 2021 10:20:32 +0800 Message-ID: <5c4dd67ae7c81721d8cfd2c3b23b7c6df493cb5a.camel@mediatek.com> Subject: Re: [PATCH v3 12/33] iommu/mediatek: Always tlb_flush_all when each PM resume From: Yong Wu To: Dafna Hirschfeld , Joerg Roedel , Rob Herring , Matthias Brugger , Will Deacon , Robin Murphy CC: Krzysztof Kozlowski , Tomasz Figa , , , , , , Hsin-Yi Wang , , , , "AngeloGioacchino Del Regno" , Fabien Parent , , "Collabora Kernel ML" Date: Wed, 10 Nov 2021 10:20:32 +0800 In-Reply-To: References: <20210923115840.17813-1-yong.wu@mediatek.com> <20210923115840.17813-13-yong.wu@mediatek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N Content-Transfer-Encoding: base64 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org T24gVHVlLCAyMDIxLTExLTA5IGF0IDE0OjIxICswMjAwLCBEYWZuYSBIaXJzY2hmZWxkIHdyb3Rl Og0KPiBIaQ0KPiBUaGlzIHBhdGNoIGlzIG5lZWRlZCBpbiBvcmRlciB0byB1cGRhdGUgdGhlIHRs YiB3aGVuIGEgZGV2aWNlIGlzDQo+IHBvd2VyZWQgb24uDQo+IENvdWxkIHlvdSBzZW5kIHRoaXMg cGF0Y2ggYWxvbmUgd2l0aG91dCB0aGUgd2hvbGUgc2VyaWVzIHNvIGl0IGdldA0KPiBhY2NlcHRl ZCBlYXNpZXI/DQoNCldoaWNoIFNvQyBhcmUgeW91IHRlc3Rpbmcgb24/IEluIHByZXZpb3VzIFNv QywgdGhlIElPTU1VIEhXIGRvbid0IGhhdmUNCnBvd2VyLWRvbWFpbiwgYW5kIHdlIGhhdmUgYSAi aGFzX3BtIlsxXSBpbiB0aGUgdGxiIGZ1bmN0aW9uIGZvciB0aGF0DQpjYXNlLiBUaGUgImhhc19w bSIgc2hvdWxkIGJlIGFsd2F5cyAwIGZvciB0aGUgcHJldmlvdXMgU29DIGxpa2UgbXQ4MTczLA0K aXQgc2hvdWxkIGFsd2F5cyB0bGIgc3luY2hyb25pemUuDQoNCnRodXMsIENvdWxkIHlvdSBoZWxw IHNoYXJlIG1vcmUgYWJvdXQgeW91ciBpc3N1ZT8gSW4gd2hpY2ggY2FzZSBpdCBsYWNrDQp0aGUg bmVjZXNzYXJ5IHRsYiBvcGVyYXRpb24uIEF0IGxlYXN0LCBXZSBuZWVkIGNvbmZpcm0gaWYgaXQg bmVlZHMgYQ0KIkZpeGVzIiB0YWdzIGlmIHNlbmRpbmcgdGhpcyBwYXRjaCBhbG9uZS4NCg0KVGhh bmtzLg0KDQpbMV0gDQpodHRwczovL2VsaXhpci5ib290bGluLmNvbS9saW51eC92NS4xNS9zb3Vy Y2UvZHJpdmVycy9pb21tdS9tdGtfaW9tbXUuYyNMMjM2DQoNCj4gSSBjYW4gcmVzZW5kIHRoZSBw YXRjaCBvbiB5b3VyIGJlaGFsZiBpZiB5b3Ugd2FudC4NCj4gDQo+IFRoYW5rcywNCj4gRGFmbmEN Cj4gDQo+IE9uIDIzLjA5LjIxIDE0OjU4LCBZb25nIFd1IHdyb3RlOg0KPiA+IFByZXBhcmUgZm9y IDIgSFdzIHRoYXQgc2hhcmluZyBwZ3RhYmxlIGluIGRpZmZlcmVudCBwb3dlci1kb21haW5zLg0K PiA+IA0KPiA+IFdoZW4gdGhlcmUgYXJlIDIgTTRVIEhXcywgaXQgbWF5IGhhcyBwcm9ibGVtIGlu IHRoZSBmbHVzaF9yYW5nZSBpbg0KPiA+IHdoaWNoDQo+ID4gd2UgZ2V0IHRoZSBwbV9zdGF0dXMg dmlhIHRoZSBtNHUgZGV2LCBCVVQgdGhhdCBmdW5jdGlvbiBkb24ndA0KPiA+IHJlZmxlY3QgdGhl DQo+ID4gcmVhbCBwb3dlci1kb21haW4gc3RhdHVzIG9mIHRoZSBIVyBzaW5jZSB0aGVyZSBtYXkg YmUgb3RoZXIgSFcgYWxzbw0KPiA+IHVzZQ0KPiA+IHRoYXQgcG93ZXItZG9tYWluLg0KPiA+IA0K PiA+IFRoZSBmdW5jdGlvbiBkbWFfYWxsb2NfYXR0cnMgaGVscCBhbGxvY2F0ZSB0aGUgaW9tbXUg YnVmZmVyIHdoaWNoDQo+ID4gbmVlZCB0aGUgY29ycmVzcG9uZGluZyBwb3dlciBkb21haW4gc2lu Y2UgdGxiIGZsdXNoIGlzIG5lZWRlZCB3aGVuDQo+ID4gcHJlcGFyaW5nIGlvdmEuIEJVVCB0aGlz IGZ1bmN0aW9uIG9ubHkgaXMgZm9yIGFsbG9jYXRpbmcgYnVmZmVyLA0KPiA+IHdlIGhhdmUgbm8g Z29vZCByZWFzb24gdG8gcmVxdWVzdCB0aGUgdXNlciBhbHdheXMgY2FsbA0KPiA+IHBtX3J1bnRp bWVfZ2V0DQo+ID4gYmVmb3JlIGNhbGxpbmcgZG1hX2FsbG9jX3h4eC4gVGhlcmVmb3JlLCB3ZSBh ZGQgYSB0bGJfZmx1c2hfYWxsDQo+ID4gaW4gdGhlIHBtX3J1bnRpbWVfcmVzdW1lIHRvIG1ha2Ug c3VyZSB0aGUgdGxiIGFsd2F5cyBpcyBjbGVhbi4NCj4gPiANCj4gPiBBbm90aGVyIHNvbHV0aW9u IGlzIGFsd2F5cyBjYWxsIHBtX3J1bnRpbWVfZ2V0IGluIHRoZQ0KPiA+IHRsYl9mbHVzaF9yYW5n ZS4NCj4gPiBUaGlzIHdpbGwgdHJpZ2dlciBwbSBydW50aW1lIHJlc3VtZS9iYWNrdXAgc28gb2Z0 ZW4gd2hlbiB0aGUgaW9tbXUNCj4gPiBwb3dlciBpcyBub3QgYWN0aXZlIGF0IHNvbWUgdGltZSht ZWFucyB1c2VyIGRvbid0IGNhbGwNCj4gPiBwbV9ydW50aW1lX2dldA0KPiA+IGJlZm9yZSBjYWxs aW5nIGRtYV9hbGxvY194eHgpLCBUaGlzIG1heSBjYXVzZSB0aGUgcGVyZm9ybWFuY2UgZHJvcC4N Cj4gPiB0aHVzIHdlIGRvbid0IHVzZSB0aGlzLg0KPiA+IA0KPiA+IEluIG90aGVyIGNhc2UsIHRo ZSBpb21tdSdzIHBvd2VyIHNob3VsZCBhbHdheXMgYmUgYWN0aXZlIHZpYSBkZXZpY2UNCj4gPiBs aW5rIHdpdGggc21pLg0KPiA+IA0KPiA+IFRoZSBwcmV2aW91cyBTb0MgZG9uJ3QgaGF2ZSBQTSBl eGNlcHQgbXQ4MTkyLiB0aGUgbXQ4MTkyIElPTU1VIGlzDQo+ID4gZGlzcGxheSdzDQo+ID4gcG93 ZXItZG9tYWluIHdoaWNoIG5lYXJseSBhbHdheXMgaXMgZW5hYmxlZC4gdGh1cyBubyBuZWVkIGZp eCB0YWdzDQo+ID4gaGVyZS4NCj4gPiBQcmVwYXJlIGZvciBtdDgxOTUuDQo+ID4gDQo+ID4gU2ln bmVkLW9mZi1ieTogWW9uZyBXdSA8eW9uZy53dUBtZWRpYXRlay5jb20+DQo+ID4gLS0tDQo+ID4g ICBkcml2ZXJzL2lvbW11L210a19pb21tdS5jIHwgMTEgKysrKysrKysrKysNCj4gPiAgIDEgZmls ZSBjaGFuZ2VkLCAxMSBpbnNlcnRpb25zKCspDQo+ID4gDQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZl cnMvaW9tbXUvbXRrX2lvbW11LmMgYi9kcml2ZXJzL2lvbW11L210a19pb21tdS5jDQo+ID4gaW5k ZXggNDRjZjU1NDdkMDg0Li5lOWU5NDk0NGVkOTEgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9p b21tdS9tdGtfaW9tbXUuYw0KPiA+ICsrKyBiL2RyaXZlcnMvaW9tbXUvbXRrX2lvbW11LmMNCj4g PiBAQCAtOTg0LDYgKzk4NCwxNyBAQCBzdGF0aWMgaW50IF9fbWF5YmVfdW51c2VkDQo+ID4gbXRr X2lvbW11X3J1bnRpbWVfcmVzdW1lKHN0cnVjdCBkZXZpY2UgKmRldikNCj4gPiAgIAkJcmV0dXJu IHJldDsNCj4gPiAgIAl9DQo+ID4gICANCj4gPiArCS8qDQo+ID4gKwkgKiBVc2VycyBtYXkgYWxs b2NhdGUgZG1hIGJ1ZmZlciBiZWZvcmUgdGhleSBjYWxsDQo+ID4gcG1fcnVudGltZV9nZXQsIHRo ZW4NCj4gPiArCSAqIGl0IHdpbGwgbGFjayB0aGUgbmVjZXNzYXJ5IHRsYiBmbHVzaC4NCj4gPiAr CSAqDQo+ID4gKwkgKiBXZSBoYXZlIG5vIGdvb2QgcmVhc29uIHRvIHJlcXVlc3QgdGhlIHVzZXJz IGFsd2F5cyBjYWxsDQo+ID4gZG1hX2FsbG9jX3h4DQo+ID4gKwkgKiBhZnRlciBwbV9ydW50aW1l X2dldF9zeW5jLg0KPiA+ICsJICoNCj4gPiArCSAqIFRodXMsIE1ha2Ugc3VyZSB0aGUgdGxiIGFs d2F5cyBpcyBjbGVhbiBhZnRlciBlYWNoIFBNDQo+ID4gcmVzdW1lLg0KPiA+ICsJICovDQo+ID4g KwltdGtfaW9tbXVfdGxiX2RvX2ZsdXNoX2FsbChkYXRhKTsNCj4gPiArDQo+ID4gICAJLyoNCj4g PiAgIAkgKiBVcHBvbiBmaXJzdCByZXN1bWUsIG9ubHkgZW5hYmxlIHRoZSBjbGsgYW5kIHJldHVy biwgc2luY2UNCj4gPiB0aGUgdmFsdWVzIG9mIHRoZQ0KPiA+ICAgCSAqIHJlZ2lzdGVycyBhcmUg bm90IHlldCBzZXQuDQo+ID4gDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B57C3C433F5 for ; Wed, 10 Nov 2021 02:20:51 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6323F610A2 for ; Wed, 10 Nov 2021 02:20:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6323F610A2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 1E561403E0; Wed, 10 Nov 2021 02:20:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B46wcAYVOTzu; Wed, 10 Nov 2021 02:20:49 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp2.osuosl.org (Postfix) with ESMTPS id 8CB1E40114; Wed, 10 Nov 2021 02:20:49 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5C5CBC0012; Wed, 10 Nov 2021 02:20:49 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7B081C000E for ; Wed, 10 Nov 2021 02:20:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 70DEE4044C for ; Wed, 10 Nov 2021 02:20:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=mediatek.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_mPRDFloWhz for ; Wed, 10 Nov 2021 02:20:40 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by smtp4.osuosl.org (Postfix) with ESMTPS id 2653C40448 for ; Wed, 10 Nov 2021 02:20:39 +0000 (UTC) X-UUID: 856a6dbc4c6341eca4ca1e898b447dc0-20211110 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=h6o8crzH0QQXPSjg4BmL9i5l114/7v3dfLGSUMXg6lQ=; b=pu1+LqOeJ5IzE1w+yl088gqqRaOXP3f1DjYslC7BeDPQLvV02UHhhWX3FbEr7CzoXmGI43dLpsXURFoD1IDGNJ6RqruW9vUOlSpnkzvCNKO/RoBDtqkEy74B5vLQFaXSDCnNh4pnaBxZzWAjFrLR9eVJADb3igUhQPtjAJKAbm8=; X-UUID: 856a6dbc4c6341eca4ca1e898b447dc0-20211110 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1352684706; Wed, 10 Nov 2021 10:20:35 +0800 Received: from mtkmbs10n2.mediatek.inc (172.21.101.183) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 10 Nov 2021 10:20:33 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkmbs10n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.3 via Frontend Transport; Wed, 10 Nov 2021 10:20:32 +0800 Message-ID: <5c4dd67ae7c81721d8cfd2c3b23b7c6df493cb5a.camel@mediatek.com> Subject: Re: [PATCH v3 12/33] iommu/mediatek: Always tlb_flush_all when each PM resume From: Yong Wu To: Dafna Hirschfeld , Joerg Roedel , Rob Herring , Matthias Brugger , Will Deacon , Robin Murphy Date: Wed, 10 Nov 2021 10:20:32 +0800 In-Reply-To: References: <20210923115840.17813-1-yong.wu@mediatek.com> <20210923115840.17813-13-yong.wu@mediatek.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N Cc: youlin.pei@mediatek.com, devicetree@vger.kernel.org, srv_heupstream@mediatek.com, Krzysztof Kozlowski , anan.sun@mediatek.com, yen-chang.chen@mediatek.com, Fabien Parent , iommu@lists.linux-foundation.org, linux-mediatek@lists.infradead.org, Hsin-Yi Wang , Collabora Kernel ML , sebastian.reichel@collabora.com, linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Tue, 2021-11-09 at 14:21 +0200, Dafna Hirschfeld wrote: > Hi > This patch is needed in order to update the tlb when a device is > powered on. > Could you send this patch alone without the whole series so it get > accepted easier? Which SoC are you testing on? In previous SoC, the IOMMU HW don't have power-domain, and we have a "has_pm"[1] in the tlb function for that case. The "has_pm" should be always 0 for the previous SoC like mt8173, it should always tlb synchronize. thus, Could you help share more about your issue? In which case it lack the necessary tlb operation. At least, We need confirm if it needs a "Fixes" tags if sending this patch alone. Thanks. [1] https://elixir.bootlin.com/linux/v5.15/source/drivers/iommu/mtk_iommu.c#L236 > I can resend the patch on your behalf if you want. > > Thanks, > Dafna > > On 23.09.21 14:58, Yong Wu wrote: > > Prepare for 2 HWs that sharing pgtable in different power-domains. > > > > When there are 2 M4U HWs, it may has problem in the flush_range in > > which > > we get the pm_status via the m4u dev, BUT that function don't > > reflect the > > real power-domain status of the HW since there may be other HW also > > use > > that power-domain. > > > > The function dma_alloc_attrs help allocate the iommu buffer which > > need the corresponding power domain since tlb flush is needed when > > preparing iova. BUT this function only is for allocating buffer, > > we have no good reason to request the user always call > > pm_runtime_get > > before calling dma_alloc_xxx. Therefore, we add a tlb_flush_all > > in the pm_runtime_resume to make sure the tlb always is clean. > > > > Another solution is always call pm_runtime_get in the > > tlb_flush_range. > > This will trigger pm runtime resume/backup so often when the iommu > > power is not active at some time(means user don't call > > pm_runtime_get > > before calling dma_alloc_xxx), This may cause the performance drop. > > thus we don't use this. > > > > In other case, the iommu's power should always be active via device > > link with smi. > > > > The previous SoC don't have PM except mt8192. the mt8192 IOMMU is > > display's > > power-domain which nearly always is enabled. thus no need fix tags > > here. > > Prepare for mt8195. > > > > Signed-off-by: Yong Wu > > --- > > drivers/iommu/mtk_iommu.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index 44cf5547d084..e9e94944ed91 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -984,6 +984,17 @@ static int __maybe_unused > > mtk_iommu_runtime_resume(struct device *dev) > > return ret; > > } > > > > + /* > > + * Users may allocate dma buffer before they call > > pm_runtime_get, then > > + * it will lack the necessary tlb flush. > > + * > > + * We have no good reason to request the users always call > > dma_alloc_xx > > + * after pm_runtime_get_sync. > > + * > > + * Thus, Make sure the tlb always is clean after each PM > > resume. > > + */ > > + mtk_iommu_tlb_do_flush_all(data); > > + > > /* > > * Uppon first resume, only enable the clk and return, since > > the values of the > > * registers are not yet set. > > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1EDE8C433EF for ; Wed, 10 Nov 2021 02:21:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DE97561181 for ; Wed, 10 Nov 2021 02:21:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DE97561181 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:CC:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GlNTZgYLUWggB/W74+kg8xM0O7gkbH6V5vMR+aCEwI8=; b=DZfTxrHHUdKoKV a6e43Io5U0Pq+u/Fr07Uza1+5/PPFGGu+vr+l3GWsw/PDZolo9s9AtgycqLCv/PWR3ra99bUfUswq 8XWl20HmdCATbrjx+xJ+Ae6qS5OeRfC5KRRk6RpJfGbtn1f1FEo+opJDJMByCUgsBCA9D3FsL+peo JdkAXo5+VZrV2VAUI2Z7jnUfA6ssCcTY3OBJ0JVyj9/yNjvg4pF6zc38YJYVdZo5XIYb/kEX8ovvT pKTdpdRSh3DcYU01Yr6leAL6e08hu522jmaSIrDp8IBJqxuhHBzva53zJOCGf6MiOWWewUBbV7ZzV Xt9eFEwk6iQKQZ2fuymQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkdEL-004J2l-Sv; Wed, 10 Nov 2021 02:20:53 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkdE8-004J17-6e; Wed, 10 Nov 2021 02:20:41 +0000 X-UUID: 9a56d7f732c2406bb70758bbdf327429-20211109 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=h6o8crzH0QQXPSjg4BmL9i5l114/7v3dfLGSUMXg6lQ=; b=pu1+LqOeJ5IzE1w+yl088gqqRaOXP3f1DjYslC7BeDPQLvV02UHhhWX3FbEr7CzoXmGI43dLpsXURFoD1IDGNJ6RqruW9vUOlSpnkzvCNKO/RoBDtqkEy74B5vLQFaXSDCnNh4pnaBxZzWAjFrLR9eVJADb3igUhQPtjAJKAbm8=; X-UUID: 9a56d7f732c2406bb70758bbdf327429-20211109 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 485300894; Tue, 09 Nov 2021 19:20:37 -0700 Received: from mtkmbs10n2.mediatek.inc (172.21.101.183) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 9 Nov 2021 18:20:34 -0800 Received: from mtkmbs10n2.mediatek.inc (172.21.101.183) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 10 Nov 2021 10:20:33 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkmbs10n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.3 via Frontend Transport; Wed, 10 Nov 2021 10:20:32 +0800 Message-ID: <5c4dd67ae7c81721d8cfd2c3b23b7c6df493cb5a.camel@mediatek.com> Subject: Re: [PATCH v3 12/33] iommu/mediatek: Always tlb_flush_all when each PM resume From: Yong Wu To: Dafna Hirschfeld , Joerg Roedel , Rob Herring , Matthias Brugger , Will Deacon , Robin Murphy CC: Krzysztof Kozlowski , Tomasz Figa , , , , , , Hsin-Yi Wang , , , , "AngeloGioacchino Del Regno" , Fabien Parent , , "Collabora Kernel ML" Date: Wed, 10 Nov 2021 10:20:32 +0800 In-Reply-To: References: <20210923115840.17813-1-yong.wu@mediatek.com> <20210923115840.17813-13-yong.wu@mediatek.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211109_182040_274082_09B2AFC0 X-CRM114-Status: GOOD ( 41.22 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Tue, 2021-11-09 at 14:21 +0200, Dafna Hirschfeld wrote: > Hi > This patch is needed in order to update the tlb when a device is > powered on. > Could you send this patch alone without the whole series so it get > accepted easier? Which SoC are you testing on? In previous SoC, the IOMMU HW don't have power-domain, and we have a "has_pm"[1] in the tlb function for that case. The "has_pm" should be always 0 for the previous SoC like mt8173, it should always tlb synchronize. thus, Could you help share more about your issue? In which case it lack the necessary tlb operation. At least, We need confirm if it needs a "Fixes" tags if sending this patch alone. Thanks. [1] https://elixir.bootlin.com/linux/v5.15/source/drivers/iommu/mtk_iommu.c#L236 > I can resend the patch on your behalf if you want. > > Thanks, > Dafna > > On 23.09.21 14:58, Yong Wu wrote: > > Prepare for 2 HWs that sharing pgtable in different power-domains. > > > > When there are 2 M4U HWs, it may has problem in the flush_range in > > which > > we get the pm_status via the m4u dev, BUT that function don't > > reflect the > > real power-domain status of the HW since there may be other HW also > > use > > that power-domain. > > > > The function dma_alloc_attrs help allocate the iommu buffer which > > need the corresponding power domain since tlb flush is needed when > > preparing iova. BUT this function only is for allocating buffer, > > we have no good reason to request the user always call > > pm_runtime_get > > before calling dma_alloc_xxx. Therefore, we add a tlb_flush_all > > in the pm_runtime_resume to make sure the tlb always is clean. > > > > Another solution is always call pm_runtime_get in the > > tlb_flush_range. > > This will trigger pm runtime resume/backup so often when the iommu > > power is not active at some time(means user don't call > > pm_runtime_get > > before calling dma_alloc_xxx), This may cause the performance drop. > > thus we don't use this. > > > > In other case, the iommu's power should always be active via device > > link with smi. > > > > The previous SoC don't have PM except mt8192. the mt8192 IOMMU is > > display's > > power-domain which nearly always is enabled. thus no need fix tags > > here. > > Prepare for mt8195. > > > > Signed-off-by: Yong Wu > > --- > > drivers/iommu/mtk_iommu.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index 44cf5547d084..e9e94944ed91 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -984,6 +984,17 @@ static int __maybe_unused > > mtk_iommu_runtime_resume(struct device *dev) > > return ret; > > } > > > > + /* > > + * Users may allocate dma buffer before they call > > pm_runtime_get, then > > + * it will lack the necessary tlb flush. > > + * > > + * We have no good reason to request the users always call > > dma_alloc_xx > > + * after pm_runtime_get_sync. > > + * > > + * Thus, Make sure the tlb always is clean after each PM > > resume. > > + */ > > + mtk_iommu_tlb_do_flush_all(data); > > + > > /* > > * Uppon first resume, only enable the clk and return, since > > the values of the > > * registers are not yet set. > > _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7713C433F5 for ; Wed, 10 Nov 2021 02:22:27 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6143F60E54 for ; Wed, 10 Nov 2021 02:22:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6143F60E54 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:CC:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pCFySnVGEzEaHV2JTWVz3/ia1e17Ev33N+8cBjG/VEA=; b=JW5fvbsucwurUo wZtkZHZI56b9ZgLZC6pK/rsHKjHij/eceyuaIfAtsIGulDHQMjX3gZgNNZrLJxz8Q2wx2z2/lHj0j EveHQSHAoqpfw60/Mg0rAO/2kqzKEzGzTYqEtfSlA50JJ/fCUw5Aj/TLDhrfyDw2b/2JjVvfMfMCR 73Q5l60f4lnfR8dwMRH5oOvb3j9h49rvuaRi8Hy1FTwUs5eyeQ6ea4lk2KkCPUxiG+UX1loHhyAMV cdyWXzxWkYSnohnWycDnjglWmyhRKALdICtH0Rmcb4E05DrJb2YIXWv3hSFotQ8LQWeMb1jV97kop zdXLu6I8Bqi47dT9zBog==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkdEC-004J1m-Qx; Wed, 10 Nov 2021 02:20:45 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mkdE8-004J17-6e; Wed, 10 Nov 2021 02:20:41 +0000 X-UUID: 9a56d7f732c2406bb70758bbdf327429-20211109 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=h6o8crzH0QQXPSjg4BmL9i5l114/7v3dfLGSUMXg6lQ=; b=pu1+LqOeJ5IzE1w+yl088gqqRaOXP3f1DjYslC7BeDPQLvV02UHhhWX3FbEr7CzoXmGI43dLpsXURFoD1IDGNJ6RqruW9vUOlSpnkzvCNKO/RoBDtqkEy74B5vLQFaXSDCnNh4pnaBxZzWAjFrLR9eVJADb3igUhQPtjAJKAbm8=; X-UUID: 9a56d7f732c2406bb70758bbdf327429-20211109 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 485300894; Tue, 09 Nov 2021 19:20:37 -0700 Received: from mtkmbs10n2.mediatek.inc (172.21.101.183) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 9 Nov 2021 18:20:34 -0800 Received: from mtkmbs10n2.mediatek.inc (172.21.101.183) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 10 Nov 2021 10:20:33 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkmbs10n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.3 via Frontend Transport; Wed, 10 Nov 2021 10:20:32 +0800 Message-ID: <5c4dd67ae7c81721d8cfd2c3b23b7c6df493cb5a.camel@mediatek.com> Subject: Re: [PATCH v3 12/33] iommu/mediatek: Always tlb_flush_all when each PM resume From: Yong Wu To: Dafna Hirschfeld , Joerg Roedel , Rob Herring , Matthias Brugger , Will Deacon , Robin Murphy CC: Krzysztof Kozlowski , Tomasz Figa , , , , , , Hsin-Yi Wang , , , , "AngeloGioacchino Del Regno" , Fabien Parent , , "Collabora Kernel ML" Date: Wed, 10 Nov 2021 10:20:32 +0800 In-Reply-To: References: <20210923115840.17813-1-yong.wu@mediatek.com> <20210923115840.17813-13-yong.wu@mediatek.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211109_182040_274082_09B2AFC0 X-CRM114-Status: GOOD ( 41.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 2021-11-09 at 14:21 +0200, Dafna Hirschfeld wrote: > Hi > This patch is needed in order to update the tlb when a device is > powered on. > Could you send this patch alone without the whole series so it get > accepted easier? Which SoC are you testing on? In previous SoC, the IOMMU HW don't have power-domain, and we have a "has_pm"[1] in the tlb function for that case. The "has_pm" should be always 0 for the previous SoC like mt8173, it should always tlb synchronize. thus, Could you help share more about your issue? In which case it lack the necessary tlb operation. At least, We need confirm if it needs a "Fixes" tags if sending this patch alone. Thanks. [1] https://elixir.bootlin.com/linux/v5.15/source/drivers/iommu/mtk_iommu.c#L236 > I can resend the patch on your behalf if you want. > > Thanks, > Dafna > > On 23.09.21 14:58, Yong Wu wrote: > > Prepare for 2 HWs that sharing pgtable in different power-domains. > > > > When there are 2 M4U HWs, it may has problem in the flush_range in > > which > > we get the pm_status via the m4u dev, BUT that function don't > > reflect the > > real power-domain status of the HW since there may be other HW also > > use > > that power-domain. > > > > The function dma_alloc_attrs help allocate the iommu buffer which > > need the corresponding power domain since tlb flush is needed when > > preparing iova. BUT this function only is for allocating buffer, > > we have no good reason to request the user always call > > pm_runtime_get > > before calling dma_alloc_xxx. Therefore, we add a tlb_flush_all > > in the pm_runtime_resume to make sure the tlb always is clean. > > > > Another solution is always call pm_runtime_get in the > > tlb_flush_range. > > This will trigger pm runtime resume/backup so often when the iommu > > power is not active at some time(means user don't call > > pm_runtime_get > > before calling dma_alloc_xxx), This may cause the performance drop. > > thus we don't use this. > > > > In other case, the iommu's power should always be active via device > > link with smi. > > > > The previous SoC don't have PM except mt8192. the mt8192 IOMMU is > > display's > > power-domain which nearly always is enabled. thus no need fix tags > > here. > > Prepare for mt8195. > > > > Signed-off-by: Yong Wu > > --- > > drivers/iommu/mtk_iommu.c | 11 +++++++++++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index 44cf5547d084..e9e94944ed91 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -984,6 +984,17 @@ static int __maybe_unused > > mtk_iommu_runtime_resume(struct device *dev) > > return ret; > > } > > > > + /* > > + * Users may allocate dma buffer before they call > > pm_runtime_get, then > > + * it will lack the necessary tlb flush. > > + * > > + * We have no good reason to request the users always call > > dma_alloc_xx > > + * after pm_runtime_get_sync. > > + * > > + * Thus, Make sure the tlb always is clean after each PM > > resume. > > + */ > > + mtk_iommu_tlb_do_flush_all(data); > > + > > /* > > * Uppon first resume, only enable the clk and return, since > > the values of the > > * registers are not yet set. > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel