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 9E5D4C433EF for ; Mon, 25 Oct 2021 03:57:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8433C61002 for ; Mon, 25 Oct 2021 03:57:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230120AbhJYEAI (ORCPT ); Mon, 25 Oct 2021 00:00:08 -0400 Received: from mailgw01.mediatek.com ([60.244.123.138]:56082 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S229379AbhJYEAG (ORCPT ); Mon, 25 Oct 2021 00:00:06 -0400 X-UUID: 6cf5dab4038e407b895180c1d1649248-20211025 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=cV6dg7PsYHB6+UKop/Sg0rROLJ+oreSSfppKhlC8xGE=; b=nBkGbQeC+Sa3c4WFbs6Ky01mc0hcpUC1VdMIVgp0Ci+nREwXGSXct8xkBhX2s3ToXb8z7bOAWuCxF6sm2/w1ZbvpyLWXSZSkGdcufbA7YrxHi4qeoC1Ri9RoqAAxoOpOmRoxjwmLJ+sjifSy3adpDDGLiZMJznJ7HwbTckMDANs=; X-UUID: 6cf5dab4038e407b895180c1d1649248-20211025 Received: from mtkmbs10n1.mediatek.inc [(172.21.101.34)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 77251011; Mon, 25 Oct 2021 11:57:42 +0800 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 25 Oct 2021 11:57:40 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 25 Oct 2021 11:57:39 +0800 Message-ID: <15d4ccb984f9e3919d6d7535d05aec0332dbe301.camel@mediatek.com> Subject: Re: [PATCH v8 04/12] iommu/mediatek: Add device_link between the consumer and the larb devices From: Yong Wu To: Dafna Hirschfeld , Matthias Brugger , Joerg Roedel , Rob Herring , Krzysztof Kozlowski , David Airlie , "Mauro Carvalho Chehab" CC: Evan Green , Robin Murphy , Tomasz Figa , Will Deacon , , , , , , , , Matthias Kaehlcke , , , , , , "Daniel Vetter" , Chun-Kuang Hu , "Philipp Zabel" , Tiffany Lin , Hsin-Yi Wang , Eizan Miyamoto , , Frank Wunderlich Date: Mon, 25 Oct 2021 11:57:39 +0800 In-Reply-To: References: <20210929013719.25120-1-yong.wu@mediatek.com> <20210929013719.25120-5-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: linux-kernel@vger.kernel.org T24gTW9uLCAyMDIxLTEwLTE4IGF0IDA5OjEzICswMjAwLCBEYWZuYSBIaXJzY2hmZWxkIHdyb3Rl Og0KPiANCj4gT24gMTYuMTAuMjEgMDQ6MjMsIFlvbmcgV3Ugd3JvdGU6DQo+ID4gT24gTW9uLCAy MDIxLTEwLTExIGF0IDE0OjM2ICswMjAwLCBEYWZuYSBIaXJzY2hmZWxkIHdyb3RlOg0KPiA+ID4g DQo+ID4gPiBPbiAyOS4wOS4yMSAwMzozNywgWW9uZyBXdSB3cm90ZToNCj4gPiA+ID4gTWVkaWFU ZWsgSU9NTVUtU01JIGRpYWdyYW0gaXMgbGlrZSBiZWxvdy4gYWxsIHRoZSBjb25zdW1lcg0KPiA+ ID4gPiBjb25uZWN0DQo+ID4gPiA+IHdpdGgNCj4gPiA+ID4gc21pLWxhcmIsIHRoZW4gY29ubmVj dCB3aXRoIHNtaS1jb21tb24uDQo+ID4gPiA+IA0KPiA+ID4gPiAgICAgICAgICAgTTRVDQo+ID4g PiA+ICAgICAgICAgICAgfA0KPiA+ID4gPiAgICAgICBzbWktY29tbW9uDQo+ID4gPiA+ICAgICAg ICAgICAgfA0KPiA+ID4gPiAgICAgLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiAgICAgfCAgICAgICAg IHwgICAgLi4uDQo+ID4gPiA+ICAgICB8ICAgICAgICAgfA0KPiA+ID4gPiBsYXJiMSAgICAgbGFy YjINCj4gPiA+ID4gICAgIHwgICAgICAgICB8DQo+ID4gPiA+IHZkZWMgICAgICAgdmVuYw0KPiA+ ID4gPiANCj4gPiA+ID4gV2hlbiB0aGUgY29uc3VtZXIgd29ya3MsIGl0IHNob3VsZCBlbmFibGUg dGhlIHNtaS1sYXJiJ3MgcG93ZXINCj4gPiA+ID4gd2hpY2gNCj4gPiA+ID4gYWxzbyBuZWVkIGVu YWJsZSB0aGUgc21pLWNvbW1vbidzIHBvd2VyIGZpcnN0bHkuDQo+ID4gPiA+IA0KPiA+ID4gPiBU aHVzLCBGaXJzdCBvZiBhbGwsIHVzZSB0aGUgZGV2aWNlIGxpbmsgY29ubmVjdCB0aGUgY29uc3Vt ZXINCj4gPiA+ID4gYW5kDQo+ID4gPiA+IHRoZQ0KPiA+ID4gPiBzbWktbGFyYnMuIHRoZW4gYWRk IGRldmljZSBsaW5rIGJldHdlZW4gdGhlIHNtaS1sYXJiIGFuZCBzbWktDQo+ID4gPiA+IGNvbW1v bi4NCj4gPiA+ID4gDQo+ID4gPiA+IFRoaXMgcGF0Y2ggYWRkcyBkZXZpY2VfbGluayBiZXR3ZWVu IHRoZSBjb25zdW1lciBhbmQgdGhlIGxhcmJzLg0KPiA+ID4gPiANCj4gPiA+ID4gV2hlbiBkZXZp Y2VfbGlua19hZGQsIEkgYWRkIHRoZSBmbGFnIERMX0ZMQUdfU1RBVEVMRVNTIHRvIGF2b2lkDQo+ ID4gPiA+IGNhbGxpbmcNCj4gPiA+ID4gcG1fcnVudGltZV94eCB0byBrZWVwIHRoZSBvcmlnaW5h bCBzdGF0dXMgb2YgY2xvY2tzLiBJdCBjYW4NCj4gPiA+ID4gYXZvaWQNCj4gPiA+ID4gdHdvDQo+ ID4gPiA+IGlzc3VlczoNCj4gPiA+ID4gMSkgRGlzcGxheSBIVyBzaG93IGZhc3Rsb2dvIGFibm9y bWFsbHkgcmVwb3J0ZWQgaW4gWzFdLiBBdCB0aGUNCj4gPiA+ID4gYmVnZ2luaW5nLA0KPiA+ID4g PiBhbGwgdGhlIGNsb2NrcyBhcmUgZW5hYmxlZCBiZWZvcmUgZW50ZXJpbmcga2VybmVsLCBidXQg dGhlDQo+ID4gPiA+IGNsb2Nrcw0KPiA+ID4gPiBmb3INCj4gPiA+ID4gZGlzcGxheSBIVyhhbHdh eXMgaW4gbGFyYjApIHdpbGwgYmUgZ2F0ZWQgYWZ0ZXIgY2xrX2VuYWJsZSBhbmQNCj4gPiA+ID4g Y2xrX2Rpc2FibGUNCj4gPiA+ID4gY2FsbGVkIGZyb20gZGV2aWNlX2xpbmtfYWRkKC0+cG1fcnVu dGltZV9yZXN1bWUpIGFuZCBycG1faWRsZS4NCj4gPiA+ID4gVGhlDQo+ID4gPiA+IGNsb2NrDQo+ ID4gPiA+IG9wZXJhdGlvbiBoYXBwZW5lZCBiZWZvcmUgZGlzcGxheSBkcml2ZXIgcHJvYmUuIEF0 IHRoYXQgdGltZSwNCj4gPiA+ID4gdGhlDQo+ID4gPiA+IGRpc3BsYXkNCj4gPiA+ID4gSFcgd2ls bCBiZSBhYm5vcm1hbC4NCj4gPiA+ID4gDQo+ID4gPiA+IDIpIEEgZGVhZGxvY2sgaXNzdWUgcmVw b3J0ZWQgaW4gWzJdLiBVc2UgRExfRkxBR19TVEFURUxFU1MgdG8NCj4gPiA+ID4gc2tpcA0KPiA+ ID4gPiBwbV9ydW50aW1lX3h4IHRvIGF2b2lkIHRoZSBkZWFkbG9jay4NCj4gPiA+ID4gDQo+ID4g PiA+IENvcnJlc3BvbmRpbmcsIERMX0ZMQUdfQVVUT1JFTU9WRV9DT05TVU1FUiBjYW4ndCBiZSBh ZGRlZCwgdGhlbg0KPiA+ID4gPiBkZXZpY2VfbGlua19yZW1vdmVkIHNob3VsZCBiZSBhZGRlZCBl eHBsaWNpdGx5Lg0KPiA+ID4gPiANCj4gPiA+ID4gWzFdDQo+ID4gPiA+IA0KaHR0cHM6Ly9sb3Jl Lmtlcm5lbC5vcmcvbGludXgtbWVkaWF0ZWsvMTU2NDIxMzg4OC4yMjkwOC40LmNhbWVsQG1oZnNk Y2FwMDMvDQo+ID4gPiA+IFsyXSBodHRwczovL2xvcmUua2VybmVsLm9yZy9wYXRjaHdvcmsvcGF0 Y2gvMTA4NjU2OS8NCj4gPiA+ID4gDQo+ID4gPiA+IFN1Z2dlc3RlZC1ieTogVG9tYXN6IEZpZ2Eg PHRmaWdhQGNocm9taXVtLm9yZz4NCj4gPiA+ID4gU2lnbmVkLW9mZi1ieTogWW9uZyBXdSA8eW9u Zy53dUBtZWRpYXRlay5jb20+DQo+ID4gPiA+IFRlc3RlZC1ieTogRnJhbmsgV3VuZGVybGljaCA8 ZnJhbmstd0BwdWJsaWMtZmlsZXMuZGU+ICMgQlBJLQ0KPiA+ID4gPiBSMi9NVDc2MjMNCj4gPiA+ ID4gLS0tDQo+ID4gPiA+ICAgIGRyaXZlcnMvaW9tbXUvbXRrX2lvbW11LmMgICAgfCAyMiArKysr KysrKysrKysrKysrKysrKysrDQo+ID4gPiA+ICAgIGRyaXZlcnMvaW9tbXUvbXRrX2lvbW11X3Yx LmMgfCAyMCArKysrKysrKysrKysrKysrKysrLQ0KPiA+ID4gPiAgICAyIGZpbGVzIGNoYW5nZWQs IDQxIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gPiA+ID4gDQo+ID4gPiA+IGRpZmYg LS1naXQgYS9kcml2ZXJzL2lvbW11L210a19pb21tdS5jDQo+ID4gPiA+IGIvZHJpdmVycy9pb21t dS9tdGtfaW9tbXUuYw0KPiA+ID4gPiBpbmRleCBkNTg0OGY3OGE2NzcuLmEyZmE1NTg5OTQzNCAx MDA2NDQNCj4gPiA+ID4gLS0tIGEvZHJpdmVycy9pb21tdS9tdGtfaW9tbXUuYw0KPiA+ID4gPiAr KysgYi9kcml2ZXJzL2lvbW11L210a19pb21tdS5jDQo+ID4gPiA+IEBAIC01NjAsMjIgKzU2MCw0 NCBAQCBzdGF0aWMgc3RydWN0IGlvbW11X2RldmljZQ0KPiA+ID4gPiAqbXRrX2lvbW11X3Byb2Jl X2RldmljZShzdHJ1Y3QgZGV2aWNlICpkZXYpDQo+ID4gPiA+ICAgIHsNCj4gPiA+ID4gICAgCXN0 cnVjdCBpb21tdV9md3NwZWMgKmZ3c3BlYyA9DQo+ID4gPiA+IGRldl9pb21tdV9md3NwZWNfZ2V0 KGRldik7DQo+ID4gPiA+ICAgIAlzdHJ1Y3QgbXRrX2lvbW11X2RhdGEgKmRhdGE7DQo+ID4gPiA+ ICsJc3RydWN0IGRldmljZV9saW5rICpsaW5rOw0KPiA+ID4gPiArCXN0cnVjdCBkZXZpY2UgKmxh cmJkZXY7DQo+ID4gPiA+ICsJdW5zaWduZWQgaW50IGxhcmJpZDsNCj4gPiA+ID4gICAgDQo+ID4g PiA+ICAgIAlpZiAoIWZ3c3BlYyB8fCBmd3NwZWMtPm9wcyAhPSAmbXRrX2lvbW11X29wcykNCj4g PiA+ID4gICAgCQlyZXR1cm4gRVJSX1BUUigtRU5PREVWKTsgLyogTm90IGEgaW9tbXUgY2xpZW50 DQo+ID4gPiA+IGRldmljZQ0KPiA+ID4gPiAqLw0KPiA+ID4gPiAgICANCj4gPiA+ID4gICAgCWRh dGEgPSBkZXZfaW9tbXVfcHJpdl9nZXQoZGV2KTsNCj4gPiA+ID4gICAgDQo+ID4gPiA+ICsJLyoN Cj4gPiA+ID4gKwkgKiBMaW5rIHRoZSBjb25zdW1lciBkZXZpY2Ugd2l0aCB0aGUgc21pLWxhcmIN Cj4gPiA+ID4gZGV2aWNlKHN1cHBsaWVyKQ0KPiA+ID4gPiArCSAqIFRoZSBkZXZpY2UgaW4gZWFj aCBhIGxhcmIgaXMgYSBpbmRlcGVuZGVudCBIVy4gdGh1cw0KPiA+ID4gPiBvbmx5DQo+ID4gPiA+ IGxpbmsNCj4gPiA+ID4gKwkgKiBvbmUgbGFyYiBoZXJlLg0KPiA+ID4gPiArCSAqLw0KPiA+ID4g PiArCWxhcmJpZCA9IE1US19NNFVfVE9fTEFSQihmd3NwZWMtPmlkc1swXSk7DQo+ID4gPiANCj4g PiA+IHNvIGxhcmJpZCBpcyBhbHdheXMgdGhlIHNhbWUgZm9yIGFsbCB0aGUgaWRzIG9mIGEgZGV2 aWNlPw0KPiA+IA0KPiA+IFllcy4gRm9yIG1lLCBlYWNoIGEgZHRzaSBub2RlIHNob3VsZCByZXBy ZXNlbnQgYSBIVyB1bml0IHdoaWNoIGNhbg0KPiA+IG9ubHkNCj4gPiBjb25uZWN0IG9uZSBsYXJi Lg0KPiA+IA0KPiA+ID4gSWYgc28gbWF5YmUgaXQgd29ydGggdGVzdGluZyBpdCBhbmQgcmV0dXJu IGVycm9yIGlmIHRoaXMgaXMgbm90DQo+ID4gPiB0aGUNCj4gPiA+IGNhc2UuDQo+ID4gDQo+ID4g VGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlvbi4gVGhpcyBpcyB2ZXJ5IGhlbHBmdWwuIEkgZGlkIHNl ZSBzb21lb25lDQo+ID4gcHV0DQo+ID4gdGhlIGRpZmZlcmVudCBsYXJicyBpbiBvbmUgbm9kZS4g SSB3aWxsIGNoZWNrIHRoaXMsIGFuZCBhZGQgcmV0dXJuDQo+IA0KPiBJIGFtIHdvcmtpbmcgb24g YnVncyBmb3VuZCBvbiBtZWRpYSBkcml2ZXJzLCBjb3VsZCB5b3UgcGxlYXNlIHBvaW50DQo+IG1l IHRvDQo+IHRoYXQgd3Jvbmcgbm9kZT8NCj4gV2lsbCB5b3Ugc2VuZCBhIGZpeCB0byB0aGF0IG5v ZGUgaW4gdGhlIGR0c2k/DQoNCnNvcnJ5LiBJIG1lYW4gaXQgaGFwcGVuZWQgaW4gdGhlIGludGVy bmFsIGJyYW5jaCBhbmQgaXQgaGFzIGFscmVhZHkNCmJlZW4gZml4ZWQgaW50ZXJuYWxseSwgIGFs bCB0aGUgdXBzdHJlYW0gbm9kZXMgYXJlIG9rIGZvciB0aGlzLg0KDQpUaGFua3MNCj4gDQo+IA0K PiBUaGFua3MsDQo+IERhZm5hDQo+IA0KPiA+IEVJTlZBTCBmb3IgdGhpcyBjYXNlLg0KPiANCj4g DQo+IA0KPiA+IA0KPiA+ID4gDQo+ID4gPiBUaGFua3MsDQo+ID4gPiBEYWZuYQ0KPiA+IA0KPiA+ ICAgDQo+ID4gPiA+IA0K 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 04490C433EF for ; Mon, 25 Oct 2021 03:57:57 +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 A949B60F46 for ; Mon, 25 Oct 2021 03:57:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A949B60F46 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 63AF840144; Mon, 25 Oct 2021 03:57:56 +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 PPjAcJ_iz2Bj; Mon, 25 Oct 2021 03:57:55 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id DB357400D4; Mon, 25 Oct 2021 03:57:54 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id BAB6EC0019; Mon, 25 Oct 2021 03:57:54 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 62F71C000E for ; Mon, 25 Oct 2021 03:57:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3F1C780E49 for ; Mon, 25 Oct 2021 03:57:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=mediatek.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjT-_cI06lS9 for ; Mon, 25 Oct 2021 03:57:47 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) by smtp1.osuosl.org (Postfix) with ESMTPS id 7A9B380E42 for ; Mon, 25 Oct 2021 03:57:46 +0000 (UTC) X-UUID: 6cf5dab4038e407b895180c1d1649248-20211025 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=cV6dg7PsYHB6+UKop/Sg0rROLJ+oreSSfppKhlC8xGE=; b=nBkGbQeC+Sa3c4WFbs6Ky01mc0hcpUC1VdMIVgp0Ci+nREwXGSXct8xkBhX2s3ToXb8z7bOAWuCxF6sm2/w1ZbvpyLWXSZSkGdcufbA7YrxHi4qeoC1Ri9RoqAAxoOpOmRoxjwmLJ+sjifSy3adpDDGLiZMJznJ7HwbTckMDANs=; X-UUID: 6cf5dab4038e407b895180c1d1649248-20211025 Received: from mtkmbs10n1.mediatek.inc [(172.21.101.34)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 77251011; Mon, 25 Oct 2021 11:57:42 +0800 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 25 Oct 2021 11:57:40 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 25 Oct 2021 11:57:39 +0800 Message-ID: <15d4ccb984f9e3919d6d7535d05aec0332dbe301.camel@mediatek.com> Subject: Re: [PATCH v8 04/12] iommu/mediatek: Add device_link between the consumer and the larb devices From: Yong Wu To: Dafna Hirschfeld , Matthias Brugger , Joerg Roedel , Rob Herring , Krzysztof Kozlowski , David Airlie , "Mauro Carvalho Chehab" Date: Mon, 25 Oct 2021 11:57:39 +0800 In-Reply-To: References: <20210929013719.25120-1-yong.wu@mediatek.com> <20210929013719.25120-5-yong.wu@mediatek.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N Cc: Chun-Kuang Hu , Will Deacon , dri-devel@lists.freedesktop.org, anthony.huang@mediatek.com, youlin.pei@mediatek.com, Evan Green , Eizan Miyamoto , Matthias Kaehlcke , linux-media@vger.kernel.org, devicetree@vger.kernel.org, Philipp Zabel , Frank Wunderlich , yi.kuo@mediatek.com, linux-mediatek@lists.infradead.org, Hsin-Yi Wang , Tiffany Lin , linux-arm-kernel@lists.infradead.org, anan.sun@mediatek.com, srv_heupstream@mediatek.com, acourbot@chromium.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Daniel Vetter , Robin Murphy 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 Mon, 2021-10-18 at 09:13 +0200, Dafna Hirschfeld wrote: > > On 16.10.21 04:23, Yong Wu wrote: > > On Mon, 2021-10-11 at 14:36 +0200, Dafna Hirschfeld wrote: > > > > > > On 29.09.21 03:37, Yong Wu wrote: > > > > MediaTek IOMMU-SMI diagram is like below. all the consumer > > > > connect > > > > with > > > > smi-larb, then connect with smi-common. > > > > > > > > M4U > > > > | > > > > smi-common > > > > | > > > > ------------- > > > > | | ... > > > > | | > > > > larb1 larb2 > > > > | | > > > > vdec venc > > > > > > > > When the consumer works, it should enable the smi-larb's power > > > > which > > > > also need enable the smi-common's power firstly. > > > > > > > > Thus, First of all, use the device link connect the consumer > > > > and > > > > the > > > > smi-larbs. then add device link between the smi-larb and smi- > > > > common. > > > > > > > > This patch adds device_link between the consumer and the larbs. > > > > > > > > When device_link_add, I add the flag DL_FLAG_STATELESS to avoid > > > > calling > > > > pm_runtime_xx to keep the original status of clocks. It can > > > > avoid > > > > two > > > > issues: > > > > 1) Display HW show fastlogo abnormally reported in [1]. At the > > > > beggining, > > > > all the clocks are enabled before entering kernel, but the > > > > clocks > > > > for > > > > display HW(always in larb0) will be gated after clk_enable and > > > > clk_disable > > > > called from device_link_add(->pm_runtime_resume) and rpm_idle. > > > > The > > > > clock > > > > operation happened before display driver probe. At that time, > > > > the > > > > display > > > > HW will be abnormal. > > > > > > > > 2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to > > > > skip > > > > pm_runtime_xx to avoid the deadlock. > > > > > > > > Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then > > > > device_link_removed should be added explicitly. > > > > > > > > [1] > > > > https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/ > > > > [2] https://lore.kernel.org/patchwork/patch/1086569/ > > > > > > > > Suggested-by: Tomasz Figa > > > > Signed-off-by: Yong Wu > > > > Tested-by: Frank Wunderlich # BPI- > > > > R2/MT7623 > > > > --- > > > > drivers/iommu/mtk_iommu.c | 22 ++++++++++++++++++++++ > > > > drivers/iommu/mtk_iommu_v1.c | 20 +++++++++++++++++++- > > > > 2 files changed, 41 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/iommu/mtk_iommu.c > > > > b/drivers/iommu/mtk_iommu.c > > > > index d5848f78a677..a2fa55899434 100644 > > > > --- a/drivers/iommu/mtk_iommu.c > > > > +++ b/drivers/iommu/mtk_iommu.c > > > > @@ -560,22 +560,44 @@ static struct iommu_device > > > > *mtk_iommu_probe_device(struct device *dev) > > > > { > > > > struct iommu_fwspec *fwspec = > > > > dev_iommu_fwspec_get(dev); > > > > struct mtk_iommu_data *data; > > > > + struct device_link *link; > > > > + struct device *larbdev; > > > > + unsigned int larbid; > > > > > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > > > return ERR_PTR(-ENODEV); /* Not a iommu client > > > > device > > > > */ > > > > > > > > data = dev_iommu_priv_get(dev); > > > > > > > > + /* > > > > + * Link the consumer device with the smi-larb > > > > device(supplier) > > > > + * The device in each a larb is a independent HW. thus > > > > only > > > > link > > > > + * one larb here. > > > > + */ > > > > + larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); > > > > > > so larbid is always the same for all the ids of a device? > > > > Yes. For me, each a dtsi node should represent a HW unit which can > > only > > connect one larb. > > > > > If so maybe it worth testing it and return error if this is not > > > the > > > case. > > > > Thanks for the suggestion. This is very helpful. I did see someone > > put > > the different larbs in one node. I will check this, and add return > > I am working on bugs found on media drivers, could you please point > me to > that wrong node? > Will you send a fix to that node in the dtsi? sorry. I mean it happened in the internal branch and it has already been fixed internally, all the upstream nodes are ok for this. Thanks > > > Thanks, > Dafna > > > EINVAL for this case. > > > > > > > > > > > Thanks, > > > Dafna > > > > > > > > _______________________________________________ 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 C5908C433EF for ; Mon, 25 Oct 2021 03:58:11 +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 756786103D for ; Mon, 25 Oct 2021 03:58:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 756786103D 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=M0zS8b15qQ/pSQjGFyT5nfYTB3oM+o5IVaTlhoM90tM=; b=eW77t3lZkSbkWS UDAI1LdrtNb/J8IgxIYwhsBALii7R1LkY+yHfo5LOyI8Tcjg55uHA7HlAmE5WtN/7is6MxJytXpMg Yo4egfwcWcLrC5cv1FBt0lZIrgIvuS8c7wJpVLyplHTA3s18t9mAVAjcUVMqdOVJ47ltII8gqJWWD O24OVmySoqTpC90DNIE3uroxRd/0bQC+b8C9B9od7SulxXr1564/PJytWLumXsK4T6uKiVWWqliQ/ P1tOU4fkU9NQAWd0zpgTuiGmFX/46vSvUYlBklif4Fk1imEPWZWLxX2OMqCkW6/c1iII40adEUK/B RbElWIzuwP3ZmGpN/6Xg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mer7a-00FDgB-30; Mon, 25 Oct 2021 03:58:02 +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 1mer7N-00FDdH-1Z; Mon, 25 Oct 2021 03:57:50 +0000 X-UUID: 4b22ebbaa2854463a5c471b3494580d6-20211024 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=cV6dg7PsYHB6+UKop/Sg0rROLJ+oreSSfppKhlC8xGE=; b=nBkGbQeC+Sa3c4WFbs6Ky01mc0hcpUC1VdMIVgp0Ci+nREwXGSXct8xkBhX2s3ToXb8z7bOAWuCxF6sm2/w1ZbvpyLWXSZSkGdcufbA7YrxHi4qeoC1Ri9RoqAAxoOpOmRoxjwmLJ+sjifSy3adpDDGLiZMJznJ7HwbTckMDANs=; X-UUID: 4b22ebbaa2854463a5c471b3494580d6-20211024 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 691523356; Sun, 24 Oct 2021 20:57:44 -0700 Received: from mtkmbs10n2.mediatek.inc (172.21.101.183) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 24 Oct 2021 20:57:42 -0700 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 25 Oct 2021 11:57:40 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 25 Oct 2021 11:57:39 +0800 Message-ID: <15d4ccb984f9e3919d6d7535d05aec0332dbe301.camel@mediatek.com> Subject: Re: [PATCH v8 04/12] iommu/mediatek: Add device_link between the consumer and the larb devices From: Yong Wu To: Dafna Hirschfeld , Matthias Brugger , Joerg Roedel , Rob Herring , Krzysztof Kozlowski , David Airlie , "Mauro Carvalho Chehab" CC: Evan Green , Robin Murphy , Tomasz Figa , Will Deacon , , , , , , , , Matthias Kaehlcke , , , , , , "Daniel Vetter" , Chun-Kuang Hu , "Philipp Zabel" , Tiffany Lin , Hsin-Yi Wang , Eizan Miyamoto , , Frank Wunderlich Date: Mon, 25 Oct 2021 11:57:39 +0800 In-Reply-To: References: <20210929013719.25120-1-yong.wu@mediatek.com> <20210929013719.25120-5-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-20211024_205749_101268_937A797C X-CRM114-Status: GOOD ( 44.98 ) 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 Mon, 2021-10-18 at 09:13 +0200, Dafna Hirschfeld wrote: > > On 16.10.21 04:23, Yong Wu wrote: > > On Mon, 2021-10-11 at 14:36 +0200, Dafna Hirschfeld wrote: > > > > > > On 29.09.21 03:37, Yong Wu wrote: > > > > MediaTek IOMMU-SMI diagram is like below. all the consumer > > > > connect > > > > with > > > > smi-larb, then connect with smi-common. > > > > > > > > M4U > > > > | > > > > smi-common > > > > | > > > > ------------- > > > > | | ... > > > > | | > > > > larb1 larb2 > > > > | | > > > > vdec venc > > > > > > > > When the consumer works, it should enable the smi-larb's power > > > > which > > > > also need enable the smi-common's power firstly. > > > > > > > > Thus, First of all, use the device link connect the consumer > > > > and > > > > the > > > > smi-larbs. then add device link between the smi-larb and smi- > > > > common. > > > > > > > > This patch adds device_link between the consumer and the larbs. > > > > > > > > When device_link_add, I add the flag DL_FLAG_STATELESS to avoid > > > > calling > > > > pm_runtime_xx to keep the original status of clocks. It can > > > > avoid > > > > two > > > > issues: > > > > 1) Display HW show fastlogo abnormally reported in [1]. At the > > > > beggining, > > > > all the clocks are enabled before entering kernel, but the > > > > clocks > > > > for > > > > display HW(always in larb0) will be gated after clk_enable and > > > > clk_disable > > > > called from device_link_add(->pm_runtime_resume) and rpm_idle. > > > > The > > > > clock > > > > operation happened before display driver probe. At that time, > > > > the > > > > display > > > > HW will be abnormal. > > > > > > > > 2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to > > > > skip > > > > pm_runtime_xx to avoid the deadlock. > > > > > > > > Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then > > > > device_link_removed should be added explicitly. > > > > > > > > [1] > > > > https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/ > > > > [2] https://lore.kernel.org/patchwork/patch/1086569/ > > > > > > > > Suggested-by: Tomasz Figa > > > > Signed-off-by: Yong Wu > > > > Tested-by: Frank Wunderlich # BPI- > > > > R2/MT7623 > > > > --- > > > > drivers/iommu/mtk_iommu.c | 22 ++++++++++++++++++++++ > > > > drivers/iommu/mtk_iommu_v1.c | 20 +++++++++++++++++++- > > > > 2 files changed, 41 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/iommu/mtk_iommu.c > > > > b/drivers/iommu/mtk_iommu.c > > > > index d5848f78a677..a2fa55899434 100644 > > > > --- a/drivers/iommu/mtk_iommu.c > > > > +++ b/drivers/iommu/mtk_iommu.c > > > > @@ -560,22 +560,44 @@ static struct iommu_device > > > > *mtk_iommu_probe_device(struct device *dev) > > > > { > > > > struct iommu_fwspec *fwspec = > > > > dev_iommu_fwspec_get(dev); > > > > struct mtk_iommu_data *data; > > > > + struct device_link *link; > > > > + struct device *larbdev; > > > > + unsigned int larbid; > > > > > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > > > return ERR_PTR(-ENODEV); /* Not a iommu client > > > > device > > > > */ > > > > > > > > data = dev_iommu_priv_get(dev); > > > > > > > > + /* > > > > + * Link the consumer device with the smi-larb > > > > device(supplier) > > > > + * The device in each a larb is a independent HW. thus > > > > only > > > > link > > > > + * one larb here. > > > > + */ > > > > + larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); > > > > > > so larbid is always the same for all the ids of a device? > > > > Yes. For me, each a dtsi node should represent a HW unit which can > > only > > connect one larb. > > > > > If so maybe it worth testing it and return error if this is not > > > the > > > case. > > > > Thanks for the suggestion. This is very helpful. I did see someone > > put > > the different larbs in one node. I will check this, and add return > > I am working on bugs found on media drivers, could you please point > me to > that wrong node? > Will you send a fix to that node in the dtsi? sorry. I mean it happened in the internal branch and it has already been fixed internally, all the upstream nodes are ok for this. Thanks > > > Thanks, > Dafna > > > EINVAL for this case. > > > > > > > > > > > Thanks, > > > Dafna > > > > > > > > _______________________________________________ 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 1BA70C433F5 for ; Mon, 25 Oct 2021 03:59:41 +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 D21F760F9B for ; Mon, 25 Oct 2021 03:59:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D21F760F9B 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=pyDF56DNpx3QWyPV2hxIuCCNxUBTn1ve2tJPeteq9+A=; b=fN4ZKJ9qQ4vM2W haK1BIyvicuILai8a4Odkguks0Kp6N8VbV6Ejmq6/ypajOmIKJLF299In69bQBWsa5y8RuXvIOkwl bA/FsU5xs/qhW1ZS3/kS+MG6LCLkbBm1eqpbXAoP8MEt/kKT4IXTQbVweFr236Z501TC9PU9mzX7j 03oQqL3O+j8qG7dVE6k18cR7EYmRmf8FvmKeq1rOyEpayIy4sxMgWIiZBd5iDMJksprzYl8HxXrxz Mo4fU554hSK/l1mXtPEK3FI89OBI/WrGZDNHd+8V8LKrivJD/kw1fC1cgD1fhCvH5lBP5mAwm3VQa pK2CNht4zHDW0dbxdurQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mer7R-00FDfD-83; Mon, 25 Oct 2021 03:57: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 1mer7N-00FDdH-1Z; Mon, 25 Oct 2021 03:57:50 +0000 X-UUID: 4b22ebbaa2854463a5c471b3494580d6-20211024 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=cV6dg7PsYHB6+UKop/Sg0rROLJ+oreSSfppKhlC8xGE=; b=nBkGbQeC+Sa3c4WFbs6Ky01mc0hcpUC1VdMIVgp0Ci+nREwXGSXct8xkBhX2s3ToXb8z7bOAWuCxF6sm2/w1ZbvpyLWXSZSkGdcufbA7YrxHi4qeoC1Ri9RoqAAxoOpOmRoxjwmLJ+sjifSy3adpDDGLiZMJznJ7HwbTckMDANs=; X-UUID: 4b22ebbaa2854463a5c471b3494580d6-20211024 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 691523356; Sun, 24 Oct 2021 20:57:44 -0700 Received: from mtkmbs10n2.mediatek.inc (172.21.101.183) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 24 Oct 2021 20:57:42 -0700 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Mon, 25 Oct 2021 11:57:40 +0800 Received: from mhfsdcap04 (10.17.3.154) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 25 Oct 2021 11:57:39 +0800 Message-ID: <15d4ccb984f9e3919d6d7535d05aec0332dbe301.camel@mediatek.com> Subject: Re: [PATCH v8 04/12] iommu/mediatek: Add device_link between the consumer and the larb devices From: Yong Wu To: Dafna Hirschfeld , Matthias Brugger , Joerg Roedel , Rob Herring , Krzysztof Kozlowski , David Airlie , "Mauro Carvalho Chehab" CC: Evan Green , Robin Murphy , Tomasz Figa , Will Deacon , , , , , , , , Matthias Kaehlcke , , , , , , "Daniel Vetter" , Chun-Kuang Hu , "Philipp Zabel" , Tiffany Lin , Hsin-Yi Wang , Eizan Miyamoto , , Frank Wunderlich Date: Mon, 25 Oct 2021 11:57:39 +0800 In-Reply-To: References: <20210929013719.25120-1-yong.wu@mediatek.com> <20210929013719.25120-5-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-20211024_205749_101268_937A797C X-CRM114-Status: GOOD ( 44.98 ) 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 Mon, 2021-10-18 at 09:13 +0200, Dafna Hirschfeld wrote: > > On 16.10.21 04:23, Yong Wu wrote: > > On Mon, 2021-10-11 at 14:36 +0200, Dafna Hirschfeld wrote: > > > > > > On 29.09.21 03:37, Yong Wu wrote: > > > > MediaTek IOMMU-SMI diagram is like below. all the consumer > > > > connect > > > > with > > > > smi-larb, then connect with smi-common. > > > > > > > > M4U > > > > | > > > > smi-common > > > > | > > > > ------------- > > > > | | ... > > > > | | > > > > larb1 larb2 > > > > | | > > > > vdec venc > > > > > > > > When the consumer works, it should enable the smi-larb's power > > > > which > > > > also need enable the smi-common's power firstly. > > > > > > > > Thus, First of all, use the device link connect the consumer > > > > and > > > > the > > > > smi-larbs. then add device link between the smi-larb and smi- > > > > common. > > > > > > > > This patch adds device_link between the consumer and the larbs. > > > > > > > > When device_link_add, I add the flag DL_FLAG_STATELESS to avoid > > > > calling > > > > pm_runtime_xx to keep the original status of clocks. It can > > > > avoid > > > > two > > > > issues: > > > > 1) Display HW show fastlogo abnormally reported in [1]. At the > > > > beggining, > > > > all the clocks are enabled before entering kernel, but the > > > > clocks > > > > for > > > > display HW(always in larb0) will be gated after clk_enable and > > > > clk_disable > > > > called from device_link_add(->pm_runtime_resume) and rpm_idle. > > > > The > > > > clock > > > > operation happened before display driver probe. At that time, > > > > the > > > > display > > > > HW will be abnormal. > > > > > > > > 2) A deadlock issue reported in [2]. Use DL_FLAG_STATELESS to > > > > skip > > > > pm_runtime_xx to avoid the deadlock. > > > > > > > > Corresponding, DL_FLAG_AUTOREMOVE_CONSUMER can't be added, then > > > > device_link_removed should be added explicitly. > > > > > > > > [1] > > > > https://lore.kernel.org/linux-mediatek/1564213888.22908.4.camel@mhfsdcap03/ > > > > [2] https://lore.kernel.org/patchwork/patch/1086569/ > > > > > > > > Suggested-by: Tomasz Figa > > > > Signed-off-by: Yong Wu > > > > Tested-by: Frank Wunderlich # BPI- > > > > R2/MT7623 > > > > --- > > > > drivers/iommu/mtk_iommu.c | 22 ++++++++++++++++++++++ > > > > drivers/iommu/mtk_iommu_v1.c | 20 +++++++++++++++++++- > > > > 2 files changed, 41 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/iommu/mtk_iommu.c > > > > b/drivers/iommu/mtk_iommu.c > > > > index d5848f78a677..a2fa55899434 100644 > > > > --- a/drivers/iommu/mtk_iommu.c > > > > +++ b/drivers/iommu/mtk_iommu.c > > > > @@ -560,22 +560,44 @@ static struct iommu_device > > > > *mtk_iommu_probe_device(struct device *dev) > > > > { > > > > struct iommu_fwspec *fwspec = > > > > dev_iommu_fwspec_get(dev); > > > > struct mtk_iommu_data *data; > > > > + struct device_link *link; > > > > + struct device *larbdev; > > > > + unsigned int larbid; > > > > > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > > > return ERR_PTR(-ENODEV); /* Not a iommu client > > > > device > > > > */ > > > > > > > > data = dev_iommu_priv_get(dev); > > > > > > > > + /* > > > > + * Link the consumer device with the smi-larb > > > > device(supplier) > > > > + * The device in each a larb is a independent HW. thus > > > > only > > > > link > > > > + * one larb here. > > > > + */ > > > > + larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); > > > > > > so larbid is always the same for all the ids of a device? > > > > Yes. For me, each a dtsi node should represent a HW unit which can > > only > > connect one larb. > > > > > If so maybe it worth testing it and return error if this is not > > > the > > > case. > > > > Thanks for the suggestion. This is very helpful. I did see someone > > put > > the different larbs in one node. I will check this, and add return > > I am working on bugs found on media drivers, could you please point > me to > that wrong node? > Will you send a fix to that node in the dtsi? sorry. I mean it happened in the internal branch and it has already been fixed internally, all the upstream nodes are ok for this. Thanks > > > Thanks, > Dafna > > > EINVAL for this case. > > > > > > > > > > > Thanks, > > > Dafna > > > > > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel