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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EE58C3F2D6 for ; Fri, 6 Mar 2020 07:01:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3B98120848 for ; Fri, 6 Mar 2020 07:01:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="i6eYExUF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726081AbgCFHA7 (ORCPT ); Fri, 6 Mar 2020 02:00:59 -0500 Received: from mailgw02.mediatek.com ([1.203.163.81]:31107 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725784AbgCFHA6 (ORCPT ); Fri, 6 Mar 2020 02:00:58 -0500 X-UUID: 58704f9f07854fc3bbccf18a0d2e5295-20200306 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=gkqDoOqHIrOTpmFheXHWiY15sLy0Mn7me1/+UDymw5E=; b=i6eYExUFp8TbbpiIpervjhx/AOvdtjC8UwuF1nYDxYHjrF3KjEvZanoYuteF2lkPqc0MkCTTWrHL3DJ39AseRq5SyqC3yOXCkDVOqH85/NyiTO6y+dAry07pgQa7jmYSSlS4/tLuirgD2MfAnh4VarSiM4u4EE/8uGJiP861FnM=; X-UUID: 58704f9f07854fc3bbccf18a0d2e5295-20200306 Received: from mtkcas34.mediatek.inc [(172.27.4.253)] by mailgw02.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLS) with ESMTP id 1987127789; Fri, 06 Mar 2020 14:59:54 +0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31N1.mediatek.inc (172.27.4.69) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 6 Mar 2020 14:58:27 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Fri, 6 Mar 2020 14:58:41 +0800 Message-ID: <1583477982.4784.37.camel@mhfsdcap03> Subject: Re: [PATCH v3 03/14] iommu/mediatek: Add device_link between the consumer and the larb devices From: Yong Wu To: Nicolas Boichat CC: Matthias Brugger , Joerg Roedel , Rob Herring , Evan Green , Robin Murphy , Tomasz Figa , Will Deacon , "moderated list:ARM/Mediatek SoC support" , srv_heupstream , Devicetree List , lkml , linux-arm Mailing List , , , "Matthias Kaehlcke" , , , , , , , Date: Fri, 6 Mar 2020 14:59:42 +0800 In-Reply-To: References: <1567503456-24725-1-git-send-email-yong.wu@mediatek.com> <1567503456-24725-4-git-send-email-yong.wu@mediatek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-TM-SNTS-SMTP: B84E2E8EC000FE6B20341D7962063DB72347CFF9209A3FBB475D95CD84B3A5AB2000:8 X-MTK: N Content-Transfer-Encoding: base64 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org T24gVGh1LCAyMDIwLTAzLTA1IGF0IDEzOjE0ICswODAwLCBOaWNvbGFzIEJvaWNoYXQgd3JvdGU6 DQo+IE9uIFR1ZSwgU2VwIDMsIDIwMTkgYXQgNTozOCBQTSBZb25nIFd1IDx5b25nLnd1QG1lZGlh dGVrLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBNZWRpYVRlayBJT01NVSBkb24ndCBoYXZlIGl0cyBw b3dlci1kb21haW4uIGFsbCB0aGUgY29uc3VtZXIgY29ubmVjdA0KPiA+IHdpdGggc21pLWxhcmIs IHRoZW4gY29ubmVjdCB3aXRoIHNtaS1jb21tb24uDQo+ID4NCj4gPiAgICAgICAgIE00VQ0KPiA+ ICAgICAgICAgIHwNCj4gPiAgICAgc21pLWNvbW1vbg0KPiA+ICAgICAgICAgIHwNCj4gPiAgIC0t LS0tLS0tLS0tLS0NCj4gPiAgIHwgICAgICAgICB8ICAgIC4uLg0KPiA+ICAgfCAgICAgICAgIHwN Cj4gPiBsYXJiMSAgICAgbGFyYjINCj4gPiAgIHwgICAgICAgICB8DQo+ID4gdmRlYyAgICAgICB2 ZW5jDQo+ID4NCj4gPiBXaGVuIHRoZSBjb25zdW1lciB3b3JrcywgaXQgc2hvdWxkIGVuYWJsZSB0 aGUgc21pLWxhcmIncyBwb3dlciB3aGljaA0KPiA+IGFsc28gbmVlZCBlbmFibGUgdGhlIHNtaS1j b21tb24ncyBwb3dlciBmaXJzdGx5Lg0KPiA+DQo+ID4gVGh1cywgRmlyc3Qgb2YgYWxsLCB1c2Ug dGhlIGRldmljZSBsaW5rIGNvbm5lY3QgdGhlIGNvbnN1bWVyIGFuZCB0aGUNCj4gPiBzbWktbGFy YnMuIHRoZW4gYWRkIGRldmljZSBsaW5rIGJldHdlZW4gdGhlIHNtaS1sYXJiIGFuZCBzbWktY29t bW9uLg0KPiA+DQo+ID4gVGhpcyBwYXRjaCBhZGRzIGRldmljZV9saW5rIGJldHdlZW4gdGhlIGNv bnN1bWVyIGFuZCB0aGUgbGFyYnMuDQo+ID4NCj4gPiBXaGVuIGRldmljZV9saW5rX2FkZCwgSSBh ZGQgdGhlIGZsYWcgRExfRkxBR19TVEFURUxFU1MgdG8gYXZvaWQgY2FsbGluZw0KPiA+IHBtX3J1 bnRpbWVfeHggdG8ga2VlcCB0aGUgb3JpZ2luYWwgc3RhdHVzIG9mIGNsb2Nrcy4gSXQgY2FuIGF2 b2lkIHR3bw0KPiA+IGlzc3VlczoNCj4gPiAxKSBEaXNwbGF5IEhXIHNob3cgZmFzdGxvZ28gYWJu b3JtYWxseSByZXBvcnRlZCBpbiBbMV0uIEF0IHRoZSBiZWdnaW5pbmcsDQo+ID4gYWxsIHRoZSBj bG9ja3MgYXJlIGVuYWJsZWQgYmVmb3JlIGVudGVyaW5nIGtlcm5lbCwgYnV0IHRoZSBjbG9ja3Mg Zm9yDQo+ID4gZGlzcGxheSBIVyhhbHdheXMgaW4gbGFyYjApIHdpbGwgYmUgZ2F0ZWQgYWZ0ZXIg Y2xrX2VuYWJsZSBhbmQgY2xrX2Rpc2FibGUNCj4gPiBjYWxsZWQgZnJvbSBkZXZpY2VfbGlua19h ZGQoLT5wbV9ydW50aW1lX3Jlc3VtZSkgYW5kIHJwbV9pZGxlLiBUaGUgY2xvY2sNCj4gPiBvcGVy YXRpb24gaGFwcGVuZWQgYmVmb3JlIGRpc3BsYXkgZHJpdmVyIHByb2JlLiBBdCB0aGF0IHRpbWUs IHRoZSBkaXNwbGF5DQo+ID4gSFcgd2lsbCBiZSBhYm5vcm1hbC4NCj4gPg0KPiA+IDIpIEEgZGVh ZGxvY2sgaXNzdWUgcmVwb3J0ZWQgaW4gWzJdLiBVc2UgRExfRkxBR19TVEFURUxFU1MgdG8gc2tp cA0KPiA+IHBtX3J1bnRpbWVfeHggdG8gYXZvaWQgdGhlIGRlYWRsb2NrLg0KPiA+DQo+ID4gQ29y cmVzcG9uZGluZywgRExfRkxBR19BVVRPUkVNT1ZFX0NPTlNVTUVSIGNhbid0IGJlIGFkZGVkLCB0 aGVuDQo+ID4gZGV2aWNlX2xpbmtfcmVtb3ZlZCBzaG91bGQgYmUgYWRkZWQgZXhwbGljaXRseS4N Cj4gPg0KPiA+IFsxXSBodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9waXBlcm1haWwvbGludXgt bWVkaWF0ZWsvMjAxOS1KdWx5Lw0KPiA+IDAyMTUwMC5odG1sDQo+ID4gWzJdIGh0dHBzOi8vbG9y ZS5rZXJuZWwub3JnL3BhdGNod29yay9wYXRjaC8xMDg2NTY5Lw0KPiA+DQo+ID4gU3VnZ2VzdGVk LWJ5OiBUb21hc3ogRmlnYSA8dGZpZ2FAY2hyb21pdW0ub3JnPg0KPiA+IFNpZ25lZC1vZmYtYnk6 IFlvbmcgV3UgPHlvbmcud3VAbWVkaWF0ZWsuY29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL2lv bW11L210a19pb21tdS5jICAgIHwgMTcgKysrKysrKysrKysrKysrKysNCj4gPiAgZHJpdmVycy9p b21tdS9tdGtfaW9tbXVfdjEuYyB8IDE4ICsrKysrKysrKysrKysrKysrLQ0KPiA+ICAyIGZpbGVz IGNoYW5nZWQsIDM0IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gPg0KPiA+IGRpZmYg LS1naXQgYS9kcml2ZXJzL2lvbW11L210a19pb21tdS5jIGIvZHJpdmVycy9pb21tdS9tdGtfaW9t bXUuYw0KPiA+IGluZGV4IGIxMzhiOTQuLjI1MTFiM2MgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVy cy9pb21tdS9tdGtfaW9tbXUuYw0KPiA+ICsrKyBiL2RyaXZlcnMvaW9tbXUvbXRrX2lvbW11LmMN Cj4gPiBAQCAtNDUwLDYgKzQ1MCw5IEBAIHN0YXRpYyBpbnQgbXRrX2lvbW11X2FkZF9kZXZpY2Uo c3RydWN0IGRldmljZSAqZGV2KQ0KPiA+ICAgICAgICAgc3RydWN0IGlvbW11X2Z3c3BlYyAqZndz cGVjID0gZGV2X2lvbW11X2Z3c3BlY19nZXQoZGV2KTsNCj4gPiAgICAgICAgIHN0cnVjdCBtdGtf aW9tbXVfZGF0YSAqZGF0YTsNCj4gPiAgICAgICAgIHN0cnVjdCBpb21tdV9ncm91cCAqZ3JvdXA7 DQo+ID4gKyAgICAgICBzdHJ1Y3QgZGV2aWNlX2xpbmsgKmxpbms7DQo+ID4gKyAgICAgICBzdHJ1 Y3QgZGV2aWNlICpsYXJiZGV2Ow0KPiA+ICsgICAgICAgdW5zaWduZWQgaW50IGxhcmJpZDsNCj4g Pg0KPiA+ICAgICAgICAgaWYgKCFmd3NwZWMgfHwgZndzcGVjLT5vcHMgIT0gJm10a19pb21tdV9v cHMpDQo+ID4gICAgICAgICAgICAgICAgIHJldHVybiAtRU5PREVWOyAvKiBOb3QgYSBpb21tdSBj bGllbnQgZGV2aWNlICovDQo+ID4gQEAgLTQ2MSw2ICs0NjQsMTQgQEAgc3RhdGljIGludCBtdGtf aW9tbXVfYWRkX2RldmljZShzdHJ1Y3QgZGV2aWNlICpkZXYpDQo+ID4gICAgICAgICBpZiAoSVNf RVJSKGdyb3VwKSkNCj4gPiAgICAgICAgICAgICAgICAgcmV0dXJuIFBUUl9FUlIoZ3JvdXApOw0K PiA+DQo+ID4gKyAgICAgICAvKiBMaW5rIHRoZSBjb25zdW1lciBkZXZpY2Ugd2l0aCB0aGUgc21p LWxhcmIgZGV2aWNlKHN1cHBsaWVyKSAqLw0KPiA+ICsgICAgICAgbGFyYmlkID0gTVRLX000VV9U T19MQVJCKGZ3c3BlYy0+aWRzWzBdKTsNCj4gDQo+IEknbGwgbWlycm9yIHRoZSBjb21tZW50IEkg bWFkZSBvbiBnZXJyaXQNCj4gKGh0dHBzOi8vY2hyb21pdW0tcmV2aWV3Lmdvb2dsZXNvdXJjZS5j b20vYy9jaHJvbWl1bW9zL3RoaXJkX3BhcnR5L2tlcm5lbC8rLzEzNjEwMTMpOg0KPiBNYXliZSBJ J20gbWlzc2luZyBzb21ldGhpbmcgaGVyZSwgYnV0IGZvciBleGFtcGxlLCBvbiBNVDgxNzMsDQo+ IHZjb2RlY19lbmM6IHZjb2RlY0AxODAwMjAwMCBuZWVkcyB0byB1c2UgYm90aCBsYXJiMyBhbmQg bGFyYjUsIGlzbid0DQo+IHRoZSBjb2RlIGJlbG93IGp1c3QgYWRkaW5nIGEgbGluayBmb3IgbGFy YjM/DQoNClllcy4gSXQgb25seSBhZGQgbGFyYjMgaGVyZS4NCg0KPiANCj4gRG8gd2UgbmVlZCB0 byBpdGVyYXRlIG92ZXIgYWxsIGZ3c3BlY3MtPmlkcyB0byBmaWd1cmUgb3V0IHdoaWNoIGxhcmJz DQo+IHdlIG5lZWQgdG8gYWRkIGxpbmtzIHRvIGVhY2ggb2YgdGhlbT8NCg0KV2UgaGF2ZSBjaGVj a2VkIHRoaXMgdmVuYyBpc3N1ZS4gQ3VycmVudGx5IEkgaGF2ZSByZXF1ZXN0ZWQgb3VyIHZlbmMg Z3V5DQp0byBzZXBlcmF0ZSBsYXJiMy12ZW5jIGFuZCBsYXJiNS12ZW5jIGluIHRoZSBkcml2ZXJb MV0gc2luY2UgdGhleSBhcmUNCmluZGVwZW5kZW50IEhXIGFjdHVhbGx5LiBJIHdpbGwgcHV0IGl0 IGludG8gdGhpcyBzZXJpZXMgd2hlbiBJIHNlbmQgbmV4dA0KdmVyc2lvbi4NCg0KSWYgdGhlcmUg aXMgc29tZSByZWFzb25hYmxlIGRyaXZlciB3aGljaCBoYXZlIHR3byBsYXJicyBpbiBpdCwgdGhl biB0aGUNCml0ZXJhdGluZyBpcyByZWFsbHkgbmVjZXNzYXJ5LCBCdXQgSSBkb24ndCBzZWUgaXQg cmlnaHQgbm93LiBPbmx5IHVzaW5nDQpmd3NwZWMtPmlkc1swXSBpcyBlbm91Z2ggZm9yIG5vdy4N Cg0KWzFdDQpodHRwczovL2Nocm9taXVtLXJldmlldy5nb29nbGVzb3VyY2UuY29tL2MvY2hyb21p dW1vcy90aGlyZF9wYXJ0eS9rZXJuZWwvKy8xOTU4MzIyDQoNCj4gDQo+ID4gKyAgICAgICBsYXJi ZGV2ID0gZGF0YS0+bGFyYl9pbXVbbGFyYmlkXS5kZXY7DQo+ID4gKyAgICAgICBsaW5rID0gZGV2 aWNlX2xpbmtfYWRkKGRldiwgbGFyYmRldiwNCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRExfRkxBR19QTV9SVU5USU1FIHwgRExfRkxBR19TVEFURUxFU1MpOw0KPiA+ICsgICAg ICAgaWYgKCFsaW5rKQ0KPiA+ICsgICAgICAgICAgICAgICBkZXZfZXJyKGRldiwgIlVuYWJsZSB0 byBsaW5rICVzXG4iLCBkZXZfbmFtZShsYXJiZGV2KSk7DQo+ID4gKw0KPiA+ICAgICAgICAgaW9t bXVfZ3JvdXBfcHV0KGdyb3VwKTsNCj4gPiAgICAgICAgIHJldHVybiAwOw0KPiA+ICB9DQo+ID4g QEAgLTQ2OSw2ICs0ODAsOCBAQCBzdGF0aWMgdm9pZCBtdGtfaW9tbXVfcmVtb3ZlX2RldmljZShz dHJ1Y3QgZGV2aWNlICpkZXYpDQo+ID4gIHsNCj4gPiAgICAgICAgIHN0cnVjdCBpb21tdV9md3Nw ZWMgKmZ3c3BlYyA9IGRldl9pb21tdV9md3NwZWNfZ2V0KGRldik7DQo+ID4gICAgICAgICBzdHJ1 Y3QgbXRrX2lvbW11X2RhdGEgKmRhdGE7DQo+ID4gKyAgICAgICBzdHJ1Y3QgZGV2aWNlICpsYXJi ZGV2Ow0KPiA+ICsgICAgICAgdW5zaWduZWQgaW50IGxhcmJpZDsNCj4gPg0KPiA+ICAgICAgICAg aWYgKCFmd3NwZWMgfHwgZndzcGVjLT5vcHMgIT0gJm10a19pb21tdV9vcHMpDQo+ID4gICAgICAg ICAgICAgICAgIHJldHVybjsNCj4gPiBAQCAtNDc2LDYgKzQ4OSwxMCBAQCBzdGF0aWMgdm9pZCBt dGtfaW9tbXVfcmVtb3ZlX2RldmljZShzdHJ1Y3QgZGV2aWNlICpkZXYpDQo+ID4gICAgICAgICBk YXRhID0gZndzcGVjLT5pb21tdV9wcml2Ow0KPiA+ICAgICAgICAgaW9tbXVfZGV2aWNlX3VubGlu aygmZGF0YS0+aW9tbXUsIGRldik7DQo+ID4NCj4gPiArICAgICAgIGxhcmJpZCA9IE1US19NNFVf VE9fTEFSQihmd3NwZWMtPmlkc1swXSk7DQo+ID4gKyAgICAgICBsYXJiZGV2ID0gZGF0YS0+bGFy Yl9pbXVbbGFyYmlkXS5kZXY7DQo+ID4gKyAgICAgICBkZXZpY2VfbGlua19yZW1vdmUoZGV2LCBs YXJiZGV2KTsNCj4gPiArDQo+ID4gICAgICAgICBpb21tdV9ncm91cF9yZW1vdmVfZGV2aWNlKGRl dik7DQo+ID4gICAgICAgICBpb21tdV9md3NwZWNfZnJlZShkZXYpOw0KPiA+ICB9DQo+ID4gZGlm ZiAtLWdpdCBhL2RyaXZlcnMvaW9tbXUvbXRrX2lvbW11X3YxLmMgYi9kcml2ZXJzL2lvbW11L210 a19pb21tdV92MS5jDQo+ID4gaW5kZXggMjAzNGQ3Mi4uYTdmMjJhMiAxMDA2NDQNCj4gPiAtLS0g YS9kcml2ZXJzL2lvbW11L210a19pb21tdV92MS5jDQo+ID4gKysrIGIvZHJpdmVycy9pb21tdS9t dGtfaW9tbXVfdjEuYw0KPiA+IEBAIC00MjMsNyArNDIzLDkgQEAgc3RhdGljIGludCBtdGtfaW9t bXVfYWRkX2RldmljZShzdHJ1Y3QgZGV2aWNlICpkZXYpDQo+ID4gICAgICAgICBzdHJ1Y3Qgb2Zf cGhhbmRsZV9pdGVyYXRvciBpdDsNCj4gPiAgICAgICAgIHN0cnVjdCBtdGtfaW9tbXVfZGF0YSAq ZGF0YTsNCj4gPiAgICAgICAgIHN0cnVjdCBpb21tdV9ncm91cCAqZ3JvdXA7DQo+ID4gLSAgICAg ICBpbnQgZXJyOw0KPiA+ICsgICAgICAgc3RydWN0IGRldmljZV9saW5rICpsaW5rOw0KPiA+ICsg ICAgICAgc3RydWN0IGRldmljZSAqbGFyYmRldjsNCj4gPiArICAgICAgIGludCBlcnIsIGxhcmJp ZDsNCj4gPg0KPiA+ICAgICAgICAgb2ZfZm9yX2VhY2hfcGhhbmRsZSgmaXQsIGVyciwgZGV2LT5v Zl9ub2RlLCAiaW9tbXVzIiwNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAiI2lvbW11LWNl bGxzIiwgMCkgew0KPiA+IEBAIC00NjYsNiArNDY4LDE0IEBAIHN0YXRpYyBpbnQgbXRrX2lvbW11 X2FkZF9kZXZpY2Uoc3RydWN0IGRldmljZSAqZGV2KQ0KPiA+ICAgICAgICAgICAgICAgICByZXR1 cm4gZXJyOw0KPiA+ICAgICAgICAgfQ0KPiA+DQo+ID4gKyAgICAgICAvKiBMaW5rIHRoZSBjb25z dW1lciBkZXZpY2Ugd2l0aCB0aGUgc21pLWxhcmIgZGV2aWNlKHN1cHBsaWVyKSAqLw0KPiA+ICsg ICAgICAgbGFyYmlkID0gbXQyNzAxX200dV90b19sYXJiKGZ3c3BlYy0+aWRzWzBdKTsNCj4gPiAr ICAgICAgIGxhcmJkZXYgPSBkYXRhLT5sYXJiX2ltdVtsYXJiaWRdLmRldjsNCj4gPiArICAgICAg IGxpbmsgPSBkZXZpY2VfbGlua19hZGQoZGV2LCBsYXJiZGV2LA0KPiA+ICsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBETF9GTEFHX1BNX1JVTlRJTUUgfCBETF9GTEFHX1NUQVRFTEVTUyk7 DQo+ID4gKyAgICAgICBpZiAoIWxpbmspDQo+ID4gKyAgICAgICAgICAgICAgIGRldl9lcnIoZGV2 LCAiVW5hYmxlIHRvIGxpbmsgJXNcbiIsIGRldl9uYW1lKGxhcmJkZXYpKTsNCj4gPiArDQo+ID4g ICAgICAgICByZXR1cm4gaW9tbXVfZGV2aWNlX2xpbmsoJmRhdGEtPmlvbW11LCBkZXYpOw0KPiA+ ICB9DQo+ID4NCj4gPiBAQCAtNDczLDYgKzQ4Myw4IEBAIHN0YXRpYyB2b2lkIG10a19pb21tdV9y ZW1vdmVfZGV2aWNlKHN0cnVjdCBkZXZpY2UgKmRldikNCj4gPiAgew0KPiA+ICAgICAgICAgc3Ry dWN0IGlvbW11X2Z3c3BlYyAqZndzcGVjID0gZGV2X2lvbW11X2Z3c3BlY19nZXQoZGV2KTsNCj4g PiAgICAgICAgIHN0cnVjdCBtdGtfaW9tbXVfZGF0YSAqZGF0YTsNCj4gPiArICAgICAgIHN0cnVj dCBkZXZpY2UgKmxhcmJkZXY7DQo+ID4gKyAgICAgICB1bnNpZ25lZCBpbnQgbGFyYmlkOw0KPiA+ DQo+ID4gICAgICAgICBpZiAoIWZ3c3BlYyB8fCBmd3NwZWMtPm9wcyAhPSAmbXRrX2lvbW11X29w cykNCj4gPiAgICAgICAgICAgICAgICAgcmV0dXJuOw0KPiA+IEBAIC00ODAsNiArNDkyLDEwIEBA IHN0YXRpYyB2b2lkIG10a19pb21tdV9yZW1vdmVfZGV2aWNlKHN0cnVjdCBkZXZpY2UgKmRldikN Cj4gPiAgICAgICAgIGRhdGEgPSBmd3NwZWMtPmlvbW11X3ByaXY7DQo+ID4gICAgICAgICBpb21t dV9kZXZpY2VfdW5saW5rKCZkYXRhLT5pb21tdSwgZGV2KTsNCj4gPg0KPiA+ICsgICAgICAgbGFy YmlkID0gbXQyNzAxX200dV90b19sYXJiKGZ3c3BlYy0+aWRzWzBdKTsNCj4gPiArICAgICAgIGxh cmJkZXYgPSBkYXRhLT5sYXJiX2ltdVtsYXJiaWRdLmRldjsNCj4gPiArICAgICAgIGRldmljZV9s aW5rX3JlbW92ZShkZXYsIGxhcmJkZXYpOw0KPiA+ICsNCj4gPiAgICAgICAgIGlvbW11X2dyb3Vw X3JlbW92ZV9kZXZpY2UoZGV2KTsNCj4gPiAgICAgICAgIGlvbW11X2Z3c3BlY19mcmVlKGRldik7 DQo+ID4gIH0NCj4gPiAtLQ0KPiA+IDEuOS4xDQo+ID4NCg0K 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 X-Spam-Level: X-Spam-Status: No, score=-8.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64F14C3F2D4 for ; Fri, 6 Mar 2020 07:10:23 +0000 (UTC) Received: from hemlock.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 21E5B2073D for ; Fri, 6 Mar 2020 07:10:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="i6eYExUF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 21E5B2073D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id E960187E74; Fri, 6 Mar 2020 07:10:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arbZ0J9G9wKI; Fri, 6 Mar 2020 07:10:22 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by hemlock.osuosl.org (Postfix) with ESMTP id 197AA87E6E; Fri, 6 Mar 2020 07:10:22 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id E72E0C18D3; Fri, 6 Mar 2020 07:10:21 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 78447C013E for ; Fri, 6 Mar 2020 07:10:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 4DE1A87E6E for ; Fri, 6 Mar 2020 07:10:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byNYux+EY5en for ; Fri, 6 Mar 2020 07:10:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mailgw02.mediatek.com (unknown [1.203.163.81]) by hemlock.osuosl.org (Postfix) with ESMTP id CA4EC87E74 for ; Fri, 6 Mar 2020 07:10:07 +0000 (UTC) X-UUID: 58704f9f07854fc3bbccf18a0d2e5295-20200306 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=gkqDoOqHIrOTpmFheXHWiY15sLy0Mn7me1/+UDymw5E=; b=i6eYExUFp8TbbpiIpervjhx/AOvdtjC8UwuF1nYDxYHjrF3KjEvZanoYuteF2lkPqc0MkCTTWrHL3DJ39AseRq5SyqC3yOXCkDVOqH85/NyiTO6y+dAry07pgQa7jmYSSlS4/tLuirgD2MfAnh4VarSiM4u4EE/8uGJiP861FnM=; X-UUID: 58704f9f07854fc3bbccf18a0d2e5295-20200306 Received: from mtkcas34.mediatek.inc [(172.27.4.253)] by mailgw02.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLS) with ESMTP id 1987127789; Fri, 06 Mar 2020 14:59:54 +0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31N1.mediatek.inc (172.27.4.69) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 6 Mar 2020 14:58:27 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Fri, 6 Mar 2020 14:58:41 +0800 Message-ID: <1583477982.4784.37.camel@mhfsdcap03> Subject: Re: [PATCH v3 03/14] iommu/mediatek: Add device_link between the consumer and the larb devices From: Yong Wu To: Nicolas Boichat Date: Fri, 6 Mar 2020 14:59:42 +0800 In-Reply-To: References: <1567503456-24725-1-git-send-email-yong.wu@mediatek.com> <1567503456-24725-4-git-send-email-yong.wu@mediatek.com> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-TM-SNTS-SMTP: B84E2E8EC000FE6B20341D7962063DB72347CFF9209A3FBB475D95CD84B3A5AB2000:8 X-MTK: N Cc: maoguang.meng@mediatek.com, Will Deacon , youlin.pei@mediatek.com, Evan Green , Matthias Kaehlcke , Devicetree List , cui.zhang@mediatek.com, houlong.wei@mediatek.com, Tomasz Figa , sj.huang@mediatek.com, Rob Herring , "moderated list:ARM/Mediatek SoC support" , Matthias Brugger , ming-fan.chen@mediatek.com, linux-arm Mailing List , anan.sun@mediatek.com, srv_heupstream , lkml , chao.hao@mediatek.com, iommu@lists.linux-foundation.org, 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 Thu, 2020-03-05 at 13:14 +0800, Nicolas Boichat wrote: > On Tue, Sep 3, 2019 at 5:38 PM Yong Wu wrote: > > > > MediaTek IOMMU don't have its power-domain. 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] http://lists.infradead.org/pipermail/linux-mediatek/2019-July/ > > 021500.html > > [2] https://lore.kernel.org/patchwork/patch/1086569/ > > > > Suggested-by: Tomasz Figa > > Signed-off-by: Yong Wu > > --- > > drivers/iommu/mtk_iommu.c | 17 +++++++++++++++++ > > drivers/iommu/mtk_iommu_v1.c | 18 +++++++++++++++++- > > 2 files changed, 34 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index b138b94..2511b3c 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -450,6 +450,9 @@ static int mtk_iommu_add_device(struct device *dev) > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > struct mtk_iommu_data *data; > > struct iommu_group *group; > > + struct device_link *link; > > + struct device *larbdev; > > + unsigned int larbid; > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > return -ENODEV; /* Not a iommu client device */ > > @@ -461,6 +464,14 @@ static int mtk_iommu_add_device(struct device *dev) > > if (IS_ERR(group)) > > return PTR_ERR(group); > > > > + /* Link the consumer device with the smi-larb device(supplier) */ > > + larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); > > I'll mirror the comment I made on gerrit > (https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1361013): > Maybe I'm missing something here, but for example, on MT8173, > vcodec_enc: vcodec@18002000 needs to use both larb3 and larb5, isn't > the code below just adding a link for larb3? Yes. It only add larb3 here. > > Do we need to iterate over all fwspecs->ids to figure out which larbs > we need to add links to each of them? We have checked this venc issue. Currently I have requested our venc guy to seperate larb3-venc and larb5-venc in the driver[1] since they are independent HW actually. I will put it into this series when I send next version. If there is some reasonable driver which have two larbs in it, then the iterating is really necessary, But I don't see it right now. Only using fwspec->ids[0] is enough for now. [1] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1958322 > > > + larbdev = data->larb_imu[larbid].dev; > > + link = device_link_add(dev, larbdev, > > + DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS); > > + if (!link) > > + dev_err(dev, "Unable to link %s\n", dev_name(larbdev)); > > + > > iommu_group_put(group); > > return 0; > > } > > @@ -469,6 +480,8 @@ static void mtk_iommu_remove_device(struct device *dev) > > { > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > struct mtk_iommu_data *data; > > + struct device *larbdev; > > + unsigned int larbid; > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > return; > > @@ -476,6 +489,10 @@ static void mtk_iommu_remove_device(struct device *dev) > > data = fwspec->iommu_priv; > > iommu_device_unlink(&data->iommu, dev); > > > > + larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); > > + larbdev = data->larb_imu[larbid].dev; > > + device_link_remove(dev, larbdev); > > + > > iommu_group_remove_device(dev); > > iommu_fwspec_free(dev); > > } > > diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c > > index 2034d72..a7f22a2 100644 > > --- a/drivers/iommu/mtk_iommu_v1.c > > +++ b/drivers/iommu/mtk_iommu_v1.c > > @@ -423,7 +423,9 @@ static int mtk_iommu_add_device(struct device *dev) > > struct of_phandle_iterator it; > > struct mtk_iommu_data *data; > > struct iommu_group *group; > > - int err; > > + struct device_link *link; > > + struct device *larbdev; > > + int err, larbid; > > > > of_for_each_phandle(&it, err, dev->of_node, "iommus", > > "#iommu-cells", 0) { > > @@ -466,6 +468,14 @@ static int mtk_iommu_add_device(struct device *dev) > > return err; > > } > > > > + /* Link the consumer device with the smi-larb device(supplier) */ > > + larbid = mt2701_m4u_to_larb(fwspec->ids[0]); > > + larbdev = data->larb_imu[larbid].dev; > > + link = device_link_add(dev, larbdev, > > + DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS); > > + if (!link) > > + dev_err(dev, "Unable to link %s\n", dev_name(larbdev)); > > + > > return iommu_device_link(&data->iommu, dev); > > } > > > > @@ -473,6 +483,8 @@ static void mtk_iommu_remove_device(struct device *dev) > > { > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > struct mtk_iommu_data *data; > > + struct device *larbdev; > > + unsigned int larbid; > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > return; > > @@ -480,6 +492,10 @@ static void mtk_iommu_remove_device(struct device *dev) > > data = fwspec->iommu_priv; > > iommu_device_unlink(&data->iommu, dev); > > > > + larbid = mt2701_m4u_to_larb(fwspec->ids[0]); > > + larbdev = data->larb_imu[larbid].dev; > > + device_link_remove(dev, larbdev); > > + > > iommu_group_remove_device(dev); > > iommu_fwspec_free(dev); > > } > > -- > > 1.9.1 > > _______________________________________________ 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 X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61479C3F2D5 for ; Fri, 6 Mar 2020 07:00:16 +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 3249C2072A for ; Fri, 6 Mar 2020 07:00:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="svl181QK"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="Kxm/E3Zs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3249C2072A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date: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=TKLkzyyjIHacrwiMNlFAOpwR37vfSeujXPPEav1niac=; b=svl181QK7eGuI+ naRLDAyUcfCf8Ex3usFq+ZRWpdNOI+YtKND9+Q4mg0BqoO5+zFxFXGBFk67aX62DlMvU2Uoh7ZJEB ZXCcUSDzGdWBdNGPG41qZ5fWV2McxOgPhFUD+nJdilUEzQxYme6xWBtw8KXxXj07WOpWLcEGq/1kE zFN8K8Dr9u3B6xTnkMv32Oz0dTrIwMAFFCyRUZlTB2axJJPxomqWAA+irLiG/IyzXLeQ32mVl5Ok8 udwXXJedWWAqcbZ8d07SRRB3cT9wG2Bb4j0Edst0xDQUP4fOU8E7GUfLIoyto16THvsSnTrE2YjQC P2Ib/PCWwad+QuLCzHmg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jA6xr-0001Ib-Md; Fri, 06 Mar 2020 07:00:07 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jA6xn-0000M0-Se; Fri, 06 Mar 2020 07:00:05 +0000 X-UUID: 25f5f5e7d5b74ab68e9d1d23175efa6e-20200305 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=gkqDoOqHIrOTpmFheXHWiY15sLy0Mn7me1/+UDymw5E=; b=Kxm/E3ZsOhX/RuR/e93d6rkyU7ocdTF8RrkzdLujLzUbfBUB5Sn26qOvsQjOTCFTnzzRN936F4iicr8U1gvbFAtLUCQNjOCdrntS+GddduiTmGgwJMXifXL7Q1cE9S80LUykGdCtBUsepFIiP9dUhoEHGiyQdocYGNXQPrEzqPk=; X-UUID: 25f5f5e7d5b74ab68e9d1d23175efa6e-20200305 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1599998255; Thu, 05 Mar 2020 22:59:56 -0800 Received: from MTKMBS31N1.mediatek.inc (172.27.4.69) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 5 Mar 2020 23:00:51 -0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31N1.mediatek.inc (172.27.4.69) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 6 Mar 2020 14:58:27 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Fri, 6 Mar 2020 14:58:41 +0800 Message-ID: <1583477982.4784.37.camel@mhfsdcap03> Subject: Re: [PATCH v3 03/14] iommu/mediatek: Add device_link between the consumer and the larb devices From: Yong Wu To: Nicolas Boichat Date: Fri, 6 Mar 2020 14:59:42 +0800 In-Reply-To: References: <1567503456-24725-1-git-send-email-yong.wu@mediatek.com> <1567503456-24725-4-git-send-email-yong.wu@mediatek.com> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-TM-SNTS-SMTP: B84E2E8EC000FE6B20341D7962063DB72347CFF9209A3FBB475D95CD84B3A5AB2000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200305_230003_946267_C77CEEBD X-CRM114-Status: GOOD ( 28.04 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: maoguang.meng@mediatek.com, Will Deacon , youlin.pei@mediatek.com, Joerg Roedel , Evan Green , Matthias Kaehlcke , Devicetree List , cui.zhang@mediatek.com, houlong.wei@mediatek.com, Tomasz Figa , sj.huang@mediatek.com, Rob Herring , "moderated list:ARM/Mediatek SoC support" , Matthias Brugger , ming-fan.chen@mediatek.com, linux-arm Mailing List , anan.sun@mediatek.com, srv_heupstream , lkml , chao.hao@mediatek.com, iommu@lists.linux-foundation.org, Robin Murphy 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 Thu, 2020-03-05 at 13:14 +0800, Nicolas Boichat wrote: > On Tue, Sep 3, 2019 at 5:38 PM Yong Wu wrote: > > > > MediaTek IOMMU don't have its power-domain. 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] http://lists.infradead.org/pipermail/linux-mediatek/2019-July/ > > 021500.html > > [2] https://lore.kernel.org/patchwork/patch/1086569/ > > > > Suggested-by: Tomasz Figa > > Signed-off-by: Yong Wu > > --- > > drivers/iommu/mtk_iommu.c | 17 +++++++++++++++++ > > drivers/iommu/mtk_iommu_v1.c | 18 +++++++++++++++++- > > 2 files changed, 34 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index b138b94..2511b3c 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -450,6 +450,9 @@ static int mtk_iommu_add_device(struct device *dev) > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > struct mtk_iommu_data *data; > > struct iommu_group *group; > > + struct device_link *link; > > + struct device *larbdev; > > + unsigned int larbid; > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > return -ENODEV; /* Not a iommu client device */ > > @@ -461,6 +464,14 @@ static int mtk_iommu_add_device(struct device *dev) > > if (IS_ERR(group)) > > return PTR_ERR(group); > > > > + /* Link the consumer device with the smi-larb device(supplier) */ > > + larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); > > I'll mirror the comment I made on gerrit > (https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1361013): > Maybe I'm missing something here, but for example, on MT8173, > vcodec_enc: vcodec@18002000 needs to use both larb3 and larb5, isn't > the code below just adding a link for larb3? Yes. It only add larb3 here. > > Do we need to iterate over all fwspecs->ids to figure out which larbs > we need to add links to each of them? We have checked this venc issue. Currently I have requested our venc guy to seperate larb3-venc and larb5-venc in the driver[1] since they are independent HW actually. I will put it into this series when I send next version. If there is some reasonable driver which have two larbs in it, then the iterating is really necessary, But I don't see it right now. Only using fwspec->ids[0] is enough for now. [1] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1958322 > > > + larbdev = data->larb_imu[larbid].dev; > > + link = device_link_add(dev, larbdev, > > + DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS); > > + if (!link) > > + dev_err(dev, "Unable to link %s\n", dev_name(larbdev)); > > + > > iommu_group_put(group); > > return 0; > > } > > @@ -469,6 +480,8 @@ static void mtk_iommu_remove_device(struct device *dev) > > { > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > struct mtk_iommu_data *data; > > + struct device *larbdev; > > + unsigned int larbid; > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > return; > > @@ -476,6 +489,10 @@ static void mtk_iommu_remove_device(struct device *dev) > > data = fwspec->iommu_priv; > > iommu_device_unlink(&data->iommu, dev); > > > > + larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); > > + larbdev = data->larb_imu[larbid].dev; > > + device_link_remove(dev, larbdev); > > + > > iommu_group_remove_device(dev); > > iommu_fwspec_free(dev); > > } > > diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c > > index 2034d72..a7f22a2 100644 > > --- a/drivers/iommu/mtk_iommu_v1.c > > +++ b/drivers/iommu/mtk_iommu_v1.c > > @@ -423,7 +423,9 @@ static int mtk_iommu_add_device(struct device *dev) > > struct of_phandle_iterator it; > > struct mtk_iommu_data *data; > > struct iommu_group *group; > > - int err; > > + struct device_link *link; > > + struct device *larbdev; > > + int err, larbid; > > > > of_for_each_phandle(&it, err, dev->of_node, "iommus", > > "#iommu-cells", 0) { > > @@ -466,6 +468,14 @@ static int mtk_iommu_add_device(struct device *dev) > > return err; > > } > > > > + /* Link the consumer device with the smi-larb device(supplier) */ > > + larbid = mt2701_m4u_to_larb(fwspec->ids[0]); > > + larbdev = data->larb_imu[larbid].dev; > > + link = device_link_add(dev, larbdev, > > + DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS); > > + if (!link) > > + dev_err(dev, "Unable to link %s\n", dev_name(larbdev)); > > + > > return iommu_device_link(&data->iommu, dev); > > } > > > > @@ -473,6 +483,8 @@ static void mtk_iommu_remove_device(struct device *dev) > > { > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > struct mtk_iommu_data *data; > > + struct device *larbdev; > > + unsigned int larbid; > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > return; > > @@ -480,6 +492,10 @@ static void mtk_iommu_remove_device(struct device *dev) > > data = fwspec->iommu_priv; > > iommu_device_unlink(&data->iommu, dev); > > > > + larbid = mt2701_m4u_to_larb(fwspec->ids[0]); > > + larbdev = data->larb_imu[larbid].dev; > > + device_link_remove(dev, larbdev); > > + > > iommu_group_remove_device(dev); > > iommu_fwspec_free(dev); > > } > > -- > > 1.9.1 > > _______________________________________________ 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 X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74D36C3F2D5 for ; Fri, 6 Mar 2020 07:00: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 4633D2072A for ; Fri, 6 Mar 2020 07:00:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YESnQ/U+"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="Kxm/E3Zs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4633D2072A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date: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=I3239pFsnzM5hWTLQqvXJgGnCAGqI4rikAH/STblre0=; b=YESnQ/U+pKa4Bz Nd1p9hsLQeh85jGWN57BUxEgURbI/HcOOwYeJQbt9dj+oxFOu3nK/Z9TJ1/5XsqIGsp9m0K6lnc1C EDyK8/9rgDrAluusnwIXvObSf6Z9WG1CPmQa2JItHbUDWtp2Sb/4e8MrAWSNY0NTvvmxvNoEgoEBV DLKapSpR530pU+IgtNE/u0NEVhcUcyWOhu8DrXPW6618v50ojPwQRcBfIgNkBZNwXBgP8Fsn+R8pp RgBRFn8WDykWVmW6ihyTzRVN3LCZe4XbIbssCO+4a+yGkgFTnvtf0QOgqvgG8TTuYJZVWA62PqpSD z2H7Ifpf6a5FZZ3q+Oog==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jA6xu-0001Rq-AW; Fri, 06 Mar 2020 07:00:10 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jA6xn-0000M0-Se; Fri, 06 Mar 2020 07:00:05 +0000 X-UUID: 25f5f5e7d5b74ab68e9d1d23175efa6e-20200305 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=gkqDoOqHIrOTpmFheXHWiY15sLy0Mn7me1/+UDymw5E=; b=Kxm/E3ZsOhX/RuR/e93d6rkyU7ocdTF8RrkzdLujLzUbfBUB5Sn26qOvsQjOTCFTnzzRN936F4iicr8U1gvbFAtLUCQNjOCdrntS+GddduiTmGgwJMXifXL7Q1cE9S80LUykGdCtBUsepFIiP9dUhoEHGiyQdocYGNXQPrEzqPk=; X-UUID: 25f5f5e7d5b74ab68e9d1d23175efa6e-20200305 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1599998255; Thu, 05 Mar 2020 22:59:56 -0800 Received: from MTKMBS31N1.mediatek.inc (172.27.4.69) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 5 Mar 2020 23:00:51 -0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS31N1.mediatek.inc (172.27.4.69) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 6 Mar 2020 14:58:27 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Fri, 6 Mar 2020 14:58:41 +0800 Message-ID: <1583477982.4784.37.camel@mhfsdcap03> Subject: Re: [PATCH v3 03/14] iommu/mediatek: Add device_link between the consumer and the larb devices From: Yong Wu To: Nicolas Boichat Date: Fri, 6 Mar 2020 14:59:42 +0800 In-Reply-To: References: <1567503456-24725-1-git-send-email-yong.wu@mediatek.com> <1567503456-24725-4-git-send-email-yong.wu@mediatek.com> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-TM-SNTS-SMTP: B84E2E8EC000FE6B20341D7962063DB72347CFF9209A3FBB475D95CD84B3A5AB2000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200305_230003_946267_C77CEEBD X-CRM114-Status: GOOD ( 28.04 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: maoguang.meng@mediatek.com, Will Deacon , youlin.pei@mediatek.com, Joerg Roedel , Evan Green , Matthias Kaehlcke , Devicetree List , cui.zhang@mediatek.com, houlong.wei@mediatek.com, Tomasz Figa , sj.huang@mediatek.com, Rob Herring , "moderated list:ARM/Mediatek SoC support" , Matthias Brugger , ming-fan.chen@mediatek.com, linux-arm Mailing List , anan.sun@mediatek.com, srv_heupstream , lkml , chao.hao@mediatek.com, iommu@lists.linux-foundation.org, Robin Murphy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2020-03-05 at 13:14 +0800, Nicolas Boichat wrote: > On Tue, Sep 3, 2019 at 5:38 PM Yong Wu wrote: > > > > MediaTek IOMMU don't have its power-domain. 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] http://lists.infradead.org/pipermail/linux-mediatek/2019-July/ > > 021500.html > > [2] https://lore.kernel.org/patchwork/patch/1086569/ > > > > Suggested-by: Tomasz Figa > > Signed-off-by: Yong Wu > > --- > > drivers/iommu/mtk_iommu.c | 17 +++++++++++++++++ > > drivers/iommu/mtk_iommu_v1.c | 18 +++++++++++++++++- > > 2 files changed, 34 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > > index b138b94..2511b3c 100644 > > --- a/drivers/iommu/mtk_iommu.c > > +++ b/drivers/iommu/mtk_iommu.c > > @@ -450,6 +450,9 @@ static int mtk_iommu_add_device(struct device *dev) > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > struct mtk_iommu_data *data; > > struct iommu_group *group; > > + struct device_link *link; > > + struct device *larbdev; > > + unsigned int larbid; > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > return -ENODEV; /* Not a iommu client device */ > > @@ -461,6 +464,14 @@ static int mtk_iommu_add_device(struct device *dev) > > if (IS_ERR(group)) > > return PTR_ERR(group); > > > > + /* Link the consumer device with the smi-larb device(supplier) */ > > + larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); > > I'll mirror the comment I made on gerrit > (https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1361013): > Maybe I'm missing something here, but for example, on MT8173, > vcodec_enc: vcodec@18002000 needs to use both larb3 and larb5, isn't > the code below just adding a link for larb3? Yes. It only add larb3 here. > > Do we need to iterate over all fwspecs->ids to figure out which larbs > we need to add links to each of them? We have checked this venc issue. Currently I have requested our venc guy to seperate larb3-venc and larb5-venc in the driver[1] since they are independent HW actually. I will put it into this series when I send next version. If there is some reasonable driver which have two larbs in it, then the iterating is really necessary, But I don't see it right now. Only using fwspec->ids[0] is enough for now. [1] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1958322 > > > + larbdev = data->larb_imu[larbid].dev; > > + link = device_link_add(dev, larbdev, > > + DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS); > > + if (!link) > > + dev_err(dev, "Unable to link %s\n", dev_name(larbdev)); > > + > > iommu_group_put(group); > > return 0; > > } > > @@ -469,6 +480,8 @@ static void mtk_iommu_remove_device(struct device *dev) > > { > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > struct mtk_iommu_data *data; > > + struct device *larbdev; > > + unsigned int larbid; > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > return; > > @@ -476,6 +489,10 @@ static void mtk_iommu_remove_device(struct device *dev) > > data = fwspec->iommu_priv; > > iommu_device_unlink(&data->iommu, dev); > > > > + larbid = MTK_M4U_TO_LARB(fwspec->ids[0]); > > + larbdev = data->larb_imu[larbid].dev; > > + device_link_remove(dev, larbdev); > > + > > iommu_group_remove_device(dev); > > iommu_fwspec_free(dev); > > } > > diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c > > index 2034d72..a7f22a2 100644 > > --- a/drivers/iommu/mtk_iommu_v1.c > > +++ b/drivers/iommu/mtk_iommu_v1.c > > @@ -423,7 +423,9 @@ static int mtk_iommu_add_device(struct device *dev) > > struct of_phandle_iterator it; > > struct mtk_iommu_data *data; > > struct iommu_group *group; > > - int err; > > + struct device_link *link; > > + struct device *larbdev; > > + int err, larbid; > > > > of_for_each_phandle(&it, err, dev->of_node, "iommus", > > "#iommu-cells", 0) { > > @@ -466,6 +468,14 @@ static int mtk_iommu_add_device(struct device *dev) > > return err; > > } > > > > + /* Link the consumer device with the smi-larb device(supplier) */ > > + larbid = mt2701_m4u_to_larb(fwspec->ids[0]); > > + larbdev = data->larb_imu[larbid].dev; > > + link = device_link_add(dev, larbdev, > > + DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS); > > + if (!link) > > + dev_err(dev, "Unable to link %s\n", dev_name(larbdev)); > > + > > return iommu_device_link(&data->iommu, dev); > > } > > > > @@ -473,6 +483,8 @@ static void mtk_iommu_remove_device(struct device *dev) > > { > > struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > struct mtk_iommu_data *data; > > + struct device *larbdev; > > + unsigned int larbid; > > > > if (!fwspec || fwspec->ops != &mtk_iommu_ops) > > return; > > @@ -480,6 +492,10 @@ static void mtk_iommu_remove_device(struct device *dev) > > data = fwspec->iommu_priv; > > iommu_device_unlink(&data->iommu, dev); > > > > + larbid = mt2701_m4u_to_larb(fwspec->ids[0]); > > + larbdev = data->larb_imu[larbid].dev; > > + device_link_remove(dev, larbdev); > > + > > iommu_group_remove_device(dev); > > iommu_fwspec_free(dev); > > } > > -- > > 1.9.1 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel