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=-17.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,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 6837DC4320A for ; Mon, 30 Aug 2021 17:14:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4D72B60F5C for ; Mon, 30 Aug 2021 17:14:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238031AbhH3RPq (ORCPT ); Mon, 30 Aug 2021 13:15:46 -0400 Received: from mailgw01.mediatek.com ([60.244.123.138]:48832 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S235853AbhH3RPo (ORCPT ); Mon, 30 Aug 2021 13:15:44 -0400 X-UUID: b9344bcaf07d4ec3a642a0248debe4ad-20210831 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=o3ZzAkBAEoLuL6O6uHI5aTvY6v4T4q0T9URohE9sqsM=; b=mJ8XatUvzQB45lHJPW7HUOVnKLO84j0/w7doFAajLOA4yUAHQ7Yw9Xo5WwWlWN2qMYsY+Xa9aQe+3pFVgKWiYATxm+9oWpiIGAY5iTyoci7em0TEEwXZaRi9+oST8f2fK2la+Omf7R4WYKxXQBuoTNHboRHJeUwRrBkfpumpTf0=; X-UUID: b9344bcaf07d4ec3a642a0248debe4ad-20210831 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 627636284; Tue, 31 Aug 2021 01:14:48 +0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by mtkmbs05n1.mediatek.inc (172.21.101.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 31 Aug 2021 01:14:46 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 31 Aug 2021 01:14:46 +0800 Message-ID: <1630343686.7403.44.camel@mhfsdcap03> Subject: Re: [PATCH v7 7/7] media: mtk-mdp: use mdp-rdma0 alias to point to MDP master From: houlong wei To: Enric Balletbo i Serra CC: Eizan Miyamoto , "linux-kernel@vger.kernel.org" , "chunkuang.hu@kernel.org" , Yong Wu =?UTF-8?Q?=28=E5=90=B4=E5=8B=87=29?= , "wenst@chromium.org" , "CK Hu =?UTF-8?Q?=28=E8=83=A1=E4=BF=8A=E5=85=89=29?=" , "Yongqiang Niu =?UTF-8?Q?=28=E7=89=9B=E6=B0=B8=E5=BC=BA=29?=" , "Andrew-CT Chen =?UTF-8?Q?=28=E9=99=B3=E6=99=BA=E8=BF=AA=29?=" , Matthias Brugger , Mauro Carvalho Chehab , "Minghsiu Tsai =?UTF-8?Q?=28=E8=94=A1=E6=98=8E=E4=BF=AE=29?=" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , Date: Tue, 31 Aug 2021 01:14:46 +0800 In-Reply-To: References: <20210825063323.3607738-1-eizan@chromium.org> <20210825163247.v7.7.I2049e180dca12e0d1b3178bfc7292dcf9e05ac28@changeid> <1629880999.12893.17.camel@mhfsdcap03> <0c9fa482-57dd-d4ef-c65b-01f137c57359@collabora.com> <1629904697.15752.11.camel@mhfsdcap03> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-MTK: N Content-Transfer-Encoding: base64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org SGkgRW5yaWMsDQoNCk15IGFuc3dlcnMgYXJlIGFzIGZvbGxvd3MuVGhhbmtzIGZvciBkZWVwIHRo aW5raW5nIGFib3V0IG10ay1tZHAuDQoNClJlZ2FyZHMsDQpIb3Vsb25nDQoNCk9uIFRodSwgMjAy MS0wOC0yNiBhdCAwMDo1NCArMDgwMCwgRW5yaWMgQmFsbGV0Ym8gaSBTZXJyYSB3cm90ZToNCj4g SGkgSG91bG9uZywNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciBhbnN3ZXIsIHNvbWUgbW9yZSBx dWVzdGlvbnMgYmVsb3cgOi0pDQo+IA0KPiBPbiAyNS84LzIxIDE3OjE4LCBob3Vsb25nIHdlaSB3 cm90ZToNCj4gPiBPbiBXZWQsIDIwMjEtMDgtMjUgYXQgMTc6MDcgKzA4MDAsIEVucmljIEJhbGxl dGJvIGkgU2VycmEgd3JvdGU6DQo+ID4+IEhpIEhvdWxvbmcsDQo+ID4+DQo+ID4+IFRoYW5rIHlv dSBmb3IgZm9sbG93aW5nIHVwIHRoaXMgcGF0Y2hzZXQuIEkgaGF2ZSBzb21lIHF1ZXN0aW9ucyB0 byB0cnkgdG8NCj4gPj4gdW5kZXJzdGFuZCBiZXR0ZXIgdGhlIGhhcmR3YXJlIHRob3VnaC4NCj4g Pj4NCj4gPj4gT24gMjUvOC8yMSAxMDo0MywgaG91bG9uZyB3ZWkgd3JvdGU6DQo+ID4+PiBIaSBF aXphbiwNCj4gPj4+DQo+ID4+PiBUaGFua3MgZm9yIHlvdSBwYXRjaC4gSSBoYXZlIGlubGluZSBj b21tZW50IGJlbG93Lg0KPiA+Pj4NCj4gPj4+IFJlZ2FyZHMsDQo+ID4+PiBIb3Vsb25nDQo+ID4+ Pg0KPiA+Pj4gT24gV2VkLCAyMDIxLTA4LTI1IGF0IDE0OjMzICswODAwLCBFaXphbiBNaXlhbW90 byB3cm90ZToNCj4gPj4+PiAuLi4gSW5zdGVhZCBvZiBkZXBlbmRpbmcgb24gdGhlIHByZXNlbmNl IG9mIGEgbWVkaWF0ZWssdnB1IHByb3BlcnR5IGluDQo+ID4+Pj4gdGhlIGRldmljZSBub2RlLg0K PiA+Pj4+DQo+ID4+Pj4gVGhhdCBwcm9wZXJ0eSB3YXMgb3JpZ2luYWxseSBhZGRlZCB0byBsaW5r IHRvIHRoZSB2cHUgbm9kZSBzbyB0aGF0IHRoZQ0KPiA+Pj4+IG10a19tZHBfY29yZSBkcml2ZXIg Y291bGQgcGFzcyB0aGUgcmlnaHQgZGV2aWNlIHRvDQo+ID4+Pj4gdnB1X3dkdF9yZWdfaGFuZGxl cigpLiBIb3dldmVyIGluIGEgcHJldmlvdXMgcGF0Y2ggaW4gdGhpcyBzZXJpZXMsDQo+ID4+Pj4g dGhlIGRyaXZlciBoYXMgYmVlbiBtb2RpZmllZCB0byBzZWFyY2ggdGhlIGRldmljZSB0cmVlIGZv ciB0aGF0IG5vZGUNCj4gPj4+PiBpbnN0ZWFkLg0KPiA+Pj4+DQo+ID4+Pj4gVGhhdCBwcm9wZXJ0 eSB3YXMgYWxzbyB1c2VkIHRvIGluZGljYXRlIHRoZSBwcmltYXJ5IE1EUCBkZXZpY2UsIHNvIHRo YXQNCj4gPj4+PiBpdCBjYW4gYmUgcGFzc2VkIHRvIHRoZSBWNEwyIHN1YnN5c3RlbSBhcyB3ZWxs IGFzIHJlZ2lzdGVyIGl0IHRvIGJlDQo+ID4+Pj4gdXNlZCB3aGVuIHNldHRpbmcgdXAgcXVldWVz IGluIHRoZSBvcGVuKCkgY2FsbGJhY2sgZm9yIHRoZSBmaWxlc3lzdGVtDQo+ID4+Pj4gZGV2aWNl IG5vZGUgdGhhdCBpcyBjcmVhdGVkLiBJbiB0aGlzIGNhc2UsIGFzc3VtaW5nIHRoYXQgdGhlIHBy aW1hcnkNCj4gPj4+PiBNRFAgZGV2aWNlIGlzIHRoZSBvbmUgd2l0aCBhIHNwZWNpZmljIGFsaWFz IHNlZW1zIHVzZWFibGUgYmVjYXVzZSB0aGUNCj4gPj4+PiBhbHRlcm5hdGl2ZSBpcyB0byBhZGQg YSBwcm9wZXJ0eSB0byB0aGUgZGV2aWNlIHRyZWUgd2hpY2ggZG9lc24ndA0KPiA+Pj4+IGFjdHVh bGx5IHJlcHJlc2VudCBhbnkgZmFjZXQgb2YgaGFyZHdhcmUgKGkuZS4sIHRoaXMgYmVpbmcgdGhl IHByaW1hcnkNCj4gPj4+PiBNRFAgZGV2aWNlIGlzIGEgc29mdHdhcmUgZGVjaXNpb24pLiBJbiBv dGhlciB3b3JkcywgdGhpcyBzb2x1dGlvbiBpcw0KPiA+Pj4+IGVxdWFsbHkgYXMgYXJiaXRyYXJ5 LCBidXQgYXQgbGVhc3QgaXQgZG9lc24ndCBhZGQgYSBwcm9wZXJ0eSB0byBhDQo+ID4+Pj4gZGV2 aWNlIG5vZGUgd2hlcmUgc2FpZCBwcm9wZXJ0eSBpcyB1bnJlbGF0ZWQgdG8gdGhlIGhhcmR3YXJl IHByZXNlbnQuDQo+ID4+Pj4NCj4gPj4+PiBTaWduZWQtb2ZmLWJ5OiBFaXphbiBNaXlhbW90byA8 ZWl6YW5AY2hyb21pdW0ub3JnPg0KPiA+Pj4+IFJldmlld2VkLWJ5OiBFbnJpYyBCYWxsZXRibyBp IFNlcnJhIDxlbnJpYy5iYWxsZXRib0Bjb2xsYWJvcmEuY29tPg0KPiA+Pj4+IC0tLQ0KPiA+Pj4+ DQo+ID4+Pj4gKG5vIGNoYW5nZXMgc2luY2UgdjEpDQo+ID4+Pj4NCj4gPj4+PiAgZHJpdmVycy9t ZWRpYS9wbGF0Zm9ybS9tdGstbWRwL210a19tZHBfY29tcC5jIHwgNTYgKysrKysrKysrKysrKy0t LS0tLQ0KPiA+Pj4+ICBkcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb3Jl LmMgfCAzNiArKysrKysrKy0tLS0NCj4gPj4+PiAgMiBmaWxlcyBjaGFuZ2VkLCA2NCBpbnNlcnRp b25zKCspLCAyOCBkZWxldGlvbnMoLSkNCj4gPj4+Pg0KPiA+Pj4+IGRpZmYgLS1naXQgYS9kcml2 ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb21wLmMgYi9kcml2ZXJzL21lZGlh L3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb21wLmMNCj4gPj4+PiBpbmRleCA4NWVmMjc0ODQx YTMuLjk1Mjc2NDlkZTk4ZSAxMDA2NDQNCj4gPj4+PiAtLS0gYS9kcml2ZXJzL21lZGlhL3BsYXRm b3JtL210ay1tZHAvbXRrX21kcF9jb21wLmMNCj4gPj4+PiArKysgYi9kcml2ZXJzL21lZGlhL3Bs YXRmb3JtL210ay1tZHAvbXRrX21kcF9jb21wLmMNCj4gPj4+PiBAQCAtMTUxLDI5ICsxNTEsNTAg QEAgdm9pZCBtdGtfbWRwX2NvbXBfY2xvY2tfb2ZmKHN0cnVjdCBtdGtfbWRwX2NvbXAgKmNvbXAp DQo+ID4+Pj4gIAkJbXRrX3NtaV9sYXJiX3B1dChjb21wLT5sYXJiX2Rldik7DQo+ID4+Pj4gIH0N Cj4gPj4+PiAgDQo+ID4+Pj4gLXN0YXRpYyBpbnQgbXRrX21kcF9jb21wX2JpbmQoc3RydWN0IGRl dmljZSAqZGV2LCBzdHJ1Y3QgZGV2aWNlICptYXN0ZXIsIHZvaWQgKmRhdGEpDQo+ID4+Pj4gKy8q DQo+ID4+Pj4gKyAqIFRoZSBNRFAgbWFzdGVyIGRldmljZSBub2RlIGlzIGlkZW50aWZpZWQgYnkg dGhlIGRldmljZSB0cmVlIGFsaWFzDQo+ID4+Pj4gKyAqICJtZHAtcmRtYTAiLg0KPiA+Pj4+ICsg Ki8NCj4gPj4+PiArc3RhdGljIGJvb2wgaXNfbWRwX21hc3RlcihzdHJ1Y3QgZGV2aWNlICpkZXYp DQo+ID4+Pj4gK3sNCj4gPj4+PiArCXN0cnVjdCBkZXZpY2Vfbm9kZSAqYWxpYXNlcywgKm1kcF9y ZG1hMF9ub2RlOw0KPiA+Pj4+ICsJY29uc3QgY2hhciAqbWRwX3JkbWEwX3BhdGg7DQo+ID4+Pj4g Kw0KPiA+Pj4+ICsJaWYgKCFkZXYtPm9mX25vZGUpDQo+ID4+Pj4gKwkJcmV0dXJuIGZhbHNlOw0K PiA+Pj4+ICsNCj4gPj4+PiArCWFsaWFzZXMgPSBvZl9maW5kX25vZGVfYnlfcGF0aCgiL2FsaWFz ZXMiKTsNCj4gPj4+PiArCWlmICghYWxpYXNlcykgew0KPiA+Pj4+ICsJCWRldl9lcnIoZGV2LCAi bm8gYWxpYXNlcyBmb3VuZCBmb3IgbWRwLXJkbWEwIik7DQo+ID4+Pj4gKwkJcmV0dXJuIGZhbHNl Ow0KPiA+Pj4+ICsJfQ0KPiA+Pj4+ICsNCj4gPj4+PiArCW1kcF9yZG1hMF9wYXRoID0gb2ZfZ2V0 X3Byb3BlcnR5KGFsaWFzZXMsICJtZHAtcmRtYTAiLCBOVUxMKTsNCj4gPj4+PiArCWlmICghbWRw X3JkbWEwX3BhdGgpIHsNCj4gPj4+PiArCQlkZXZfZXJyKGRldiwgImdldCBtZHAtcmRtYTAgcHJv cGVydHkgb2YgL2FsaWFzZXMgZmFpbGVkIik7DQo+ID4+Pj4gKwkJcmV0dXJuIGZhbHNlOw0KPiA+ Pj4+ICsJfQ0KPiA+Pj4+ICsNCj4gPj4+PiArCW1kcF9yZG1hMF9ub2RlID0gb2ZfZmluZF9ub2Rl X2J5X3BhdGgobWRwX3JkbWEwX3BhdGgpOw0KPiA+Pj4+ICsJaWYgKCFtZHBfcmRtYTBfbm9kZSkg ew0KPiA+Pj4+ICsJCWRldl9lcnIoZGV2LCAicGF0aCByZXNvbHV0aW9uIGZhaWxlZCBmb3IgJXMi LCBtZHBfcmRtYTBfcGF0aCk7DQo+ID4+Pj4gKwkJcmV0dXJuIGZhbHNlOw0KPiA+Pj4+ICsJfQ0K PiA+Pj4+ICsNCj4gPj4+PiArCXJldHVybiBkZXYtPm9mX25vZGUgPT0gbWRwX3JkbWEwX25vZGU7 DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFib3V0IGhvdyB0byBkZXRlcm1pbmUgdGhlIG1hc3RlciBt ZHAgZHJpdmVyLCB3ZSBhbHNvIGNhbg0KPiA+Pj4ganVkZ2UgdGhlIGNvbXBvbmVudCB0eXBlLiBU aGUgY29tcG9uZW50IHR5cGUgY2FuIGJlIGdvdHRlbiBieSBjYWxsaW5nDQo+ID4+PiBvZl9kZXZp Y2VfZ2V0X21hdGNoX2RhdGEoZGV2KS4gSWYgdGhlIGNvbXBvbmVudCBpcyBNVEtfTURQX1JETUEs IGl0IGlzDQo+ID4+PiB0aGUgbWFzdGVyIGRyaXZlci4gTm8gbWF0dGVyIGl0IGlzIG1kcF9yZG1h MCBvciBtZHBfcmRtYTEuDQo+ID4+DQo+ID4+DQo+ID4+IEknbSBjb25mdXNlZCwgeW91IG1lYW4g dGhhdCB0aGUgY29tcG9uZW50IHR5cGUsIGFrYSBNVEtfTURQX1JETUEgaXMgb25seSBzZXQgZm9y DQo+ID4+IG10a19tZHBfcmRtYTA/IGlzbid0IG10a19kbXBfcmRtYTEgYWxzbyBhIE1US19NRFBf UkRNQSB0eXBlPyBCZWNhdXNlIGxvb2tzIHdlaXJkDQo+ID4+IHRvIG1lIHRoYXQgdHdvIHJkbWEg aGF2ZSBkaWZmZW50IHR5cGVzLg0KPiA+Pg0KPiA+IEhpIEVucmljLA0KPiA+IA0KPiA+IEkgY2Fu IHVuZGVyc3RhbmQgeW91ciBkb3VidHMuIEZvciBtdGstbWRwIGRpcnZlciwgaXQgaXMgcmVhbGx5 IGRpZmZpY3VsdA0KPiA+IHRvIHVuZGVyc3RhbmQgdGhlIHJlbGF0aW9uc2hpcCBhbW9uZyB0aGUg Y29tcG9uZW50cy4gQmVjYXVzZSB0aGUgTURQDQo+ID4gaGFyZHdhcmUgcGF0aCBpcyBjb25maWd1 cmVkIGFuZCBjb25uZWN0ZWQgaW4gdGhlIFZQVSBmaXJtd2FyZS4NCj4gDQo+IFNvIGlzIGZpeGVk IGJ5IHRoZSBWUFUgZmlybXdhcmUgYW5kIGNhbid0IGJlIGNoYW5nZWQgdmlhLCBpLmUgd3JpdGlu ZyBzb21lDQo+IHJlZ2lzdGVycz8gQ2FuJ3QgYmUgcGxhdGZvcm0gZGF0YSB0aGVuPw0KPiANCj4g SWYgdGhhdCdzIHRoZSBjYXNlLCBjYW4geW91IGRyYXcgdGhlIG1kcCBoYXJkd2FyZSBwYXRoIGZv ciBpLmUgTVQ4MTczPyAoc28gSQ0KPiBoYXZlIGEgYmV0dGVyIHVuZGVyc3RhbmRpbmcpDQo+IA0K DQpJIHJldmlld2VkIHRoZSBtdDgxNzMgVlBVIGZpcm13YXJlIGNvZGUgYW5kIGZvdW5kIGl0IG9u bHkgdXNlIDEgTURQDQpwYXRoLlBlcmhhcHMgb25lIE1EUCBwYXRoIGNvdWxkIG1lZXQgdGhlIHBy b2plY3QgdGVhbSdzIHJlcXVpcmVtZW50IHdoZW4NCnRoZSBWUFUgZmlybXdhcmUgd2FzIGltcGxl bWVudGVkLg0KQSBNRFAgcGF0aCBpcyBhIGRhdGEgcGF0aCB3aGljaCBjb25zaXN0cyBvZiBzZXZl cmFsIE1EUCBoYXJkd2FyZQ0KZW5naW5lcywgZS5nLiBtZHBfcmRtYTEtPm1kcF9yc3oxLT5tZHBf d3JvdDEsDQptZHBfcmRtYTItPm1kcF9yc3oyLT5tZHBfd3JvdDIuIElkZWFsbHksaWYgdGhlcmUg YXJlIG11bHRpcGxlIE1EUCBwYXRocywNCnRoZSB1c2VycyhlLmcuIGFwcGxpY2F0aW9ucykgY2Fu IHVzZSB0aGVtIGNvbmN1cnJlbnRseS4NCg0KPiANCj4gPiBGb3IgTVQ4MTczLCB0aGUgY29tcG9u ZW50IHR5cGUgb2YgbXRrX21kcF9yZG1hMCBhbmQgbXRrX21kcF9yZG1hMSBhcmUNCj4gPiBib3Ro IE1US19NRFBfUkRNQS4gRXZlbiB0aG91Z2ggdGhlIG10ay1tZHAgZHJpdmVyJ3MgY29tcG9uZW50 IGxpc3QNCj4gPiBjb250YWlucyBib3RoIG9mIHRoZW0sIG9ubHkgb25lIGNvcnJlc3BvbmRpbmcg aGFyZHdhcmUgY29tcG9uZW50IHRha2VzDQo+ID4gZWZmZWN0IGR1cmluZyB0aGUgcHJvY2Vzc2lu ZyBvZiBhIGZyYW1lLCB0aGUgVlBVIGRlY2lkZXMgaXQuDQo+ID4gDQo+IA0KPiBTbyBJSVVDIHRo ZSBWUFUgZmlybXdhcmUgZGVjaWRlcyB3aGljaCByZG1hIHVzZXMgb24gZXZlcnkgZnJhbWUsIHJp Z2h0PyBGcm9tIGh3DQo+IHBvaW50IG9mIHZpZXcsIHdoeSBvbmUgb2YgdGhlbSBuZWVkIHRvIGJl IG1hc3Rlcj8NCj4gDQoNCkZvciBtdDgxNzMsIHRoZSBWUFUgZmlybXdhcmUgb25seSB1c2Ugb25l IHJkbWEgYmVjYXVzZSBhbm90aGVyIE1EUCBwYXRoDQppcyBub3QgaW1wbGVtZW50ZWQuSWYgd2Ug aW1wbGVtZW50IG11bHRpcGxlIE1EUCBwYXRocyBpbiBjZXJ0YWluDQpwcm9qZWN0LCBlYWNoIHJk bWEgY2FuIGJlIG1hc3Rlci4NCg0KDQo+ID4gUmVnYXJkcywNCj4gPiBIb3Vsb25nDQo+ID4+DQo+ ID4+PiBodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9waXBlcm1haWwvbGludXgtbWVkaWF0ZWsv MjAyMS1BdWd1c3QvMDI4NTMzLmh0bWwNCj4gPj4+DQo+ID4+PiBJTU8sIGp1ZGdpbmcgaXQgYnkg Y29tcG9uZW50IHR5cGUgaXMgbW9yZSBmbGV4aWJsZSBiZWNhdXNlIGl0IGRvZXMgbm90DQo+ID4+ PiBsaW1pdCB0byAnbWRwX3JkbWEwJy4NCj4gPj4+DQo+ID4+DQo+ID4+IFVzaW5nIGFuIGFsaWFz IGxpa2UgRWl6YW4gZGlkIGlzIGFsc28gZmxleGlibGUsIHlvdSBvbmx5IG5lZWQgdG8gc2V0IG1k cC1yZG1hMA0KPiA+PiB0byBwb2ludCB0aGUgbWRwX3JkbWExIG5vZGUuDQo+ID4+DQo+ID4+IFdo YXQgSSBhbSByZWFsbHkgaW50ZXJlc3RlZCB0byBrbm93IGlzIHRoZSBkaWZmZXJlbmNlcyBiZXR3 ZWVuIHRoZSBwbGF0Zm9ybXMgdG8NCj4gPj4gdW5kZXJzdGFuZCBpZiB0aGlzIGlzIHJlYWxseSBh IHBsYXRmb3JtIGhhcmR3YXJlIHByb3BlcnR5IG9yIGEgc29mdHdhcmUNCj4gPj4gY29uZmlndXJh YmxlIHRoaW5nLCBzbyB3b3VsZCBoZWxwIGlmIHlvdSBjYW4gZ2l2ZSB1c2UgdGhlIGRpZmZlcmVu dCB1c2UgY2FzZXMNCj4gPj4gZm9yIGRpZmZlcmVudCBTb0NzLg0KPiA+Pg0KPiA+PiBGb3IgTVQ4 MTczIHdoaWNoIGlzIHRoZSBtYXN0ZXIgZGV2aWNlPyBpcyBfYWx3YXlzXyByZG1hMCBvciBjYW4g YWxzbyBiZSByZG1hMT8NCj4gPj4NCj4gPj4gT3IgbWF5YmUgd2hhdCBpcyBub3QgY2xlYXIgaGVy ZSBpcyB3aGF0IGV4YWN0bHkgbWVhbnMgYmUgYSBtYXN0ZXIgZGV2aWNlPw0KPiA+Pg0KPiA+PiBX aGF0IGFib3V0IE1UODE4MyBhbmQgb3RoZXIgU29Dcz8NCj4gPj4NCj4gPj4gVGhhbmtzLA0KPiA+ PiAgIEVucmljDQo+ID4+DQo+ID4gSGkgRW5yaWMsDQo+ID4gDQo+ID4gQmVmb3JlIGFuc3dlciB5 b3VyIHF1ZXN0aW9ucywgbGV0J3MgdW5pZnkgdGhlIGNvbmNlcHQgb2YgdGhlIG1hc3Rlcg0KPiA+ IGRldmljZS5JZiBhbiBNRFAgZGV2aWNlLXRyZWUgbm9kZSBjYW4gbm90IG9ubHkgZ2VuZXJhdGUg YSAvZGV2L3ZpZGVvDQo+ID4gZGV2aWNlIG5vZGUsIGJ1dCBhbHNvIGNhbiBnZW5lcmF0ZSBhIG10 ayBjb21wb25lbnQgZGV2aWNlIG5vZGUsIHRoZW4NCj4gPiB0aGlzIGNvbXBvbmVudCBkZXZpY2Ug aXMgdGhlIG1hc3RlciBkZXZpY2UuDQo+IA0KPiBTb3JyeSwgd2hhdCB5b3UgbWVhbiB3aXRoIGEg bXRrIGNvbXBvbmVudCBkZXZpY2Ugbm9kZT8NCg0KTXkgbWVhbmluZyBpcyB0aGF0IHRoZSBkZXZp Y2UtdHJlZSBub2RlIGNhbiBnZW5lcmF0ZSBhIHBsYXRmb3JtIGRldmljZSwNCml0IGlzIHdoYXQg dGhlIG10a19tZHBfY29tcC5jIGRvZXMuDQoNCj4gDQo+ID4gRnJvbSB0aGUgcGVyc3BlY3RpdmUg b2YgdGhlIGRldmljZSB0cmVlIG5vZGUsIHRoZSBjb21wYXRpYmxlIG9mIGEgTURQDQo+ID4gZGV2 aWNlIHRyZWUgbm9kZSBjb250YWlucyBib3RoICJtZWRpYXRlayxtdDgxNzMtbWRwLXJkbWEiIGFu ZA0KPiA+ICJtZWRpYXRlayxtdDgxNzMtbWRwIiwgdGhlbiBpdHMgY29ycmVzcG9uZGluZyBtdGsg Y29tcG9uZW50IGRldmljZSBpcw0KPiA+IHRoZSBtYXN0ZXIgZGV2aWNlLg0KPiANCj4gU28gdGhh dCdzIHdoYXQncyB3cm9uZywgYW5kIEVpemFuIHBhdGNoZXMgZ2V0IHJpZCBvZiB0aGlzLiBJbiB0 aGlzIGNhc2UgeW91DQo+IGNhbid0IHVzZSBkZXZpY2UtdHJlZSB0byBzcGVjaWZ5IHN1Y2ggbWFz dGVyIGRldmljZS4gRGV2aWNlLXRyZWUgaXMgb25seSBhYm91dA0KPiBoYXJkd2FyZSBkZXNjcmlw dGlvbiwgY2FuJ3QgYmUgdXNlZCwgaW4gdGhpcyBjYXNlLCBhcyBlbnRyeSBwb2ludCB0byBpbnN0 YW50aWF0ZQ0KPiB0aGUgbWRwIGRyaXZlci4gSGVuY2UgRWl6YW4gcGF0Y2hlcyBjaGFuZ2UgdGhp cywgYW5kIG1kcCBpcyBpbnN0YW50aWF0ZWQgYnkgdGhlDQo+IG1tc3lzIGRyaXZlci4gU2ltaWxh ciB0byB3aGF0IHdlIGRvIGZvciB0aGUgZHJtIGRyaXZlci4NCj4gDQo+IEZvciB0aGUgdHdvIGh3 IHJkbWEgYmxvY2tzIHRoZSBjb21wYXRpYmxlIHNob3VsZCBiZSBqdXN0DQo+ICJtZWRpYXRlayxt dDgxNzMtbWRwLXJkbWEiIGluIHRoaXMgY2FzZS4NCj4gDQo+IFRoYW5rcywNCj4gICBFbnJpYw0K DQpNeSBjb25zaWRlcmF0aW9uIGlzIGhvdyB0aGUgZHJpdmVyIHN1cHBvcnRzIGl0IHdoZW4gdGhl cmUgYXJlIG11bHRpcGxlDQpNRFAgcGF0aHMuIEFzc3VtZSB0aGVyZSBhcmUgMiBNRFAgcGF0aHMs IGFzIGEgVjRMMiBkcml2ZXIsIG10ay1tZHAgY2FuDQpnZW5lcmF0ZXMgdHdvIGRldmljZSBub2Rl cywgZS5nLiAvZGV2L3ZpZGVvMCBzdXBwb3J0cyBvbmUgb2YgTURQDQpwYXRoLCAvZGV2L3ZpZGVv MSBzdXBwb3J0cyBhbm90aGVyIE1EUCBwYXRoLg0KDQo+ID4gU2luY2UgdGhpcyBjb25jZXB0IGNv bWVzIGZyb20gRWl6YW4ncyBwYXRjaGVzLCBpZiBteSB1bmRlcnN0YW5kaW5nIGlzDQo+ID4gZGlm ZmVyZW50IGZyb20geW91cnMsIHBsZWFzZSBsZXQgbWUga25vdywgdGhhbmtzLg0KPiA+IA0KPiA+ IElmIHRoZXJlIGlzIG9ubHkgb25lIG1hc3RlciBkZXZpY2UsIEkgZnVsbHkgYWdyZWUgd2l0aCB5 b3UuIEZvciBNVDgxNzMsDQo+ID4gYm90aCBtZHBfcmRtYTAgYW5kIG1kcF9yZG1hMSBjYW4gYmUg bWFzdGVyIGRldmljZSBhdCB0aGUgc2FtZSB0aW1lLg0KPiA+IEJ1dCBub3cgb25seSBtZHBfcmRt YTAgdGFrZXMgdGhpcyByb2xlLCBwZXJoYXBzIGJlY2F1c2Ugb25lIE1EUCBoYXJkd2FyZQ0KPiA+ IHBhdGggY291bGQgbWVldCB0aGUgcHJvamVjdCdzIHRoZSByZXF1aXJlbWVudCBzaXggeWVhcnMg YWdvLg0KPiA+IEluIHNvbWUgcHJvamVjdCwgd2UgaGF2ZSB0d28gb3IgbW9yZSBNRFAgaGFyZHdh cmUgcGF0aHMsIHdlIGNhbg0KPiA+IGNvbmZpZ3VyZSBhbGwgdGhlIG1kcF9yZG1hIGNvbXBvbmVu dHMgYXMgbWFzdGVyIGRldmljZXMsIGFuZCB0aGVyZSB3aWxsDQo+ID4gYmUgc2V2ZXJhbCAvZGV2 L3ZpZGVvIGRldmljZSBub2Rlcy4gVGhlIHVzZXIgY2FuIGNvbnRyb2wgdGhlbQ0KPiA+IGNvbmN1 cnJlbnRseS4NCj4gPiANCj4gPiBSZWdhcmRzLA0KPiA+IEhvdWxvbmcNCj4gPiANCj4gPj4NCj4g Pj4+PiArfQ0KPiA+Pj4+ICsNCj4gPj4+PiArc3RhdGljIGludCBtdGtfbWRwX2NvbXBfYmluZChz dHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVjdCBkZXZpY2UgKm1hc3RlciwNCj4gPj4+PiArCQkJdm9p ZCAqZGF0YSkNCj4gPj4+PiAgew0KPiA+Pj4+ICAJc3RydWN0IG10a19tZHBfY29tcCAqY29tcCA9 IGRldl9nZXRfZHJ2ZGF0YShkZXYpOw0KPiA+Pj4+ICAJc3RydWN0IG10a19tZHBfZGV2ICptZHAg PSBkYXRhOw0KPiA+Pj4+IC0Jc3RydWN0IGRldmljZV9ub2RlICp2cHVfbm9kZTsNCj4gPj4+PiAg DQo+ID4+Pj4gIAltdGtfbWRwX3JlZ2lzdGVyX2NvbXBvbmVudChtZHAsIGNvbXApOw0KPiA+Pj4+ ICANCj4gPj4+PiAtCS8qDQo+ID4+Pj4gLQkgKiBJZiB0aGlzIGNvbXBvbmVudCBoYXMgYSAibWVk aWF0ZWstdnB1IiBwcm9wZXJ0eSwgaXQgaXMgcmVzcG9uc2libGUgZm9yDQo+ID4+Pj4gLQkgKiBu b3RpZnlpbmcgdGhlIG1kcCBtYXN0ZXIgZHJpdmVyIGFib3V0IGl0IHNvIGl0IGNhbiBiZSBmdXJ0 aGVyIGluaXRpYWxpemVkDQo+ID4+Pj4gLQkgKiBsYXRlci4NCj4gPj4+PiAtCSAqLw0KPiA+Pj4+ IC0JdnB1X25vZGUgPSBvZl9wYXJzZV9waGFuZGxlKGRldi0+b2Zfbm9kZSwgIm1lZGlhdGVrLHZw dSIsIDApOw0KPiA+Pj4+IC0JaWYgKHZwdV9ub2RlKSB7DQo+ID4+Pj4gKwlpZiAoaXNfbWRwX21h c3RlcihkZXYpKSB7DQo+ID4+Pj4gIAkJaW50IHJldDsNCj4gPj4+PiAgDQo+ID4+Pj4gLQkJbWRw LT52cHVfZGV2ID0gb2ZfZmluZF9kZXZpY2VfYnlfbm9kZSh2cHVfbm9kZSk7DQo+ID4+Pj4gLQkJ aWYgKFdBUk5fT04oIW1kcC0+dnB1X2RldikpIHsNCj4gPj4+PiAtCQkJZGV2X2VycihkZXYsICJ2 cHUgcGRldiBmYWlsZWRcbiIpOw0KPiA+Pj4+IC0JCQlvZl9ub2RlX3B1dCh2cHVfbm9kZSk7DQo+ ID4+Pj4gLQkJfQ0KPiA+Pj4+IC0NCj4gPj4+PiAgCQlyZXQgPSB2NGwyX2RldmljZV9yZWdpc3Rl cihkZXYsICZtZHAtPnY0bDJfZGV2KTsNCj4gPj4+PiAgCQlpZiAocmV0KSB7DQo+ID4+Pj4gIAkJ CWRldl9lcnIoZGV2LCAiRmFpbGVkIHRvIHJlZ2lzdGVyIHY0bDIgZGV2aWNlXG4iKTsNCj4gPj4+ PiBAQCAtMTg3LDkgKzIwOCw4IEBAIHN0YXRpYyBpbnQgbXRrX21kcF9jb21wX2JpbmQoc3RydWN0 IGRldmljZSAqZGV2LCBzdHJ1Y3QgZGV2aWNlICptYXN0ZXIsIHZvaWQgKmRhDQo+ID4+Pj4gIAkJ fQ0KPiA+Pj4+ICANCj4gPj4+PiAgCQkvKg0KPiA+Pj4+IC0JCSAqIHByZXNlbmNlIG9mIHRoZSAi bWVkaWF0ZWssdnB1IiBwcm9wZXJ0eSBpbiBhIGRldmljZSBub2RlDQo+ID4+Pj4gLQkJICogaW5k aWNhdGVzIHRoYXQgaXQgaXMgdGhlIHByaW1hcnkgTURQIHJkbWEgZGV2aWNlIGFuZCBNRFAgRE1B DQo+ID4+Pj4gLQkJICogb3BzIHNob3VsZCBiZSBoYW5kbGVkIGJ5IGl0cyBETUEgY2FsbGJhY2tz Lg0KPiA+Pj4+ICsJCSAqIE1EUCBETUEgb3BzIHdpbGwgYmUgaGFuZGxlZCBieSB0aGUgRE1BIGNh bGxiYWNrcyBhc3NvY2lhdGVkIHdpdGggdGhpcw0KPiA+Pj4+ICsJCSAqIGRldmljZTsNCj4gPj4+ PiAgCQkgKi8NCj4gPj4+PiAgCQltZHAtPnJkbWFfZGV2ID0gZGV2Ow0KPiA+Pj4+ICAJfQ0KPiA+ Pj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9j b3JlLmMgYi9kcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb3JlLmMNCj4g Pj4+PiBpbmRleCA1MGVhZmNjOTk5M2QuLjZhNzc1NDYzMzk5YyAxMDA2NDQNCj4gPj4+PiAtLS0g YS9kcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb3JlLmMNCj4gPj4+PiAr KysgYi9kcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb3JlLmMNCj4gPj4+ PiBAQCAtMTUwLDggKzE1MCw5IEBAIHN0YXRpYyB2b2lkIHJlbGVhc2Vfb2Yoc3RydWN0IGRldmlj ZSAqZGV2LCB2b2lkICpkYXRhKQ0KPiA+Pj4+ICANCj4gPj4+PiAgc3RhdGljIGludCBtdGtfbWRw X21hc3Rlcl9iaW5kKHN0cnVjdCBkZXZpY2UgKmRldikNCj4gPj4+PiAgew0KPiA+Pj4+IC0JaW50 IHN0YXR1czsNCj4gPj4+PiAgCXN0cnVjdCBtdGtfbWRwX2RldiAqbWRwID0gZGV2X2dldF9kcnZk YXRhKGRldik7DQo+ID4+Pj4gKwlzdHJ1Y3QgZGV2aWNlX25vZGUgKnZwdV9ub2RlOw0KPiA+Pj4+ ICsJaW50IHN0YXR1czsNCj4gPj4+PiAgDQo+ID4+Pj4gIAlzdGF0dXMgPSBjb21wb25lbnRfYmlu ZF9hbGwoZGV2LCBtZHApOw0KPiA+Pj4+ICAJaWYgKHN0YXR1cykgew0KPiA+Pj4+IEBAIC0xNTks MTUgKzE2MCwzMCBAQCBzdGF0aWMgaW50IG10a19tZHBfbWFzdGVyX2JpbmQoc3RydWN0IGRldmlj ZSAqZGV2KQ0KPiA+Pj4+ICAJCWdvdG8gZXJyX2NvbXBvbmVudF9iaW5kX2FsbDsNCj4gPj4+PiAg CX0NCj4gPj4+PiAgDQo+ID4+Pj4gLQlpZiAobWRwLT52cHVfZGV2KSB7DQo+ID4+Pj4gLQkJaW50 IHJldCA9IHZwdV93ZHRfcmVnX2hhbmRsZXIobWRwLT52cHVfZGV2LCBtdGtfbWRwX3Jlc2V0X2hh bmRsZXIsIG1kcCwNCj4gPj4+PiAtCQkJCQkgIFZQVV9SU1RfTURQKTsNCj4gPj4+PiAtCQlpZiAo cmV0KSB7DQo+ID4+Pj4gLQkJCWRldl9lcnIoZGV2LCAiRmFpbGVkIHRvIHJlZ2lzdGVyIHJlc2V0 IGhhbmRsZXJcbiIpOw0KPiA+Pj4+IC0JCQlnb3RvIGVycl93ZHRfcmVnOw0KPiA+Pj4+IC0JCX0N Cj4gPj4+PiAtCX0gZWxzZSB7DQo+ID4+Pj4gLQkJZGV2X2VycihkZXYsICJubyB2cHVfZGV2IGZv dW5kXG4iKTsNCj4gPj4+PiArCWlmIChtZHAtPnJkbWFfZGV2ID09IE5VTEwpIHsNCj4gPj4+PiAr CQlkZXZfZXJyKGRldiwgIlByaW1hcnkgTURQIGRldmljZSBub3QgZm91bmQiKTsNCj4gPj4+PiAr CQlzdGF0dXMgPSAtRU5PREVWOw0KPiA+Pj4+ICsJCWdvdG8gZXJyX2NvbXBvbmVudF9iaW5kX2Fs bDsNCj4gPj4+PiArCX0NCj4gPj4+PiArDQo+ID4+Pj4gKwl2cHVfbm9kZSA9IG9mX2ZpbmRfbm9k ZV9ieV9uYW1lKE5VTEwsICJ2cHUiKTsNCj4gPj4+PiArCWlmICghdnB1X25vZGUpIHsNCj4gPj4+ PiArCQlkZXZfZXJyKGRldiwgInVuYWJsZSB0byBmaW5kIHZwdSBub2RlIik7DQo+ID4+Pj4gKwkJ c3RhdHVzID0gLUVOT0RFVjsNCj4gPj4+PiArCQlnb3RvIGVycl93ZHRfcmVnOw0KPiA+Pj4+ICsJ fQ0KPiA+Pj4+ICsNCj4gPj4+PiArCW1kcC0+dnB1X2RldiA9IG9mX2ZpbmRfZGV2aWNlX2J5X25v ZGUodnB1X25vZGUpOw0KPiA+Pj4NCj4gPj4+IFRoZSAndnB1X25vZGUnIHNob3VsZCBiZSBwdXQg YnkgY2FsbGluZyAnb2Zfbm9kZV9wdXQodnB1X25vZGUpJyB3aGVuIGl0DQo+ID4+PiBpcyBub3Qg dXNlZC4NCj4gPj4+DQo+ID4+Pj4gKwlpZiAoIW1kcC0+dnB1X2Rldikgew0KPiA+Pj4+ICsJCWRl dl9lcnIoZGV2LCAidW5hYmxlIHRvIGZpbmQgdnB1IGRldmljZSIpOw0KPiA+Pj4+ICsJCXN0YXR1 cyA9IC1FTk9ERVY7DQo+ID4+Pj4gKwkJZ290byBlcnJfd2R0X3JlZzsNCj4gPj4+PiArCX0NCj4g Pj4+PiArDQo+ID4+Pj4gKwlzdGF0dXMgPSB2cHVfd2R0X3JlZ19oYW5kbGVyKG1kcC0+dnB1X2Rl diwgbXRrX21kcF9yZXNldF9oYW5kbGVyLCBtZHAsIFZQVV9SU1RfTURQKTsNCj4gPj4+PiArCWlm IChzdGF0dXMpIHsNCj4gPj4+PiArCQlkZXZfZXJyKGRldiwgIkZhaWxlZCB0byByZWdpc3RlciBy ZXNldCBoYW5kbGVyXG4iKTsNCj4gPj4+PiArCQlnb3RvIGVycl93ZHRfcmVnOw0KPiA+Pj4+ICAJ fQ0KPiA+Pj4+ICANCj4gPj4+PiAgCXN0YXR1cyA9IG10a19tZHBfcmVnaXN0ZXJfbTJtX2Rldmlj ZShtZHApOw0KPiA+Pj4NCj4gPiANCg0K 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=-15.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,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 6CBD1C432BE for ; Mon, 30 Aug 2021 17:15:12 +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 2DBD860F8F for ; Mon, 30 Aug 2021 17:15:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2DBD860F8F 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=JcKxU+3cC600gS0WNiuaCxnUAwp8fnkQvR0LFxF9JR0=; b=loShUGoq1hNYl/ 8bMIkm7Nhlxn/eEy7r8aobjvLmnnrS5Nh2soTjYFpxR/byZaPkGq1r2oqzHLJh7hUn0fmVBCmspJC T6KbU1MW+XwWPytNLkCoVbov+GUHGq41/75gJV6ow2FI+RSVPJnez0JVoPaMFCbvBMpACiiMr9DsK brwp7kgHx2dLK//7B0qwqqSvrd/sbdV51Jcj44AQXo3MN7jCUZse+J6y3msy9GZ63c2impD2DRw9/ 6uLBZ1hJmnBtbPfYf7Spb76qXL2xkJC3zWjlOhwdbywSN7bmxtDAqGa+kyDJTq+9ZRr9xks9RQ8RF NpYuhmsRG7dFWA4Ouo0g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKks9-000A9H-3J; Mon, 30 Aug 2021 17:15:01 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKks3-000A7O-Pd; Mon, 30 Aug 2021 17:14:59 +0000 X-UUID: ec22a16f181d4b23a08881a0a4d8f76e-20210830 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=o3ZzAkBAEoLuL6O6uHI5aTvY6v4T4q0T9URohE9sqsM=; b=l5e5fkSvlRrdokWtIgdJmGVcaC1XCpr6Y2P7Q/3G2lBFf4qUWcdy2UxobLlIlKnC1TKpxkpvWyF0jylewbUDu/r2fz1CJhaonJFpuS1OPOBFhnmJR1J7TKLHEhV+dzfrpKETikjXU/xKi8CMuYNGnSgInlii9zvD6Q54eZkdBQ4=; X-UUID: ec22a16f181d4b23a08881a0a4d8f76e-20210830 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1168148174; Mon, 30 Aug 2021 10:14:50 -0700 Received: from mtkmbs05n1.mediatek.inc (172.21.101.15) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Aug 2021 10:14:48 -0700 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by mtkmbs05n1.mediatek.inc (172.21.101.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 31 Aug 2021 01:14:46 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 31 Aug 2021 01:14:46 +0800 Message-ID: <1630343686.7403.44.camel@mhfsdcap03> Subject: Re: [PATCH v7 7/7] media: mtk-mdp: use mdp-rdma0 alias to point to MDP master From: houlong wei To: Enric Balletbo i Serra CC: Eizan Miyamoto , "linux-kernel@vger.kernel.org" , "chunkuang.hu@kernel.org" , Yong Wu =?UTF-8?Q?=28=E5=90=B4=E5=8B=87=29?= , "wenst@chromium.org" , CK Hu =?UTF-8?Q?=28=E8=83=A1=E4=BF=8A=E5=85=89=29?= , Yongqiang Niu =?UTF-8?Q?=28=E7=89=9B=E6=B0=B8=E5=BC=BA=29?= , Andrew-CT Chen =?UTF-8?Q?=28=E9=99=B3=E6=99=BA=E8=BF=AA=29?= , Matthias Brugger , Mauro Carvalho Chehab , Minghsiu Tsai =?UTF-8?Q?=28=E8=94=A1=E6=98=8E=E4=BF=AE=29?= , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , Date: Tue, 31 Aug 2021 01:14:46 +0800 In-Reply-To: References: <20210825063323.3607738-1-eizan@chromium.org> <20210825163247.v7.7.I2049e180dca12e0d1b3178bfc7292dcf9e05ac28@changeid> <1629880999.12893.17.camel@mhfsdcap03> <0c9fa482-57dd-d4ef-c65b-01f137c57359@collabora.com> <1629904697.15752.11.camel@mhfsdcap03> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210830_101455_873778_3A828302 X-CRM114-Status: GOOD ( 64.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 Hi Enric, My answers are as follows.Thanks for deep thinking about mtk-mdp. Regards, Houlong On Thu, 2021-08-26 at 00:54 +0800, Enric Balletbo i Serra wrote: > Hi Houlong, > > Thank you for your answer, some more questions below :-) > > On 25/8/21 17:18, houlong wei wrote: > > On Wed, 2021-08-25 at 17:07 +0800, Enric Balletbo i Serra wrote: > >> Hi Houlong, > >> > >> Thank you for following up this patchset. I have some questions to try to > >> understand better the hardware though. > >> > >> On 25/8/21 10:43, houlong wei wrote: > >>> Hi Eizan, > >>> > >>> Thanks for you patch. I have inline comment below. > >>> > >>> Regards, > >>> Houlong > >>> > >>> On Wed, 2021-08-25 at 14:33 +0800, Eizan Miyamoto wrote: > >>>> ... Instead of depending on the presence of a mediatek,vpu property in > >>>> the device node. > >>>> > >>>> That property was originally added to link to the vpu node so that the > >>>> mtk_mdp_core driver could pass the right device to > >>>> vpu_wdt_reg_handler(). However in a previous patch in this series, > >>>> the driver has been modified to search the device tree for that node > >>>> instead. > >>>> > >>>> That property was also used to indicate the primary MDP device, so that > >>>> it can be passed to the V4L2 subsystem as well as register it to be > >>>> used when setting up queues in the open() callback for the filesystem > >>>> device node that is created. In this case, assuming that the primary > >>>> MDP device is the one with a specific alias seems useable because the > >>>> alternative is to add a property to the device tree which doesn't > >>>> actually represent any facet of hardware (i.e., this being the primary > >>>> MDP device is a software decision). In other words, this solution is > >>>> equally as arbitrary, but at least it doesn't add a property to a > >>>> device node where said property is unrelated to the hardware present. > >>>> > >>>> Signed-off-by: Eizan Miyamoto > >>>> Reviewed-by: Enric Balletbo i Serra > >>>> --- > >>>> > >>>> (no changes since v1) > >>>> > >>>> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 56 +++++++++++++------ > >>>> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 36 ++++++++---- > >>>> 2 files changed, 64 insertions(+), 28 deletions(-) > >>>> > >>>> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c > >>>> index 85ef274841a3..9527649de98e 100644 > >>>> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c > >>>> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c > >>>> @@ -151,29 +151,50 @@ void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp) > >>>> mtk_smi_larb_put(comp->larb_dev); > >>>> } > >>>> > >>>> -static int mtk_mdp_comp_bind(struct device *dev, struct device *master, void *data) > >>>> +/* > >>>> + * The MDP master device node is identified by the device tree alias > >>>> + * "mdp-rdma0". > >>>> + */ > >>>> +static bool is_mdp_master(struct device *dev) > >>>> +{ > >>>> + struct device_node *aliases, *mdp_rdma0_node; > >>>> + const char *mdp_rdma0_path; > >>>> + > >>>> + if (!dev->of_node) > >>>> + return false; > >>>> + > >>>> + aliases = of_find_node_by_path("/aliases"); > >>>> + if (!aliases) { > >>>> + dev_err(dev, "no aliases found for mdp-rdma0"); > >>>> + return false; > >>>> + } > >>>> + > >>>> + mdp_rdma0_path = of_get_property(aliases, "mdp-rdma0", NULL); > >>>> + if (!mdp_rdma0_path) { > >>>> + dev_err(dev, "get mdp-rdma0 property of /aliases failed"); > >>>> + return false; > >>>> + } > >>>> + > >>>> + mdp_rdma0_node = of_find_node_by_path(mdp_rdma0_path); > >>>> + if (!mdp_rdma0_node) { > >>>> + dev_err(dev, "path resolution failed for %s", mdp_rdma0_path); > >>>> + return false; > >>>> + } > >>>> + > >>>> + return dev->of_node == mdp_rdma0_node; > >>> > >>> > >>> About how to determine the master mdp driver, we also can > >>> judge the component type. The component type can be gotten by calling > >>> of_device_get_match_data(dev). If the component is MTK_MDP_RDMA, it is > >>> the master driver. No matter it is mdp_rdma0 or mdp_rdma1. > >> > >> > >> I'm confused, you mean that the component type, aka MTK_MDP_RDMA is only set for > >> mtk_mdp_rdma0? isn't mtk_dmp_rdma1 also a MTK_MDP_RDMA type? Because looks weird > >> to me that two rdma have diffent types. > >> > > Hi Enric, > > > > I can understand your doubts. For mtk-mdp dirver, it is really difficult > > to understand the relationship among the components. Because the MDP > > hardware path is configured and connected in the VPU firmware. > > So is fixed by the VPU firmware and can't be changed via, i.e writing some > registers? Can't be platform data then? > > If that's the case, can you draw the mdp hardware path for i.e MT8173? (so I > have a better understanding) > I reviewed the mt8173 VPU firmware code and found it only use 1 MDP path.Perhaps one MDP path could meet the project team's requirement when the VPU firmware was implemented. A MDP path is a data path which consists of several MDP hardware engines, e.g. mdp_rdma1->mdp_rsz1->mdp_wrot1, mdp_rdma2->mdp_rsz2->mdp_wrot2. Ideally,if there are multiple MDP paths, the users(e.g. applications) can use them concurrently. > > > For MT8173, the component type of mtk_mdp_rdma0 and mtk_mdp_rdma1 are > > both MTK_MDP_RDMA. Even though the mtk-mdp driver's component list > > contains both of them, only one corresponding hardware component takes > > effect during the processing of a frame, the VPU decides it. > > > > So IIUC the VPU firmware decides which rdma uses on every frame, right? From hw > point of view, why one of them need to be master? > For mt8173, the VPU firmware only use one rdma because another MDP path is not implemented.If we implement multiple MDP paths in certain project, each rdma can be master. > > Regards, > > Houlong > >> > >>> http://lists.infradead.org/pipermail/linux-mediatek/2021-August/028533.html > >>> > >>> IMO, judging it by component type is more flexible because it does not > >>> limit to 'mdp_rdma0'. > >>> > >> > >> Using an alias like Eizan did is also flexible, you only need to set mdp-rdma0 > >> to point the mdp_rdma1 node. > >> > >> What I am really interested to know is the differences between the platforms to > >> understand if this is really a platform hardware property or a software > >> configurable thing, so would help if you can give use the different use cases > >> for different SoCs. > >> > >> For MT8173 which is the master device? is _always_ rdma0 or can also be rdma1? > >> > >> Or maybe what is not clear here is what exactly means be a master device? > >> > >> What about MT8183 and other SoCs? > >> > >> Thanks, > >> Enric > >> > > Hi Enric, > > > > Before answer your questions, let's unify the concept of the master > > device.If an MDP device-tree node can not only generate a /dev/video > > device node, but also can generate a mtk component device node, then > > this component device is the master device. > > Sorry, what you mean with a mtk component device node? My meaning is that the device-tree node can generate a platform device, it is what the mtk_mdp_comp.c does. > > > From the perspective of the device tree node, the compatible of a MDP > > device tree node contains both "mediatek,mt8173-mdp-rdma" and > > "mediatek,mt8173-mdp", then its corresponding mtk component device is > > the master device. > > So that's what's wrong, and Eizan patches get rid of this. In this case you > can't use device-tree to specify such master device. Device-tree is only about > hardware description, can't be used, in this case, as entry point to instantiate > the mdp driver. Hence Eizan patches change this, and mdp is instantiated by the > mmsys driver. Similar to what we do for the drm driver. > > For the two hw rdma blocks the compatible should be just > "mediatek,mt8173-mdp-rdma" in this case. > > Thanks, > Enric My consideration is how the driver supports it when there are multiple MDP paths. Assume there are 2 MDP paths, as a V4L2 driver, mtk-mdp can generates two device nodes, e.g. /dev/video0 supports one of MDP path, /dev/video1 supports another MDP path. > > Since this concept comes from Eizan's patches, if my understanding is > > different from yours, please let me know, thanks. > > > > If there is only one master device, I fully agree with you. For MT8173, > > both mdp_rdma0 and mdp_rdma1 can be master device at the same time. > > But now only mdp_rdma0 takes this role, perhaps because one MDP hardware > > path could meet the project's the requirement six years ago. > > In some project, we have two or more MDP hardware paths, we can > > configure all the mdp_rdma components as master devices, and there will > > be several /dev/video device nodes. The user can control them > > concurrently. > > > > Regards, > > Houlong > > > >> > >>>> +} > >>>> + > >>>> +static int mtk_mdp_comp_bind(struct device *dev, struct device *master, > >>>> + void *data) > >>>> { > >>>> struct mtk_mdp_comp *comp = dev_get_drvdata(dev); > >>>> struct mtk_mdp_dev *mdp = data; > >>>> - struct device_node *vpu_node; > >>>> > >>>> mtk_mdp_register_component(mdp, comp); > >>>> > >>>> - /* > >>>> - * If this component has a "mediatek-vpu" property, it is responsible for > >>>> - * notifying the mdp master driver about it so it can be further initialized > >>>> - * later. > >>>> - */ > >>>> - vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0); > >>>> - if (vpu_node) { > >>>> + if (is_mdp_master(dev)) { > >>>> int ret; > >>>> > >>>> - mdp->vpu_dev = of_find_device_by_node(vpu_node); > >>>> - if (WARN_ON(!mdp->vpu_dev)) { > >>>> - dev_err(dev, "vpu pdev failed\n"); > >>>> - of_node_put(vpu_node); > >>>> - } > >>>> - > >>>> ret = v4l2_device_register(dev, &mdp->v4l2_dev); > >>>> if (ret) { > >>>> dev_err(dev, "Failed to register v4l2 device\n"); > >>>> @@ -187,9 +208,8 @@ static int mtk_mdp_comp_bind(struct device *dev, struct device *master, void *da > >>>> } > >>>> > >>>> /* > >>>> - * presence of the "mediatek,vpu" property in a device node > >>>> - * indicates that it is the primary MDP rdma device and MDP DMA > >>>> - * ops should be handled by its DMA callbacks. > >>>> + * MDP DMA ops will be handled by the DMA callbacks associated with this > >>>> + * device; > >>>> */ > >>>> mdp->rdma_dev = dev; > >>>> } > >>>> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c > >>>> index 50eafcc9993d..6a775463399c 100644 > >>>> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c > >>>> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c > >>>> @@ -150,8 +150,9 @@ static void release_of(struct device *dev, void *data) > >>>> > >>>> static int mtk_mdp_master_bind(struct device *dev) > >>>> { > >>>> - int status; > >>>> struct mtk_mdp_dev *mdp = dev_get_drvdata(dev); > >>>> + struct device_node *vpu_node; > >>>> + int status; > >>>> > >>>> status = component_bind_all(dev, mdp); > >>>> if (status) { > >>>> @@ -159,15 +160,30 @@ static int mtk_mdp_master_bind(struct device *dev) > >>>> goto err_component_bind_all; > >>>> } > >>>> > >>>> - if (mdp->vpu_dev) { > >>>> - int ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp, > >>>> - VPU_RST_MDP); > >>>> - if (ret) { > >>>> - dev_err(dev, "Failed to register reset handler\n"); > >>>> - goto err_wdt_reg; > >>>> - } > >>>> - } else { > >>>> - dev_err(dev, "no vpu_dev found\n"); > >>>> + if (mdp->rdma_dev == NULL) { > >>>> + dev_err(dev, "Primary MDP device not found"); > >>>> + status = -ENODEV; > >>>> + goto err_component_bind_all; > >>>> + } > >>>> + > >>>> + vpu_node = of_find_node_by_name(NULL, "vpu"); > >>>> + if (!vpu_node) { > >>>> + dev_err(dev, "unable to find vpu node"); > >>>> + status = -ENODEV; > >>>> + goto err_wdt_reg; > >>>> + } > >>>> + > >>>> + mdp->vpu_dev = of_find_device_by_node(vpu_node); > >>> > >>> The 'vpu_node' should be put by calling 'of_node_put(vpu_node)' when it > >>> is not used. > >>> > >>>> + if (!mdp->vpu_dev) { > >>>> + dev_err(dev, "unable to find vpu device"); > >>>> + status = -ENODEV; > >>>> + goto err_wdt_reg; > >>>> + } > >>>> + > >>>> + status = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp, VPU_RST_MDP); > >>>> + if (status) { > >>>> + dev_err(dev, "Failed to register reset handler\n"); > >>>> + goto err_wdt_reg; > >>>> } > >>>> > >>>> status = mtk_mdp_register_m2m_device(mdp); > >>> > > _______________________________________________ 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=-15.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,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 0C614C432BE for ; Mon, 30 Aug 2021 17:17:14 +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 AEFBB60F56 for ; Mon, 30 Aug 2021 17:17:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AEFBB60F56 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=v2QjBPZTpJNgbZ0W9Ufs00aMUO8rIMuDBmFnqKtN/08=; b=jCAZXvsv+UGqKG sj2kvd5c34l8TuysZJUtJJaRgafjrXVR15tcTA7jnVBK8Wg4ek7Iw/ectllYXGylMR0PhNur8riOL p2FNDc3BgLBHZUmtnwqMEaj04jF8wfG2vsKtF+PtxkrHrLzB+fyl+RszxfoWsUb2/L+xRDnzmWd2i TF1QT4mD0b7sfAFR4QArcCgsToe9ucXHytJec/3MIZhnkolQRs7Rn2LZD2hJx5tUThurAxyieoAjf VH8n4uD0gn2glRWEe3yaStedaYuCGt3XyQbBQ8rzu58cT8AYPmenrMRqvQy/+vnr+MC4I1GWEhmga XB1RCEMv1lDKa41SLX0A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKksB-000AA1-9z; Mon, 30 Aug 2021 17:15:03 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKks3-000A7O-Pd; Mon, 30 Aug 2021 17:14:59 +0000 X-UUID: ec22a16f181d4b23a08881a0a4d8f76e-20210830 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=o3ZzAkBAEoLuL6O6uHI5aTvY6v4T4q0T9URohE9sqsM=; b=l5e5fkSvlRrdokWtIgdJmGVcaC1XCpr6Y2P7Q/3G2lBFf4qUWcdy2UxobLlIlKnC1TKpxkpvWyF0jylewbUDu/r2fz1CJhaonJFpuS1OPOBFhnmJR1J7TKLHEhV+dzfrpKETikjXU/xKi8CMuYNGnSgInlii9zvD6Q54eZkdBQ4=; X-UUID: ec22a16f181d4b23a08881a0a4d8f76e-20210830 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1168148174; Mon, 30 Aug 2021 10:14:50 -0700 Received: from mtkmbs05n1.mediatek.inc (172.21.101.15) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Aug 2021 10:14:48 -0700 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by mtkmbs05n1.mediatek.inc (172.21.101.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 31 Aug 2021 01:14:46 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 31 Aug 2021 01:14:46 +0800 Message-ID: <1630343686.7403.44.camel@mhfsdcap03> Subject: Re: [PATCH v7 7/7] media: mtk-mdp: use mdp-rdma0 alias to point to MDP master From: houlong wei To: Enric Balletbo i Serra CC: Eizan Miyamoto , "linux-kernel@vger.kernel.org" , "chunkuang.hu@kernel.org" , Yong Wu =?UTF-8?Q?=28=E5=90=B4=E5=8B=87=29?= , "wenst@chromium.org" , CK Hu =?UTF-8?Q?=28=E8=83=A1=E4=BF=8A=E5=85=89=29?= , Yongqiang Niu =?UTF-8?Q?=28=E7=89=9B=E6=B0=B8=E5=BC=BA=29?= , Andrew-CT Chen =?UTF-8?Q?=28=E9=99=B3=E6=99=BA=E8=BF=AA=29?= , Matthias Brugger , Mauro Carvalho Chehab , Minghsiu Tsai =?UTF-8?Q?=28=E8=94=A1=E6=98=8E=E4=BF=AE=29?= , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , Date: Tue, 31 Aug 2021 01:14:46 +0800 In-Reply-To: References: <20210825063323.3607738-1-eizan@chromium.org> <20210825163247.v7.7.I2049e180dca12e0d1b3178bfc7292dcf9e05ac28@changeid> <1629880999.12893.17.camel@mhfsdcap03> <0c9fa482-57dd-d4ef-c65b-01f137c57359@collabora.com> <1629904697.15752.11.camel@mhfsdcap03> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210830_101455_873778_3A828302 X-CRM114-Status: GOOD ( 64.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 Hi Enric, My answers are as follows.Thanks for deep thinking about mtk-mdp. Regards, Houlong On Thu, 2021-08-26 at 00:54 +0800, Enric Balletbo i Serra wrote: > Hi Houlong, > > Thank you for your answer, some more questions below :-) > > On 25/8/21 17:18, houlong wei wrote: > > On Wed, 2021-08-25 at 17:07 +0800, Enric Balletbo i Serra wrote: > >> Hi Houlong, > >> > >> Thank you for following up this patchset. I have some questions to try to > >> understand better the hardware though. > >> > >> On 25/8/21 10:43, houlong wei wrote: > >>> Hi Eizan, > >>> > >>> Thanks for you patch. I have inline comment below. > >>> > >>> Regards, > >>> Houlong > >>> > >>> On Wed, 2021-08-25 at 14:33 +0800, Eizan Miyamoto wrote: > >>>> ... Instead of depending on the presence of a mediatek,vpu property in > >>>> the device node. > >>>> > >>>> That property was originally added to link to the vpu node so that the > >>>> mtk_mdp_core driver could pass the right device to > >>>> vpu_wdt_reg_handler(). However in a previous patch in this series, > >>>> the driver has been modified to search the device tree for that node > >>>> instead. > >>>> > >>>> That property was also used to indicate the primary MDP device, so that > >>>> it can be passed to the V4L2 subsystem as well as register it to be > >>>> used when setting up queues in the open() callback for the filesystem > >>>> device node that is created. In this case, assuming that the primary > >>>> MDP device is the one with a specific alias seems useable because the > >>>> alternative is to add a property to the device tree which doesn't > >>>> actually represent any facet of hardware (i.e., this being the primary > >>>> MDP device is a software decision). In other words, this solution is > >>>> equally as arbitrary, but at least it doesn't add a property to a > >>>> device node where said property is unrelated to the hardware present. > >>>> > >>>> Signed-off-by: Eizan Miyamoto > >>>> Reviewed-by: Enric Balletbo i Serra > >>>> --- > >>>> > >>>> (no changes since v1) > >>>> > >>>> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 56 +++++++++++++------ > >>>> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 36 ++++++++---- > >>>> 2 files changed, 64 insertions(+), 28 deletions(-) > >>>> > >>>> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c > >>>> index 85ef274841a3..9527649de98e 100644 > >>>> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c > >>>> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_comp.c > >>>> @@ -151,29 +151,50 @@ void mtk_mdp_comp_clock_off(struct mtk_mdp_comp *comp) > >>>> mtk_smi_larb_put(comp->larb_dev); > >>>> } > >>>> > >>>> -static int mtk_mdp_comp_bind(struct device *dev, struct device *master, void *data) > >>>> +/* > >>>> + * The MDP master device node is identified by the device tree alias > >>>> + * "mdp-rdma0". > >>>> + */ > >>>> +static bool is_mdp_master(struct device *dev) > >>>> +{ > >>>> + struct device_node *aliases, *mdp_rdma0_node; > >>>> + const char *mdp_rdma0_path; > >>>> + > >>>> + if (!dev->of_node) > >>>> + return false; > >>>> + > >>>> + aliases = of_find_node_by_path("/aliases"); > >>>> + if (!aliases) { > >>>> + dev_err(dev, "no aliases found for mdp-rdma0"); > >>>> + return false; > >>>> + } > >>>> + > >>>> + mdp_rdma0_path = of_get_property(aliases, "mdp-rdma0", NULL); > >>>> + if (!mdp_rdma0_path) { > >>>> + dev_err(dev, "get mdp-rdma0 property of /aliases failed"); > >>>> + return false; > >>>> + } > >>>> + > >>>> + mdp_rdma0_node = of_find_node_by_path(mdp_rdma0_path); > >>>> + if (!mdp_rdma0_node) { > >>>> + dev_err(dev, "path resolution failed for %s", mdp_rdma0_path); > >>>> + return false; > >>>> + } > >>>> + > >>>> + return dev->of_node == mdp_rdma0_node; > >>> > >>> > >>> About how to determine the master mdp driver, we also can > >>> judge the component type. The component type can be gotten by calling > >>> of_device_get_match_data(dev). If the component is MTK_MDP_RDMA, it is > >>> the master driver. No matter it is mdp_rdma0 or mdp_rdma1. > >> > >> > >> I'm confused, you mean that the component type, aka MTK_MDP_RDMA is only set for > >> mtk_mdp_rdma0? isn't mtk_dmp_rdma1 also a MTK_MDP_RDMA type? Because looks weird > >> to me that two rdma have diffent types. > >> > > Hi Enric, > > > > I can understand your doubts. For mtk-mdp dirver, it is really difficult > > to understand the relationship among the components. Because the MDP > > hardware path is configured and connected in the VPU firmware. > > So is fixed by the VPU firmware and can't be changed via, i.e writing some > registers? Can't be platform data then? > > If that's the case, can you draw the mdp hardware path for i.e MT8173? (so I > have a better understanding) > I reviewed the mt8173 VPU firmware code and found it only use 1 MDP path.Perhaps one MDP path could meet the project team's requirement when the VPU firmware was implemented. A MDP path is a data path which consists of several MDP hardware engines, e.g. mdp_rdma1->mdp_rsz1->mdp_wrot1, mdp_rdma2->mdp_rsz2->mdp_wrot2. Ideally,if there are multiple MDP paths, the users(e.g. applications) can use them concurrently. > > > For MT8173, the component type of mtk_mdp_rdma0 and mtk_mdp_rdma1 are > > both MTK_MDP_RDMA. Even though the mtk-mdp driver's component list > > contains both of them, only one corresponding hardware component takes > > effect during the processing of a frame, the VPU decides it. > > > > So IIUC the VPU firmware decides which rdma uses on every frame, right? From hw > point of view, why one of them need to be master? > For mt8173, the VPU firmware only use one rdma because another MDP path is not implemented.If we implement multiple MDP paths in certain project, each rdma can be master. > > Regards, > > Houlong > >> > >>> http://lists.infradead.org/pipermail/linux-mediatek/2021-August/028533.html > >>> > >>> IMO, judging it by component type is more flexible because it does not > >>> limit to 'mdp_rdma0'. > >>> > >> > >> Using an alias like Eizan did is also flexible, you only need to set mdp-rdma0 > >> to point the mdp_rdma1 node. > >> > >> What I am really interested to know is the differences between the platforms to > >> understand if this is really a platform hardware property or a software > >> configurable thing, so would help if you can give use the different use cases > >> for different SoCs. > >> > >> For MT8173 which is the master device? is _always_ rdma0 or can also be rdma1? > >> > >> Or maybe what is not clear here is what exactly means be a master device? > >> > >> What about MT8183 and other SoCs? > >> > >> Thanks, > >> Enric > >> > > Hi Enric, > > > > Before answer your questions, let's unify the concept of the master > > device.If an MDP device-tree node can not only generate a /dev/video > > device node, but also can generate a mtk component device node, then > > this component device is the master device. > > Sorry, what you mean with a mtk component device node? My meaning is that the device-tree node can generate a platform device, it is what the mtk_mdp_comp.c does. > > > From the perspective of the device tree node, the compatible of a MDP > > device tree node contains both "mediatek,mt8173-mdp-rdma" and > > "mediatek,mt8173-mdp", then its corresponding mtk component device is > > the master device. > > So that's what's wrong, and Eizan patches get rid of this. In this case you > can't use device-tree to specify such master device. Device-tree is only about > hardware description, can't be used, in this case, as entry point to instantiate > the mdp driver. Hence Eizan patches change this, and mdp is instantiated by the > mmsys driver. Similar to what we do for the drm driver. > > For the two hw rdma blocks the compatible should be just > "mediatek,mt8173-mdp-rdma" in this case. > > Thanks, > Enric My consideration is how the driver supports it when there are multiple MDP paths. Assume there are 2 MDP paths, as a V4L2 driver, mtk-mdp can generates two device nodes, e.g. /dev/video0 supports one of MDP path, /dev/video1 supports another MDP path. > > Since this concept comes from Eizan's patches, if my understanding is > > different from yours, please let me know, thanks. > > > > If there is only one master device, I fully agree with you. For MT8173, > > both mdp_rdma0 and mdp_rdma1 can be master device at the same time. > > But now only mdp_rdma0 takes this role, perhaps because one MDP hardware > > path could meet the project's the requirement six years ago. > > In some project, we have two or more MDP hardware paths, we can > > configure all the mdp_rdma components as master devices, and there will > > be several /dev/video device nodes. The user can control them > > concurrently. > > > > Regards, > > Houlong > > > >> > >>>> +} > >>>> + > >>>> +static int mtk_mdp_comp_bind(struct device *dev, struct device *master, > >>>> + void *data) > >>>> { > >>>> struct mtk_mdp_comp *comp = dev_get_drvdata(dev); > >>>> struct mtk_mdp_dev *mdp = data; > >>>> - struct device_node *vpu_node; > >>>> > >>>> mtk_mdp_register_component(mdp, comp); > >>>> > >>>> - /* > >>>> - * If this component has a "mediatek-vpu" property, it is responsible for > >>>> - * notifying the mdp master driver about it so it can be further initialized > >>>> - * later. > >>>> - */ > >>>> - vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0); > >>>> - if (vpu_node) { > >>>> + if (is_mdp_master(dev)) { > >>>> int ret; > >>>> > >>>> - mdp->vpu_dev = of_find_device_by_node(vpu_node); > >>>> - if (WARN_ON(!mdp->vpu_dev)) { > >>>> - dev_err(dev, "vpu pdev failed\n"); > >>>> - of_node_put(vpu_node); > >>>> - } > >>>> - > >>>> ret = v4l2_device_register(dev, &mdp->v4l2_dev); > >>>> if (ret) { > >>>> dev_err(dev, "Failed to register v4l2 device\n"); > >>>> @@ -187,9 +208,8 @@ static int mtk_mdp_comp_bind(struct device *dev, struct device *master, void *da > >>>> } > >>>> > >>>> /* > >>>> - * presence of the "mediatek,vpu" property in a device node > >>>> - * indicates that it is the primary MDP rdma device and MDP DMA > >>>> - * ops should be handled by its DMA callbacks. > >>>> + * MDP DMA ops will be handled by the DMA callbacks associated with this > >>>> + * device; > >>>> */ > >>>> mdp->rdma_dev = dev; > >>>> } > >>>> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c > >>>> index 50eafcc9993d..6a775463399c 100644 > >>>> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c > >>>> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c > >>>> @@ -150,8 +150,9 @@ static void release_of(struct device *dev, void *data) > >>>> > >>>> static int mtk_mdp_master_bind(struct device *dev) > >>>> { > >>>> - int status; > >>>> struct mtk_mdp_dev *mdp = dev_get_drvdata(dev); > >>>> + struct device_node *vpu_node; > >>>> + int status; > >>>> > >>>> status = component_bind_all(dev, mdp); > >>>> if (status) { > >>>> @@ -159,15 +160,30 @@ static int mtk_mdp_master_bind(struct device *dev) > >>>> goto err_component_bind_all; > >>>> } > >>>> > >>>> - if (mdp->vpu_dev) { > >>>> - int ret = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp, > >>>> - VPU_RST_MDP); > >>>> - if (ret) { > >>>> - dev_err(dev, "Failed to register reset handler\n"); > >>>> - goto err_wdt_reg; > >>>> - } > >>>> - } else { > >>>> - dev_err(dev, "no vpu_dev found\n"); > >>>> + if (mdp->rdma_dev == NULL) { > >>>> + dev_err(dev, "Primary MDP device not found"); > >>>> + status = -ENODEV; > >>>> + goto err_component_bind_all; > >>>> + } > >>>> + > >>>> + vpu_node = of_find_node_by_name(NULL, "vpu"); > >>>> + if (!vpu_node) { > >>>> + dev_err(dev, "unable to find vpu node"); > >>>> + status = -ENODEV; > >>>> + goto err_wdt_reg; > >>>> + } > >>>> + > >>>> + mdp->vpu_dev = of_find_device_by_node(vpu_node); > >>> > >>> The 'vpu_node' should be put by calling 'of_node_put(vpu_node)' when it > >>> is not used. > >>> > >>>> + if (!mdp->vpu_dev) { > >>>> + dev_err(dev, "unable to find vpu device"); > >>>> + status = -ENODEV; > >>>> + goto err_wdt_reg; > >>>> + } > >>>> + > >>>> + status = vpu_wdt_reg_handler(mdp->vpu_dev, mtk_mdp_reset_handler, mdp, VPU_RST_MDP); > >>>> + if (status) { > >>>> + dev_err(dev, "Failed to register reset handler\n"); > >>>> + goto err_wdt_reg; > >>>> } > >>>> > >>>> status = mtk_mdp_register_m2m_device(mdp); > >>> > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel