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=-22.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,MENTIONS_GIT_HOSTING,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 16B62C43216 for ; Mon, 16 Aug 2021 04:53:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EFD06619A6 for ; Mon, 16 Aug 2021 04:53:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233064AbhHPExg (ORCPT ); Mon, 16 Aug 2021 00:53:36 -0400 Received: from Mailgw01.mediatek.com ([1.203.163.78]:20338 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S229523AbhHPEx2 (ORCPT ); Mon, 16 Aug 2021 00:53:28 -0400 X-UUID: 761e5aff771e4c4f9bb27e141a8ed292-20210816 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=aPfveejJG/uf1hsSa7IBENHohu6hzoRJjQmF5egFfyE=; b=GE3ULi/IqwcyAEwUjNBMIDxVLeYApW0Efaoo9logHXZIrllDmdYM7Hq4ljAIsPFSYRB0XPO6bIK5S6SnkFzvDBR3ipwFiqT4pCHcAE+bI2YsIXwRVZ+J8tUDLm6WKf8V5GB9LZhFCczdLvhQQtk2YmUxjR9fBxVZbIFQqngFD4I=; X-UUID: 761e5aff771e4c4f9bb27e141a8ed292-20210816 Received: from mtkcas32.mediatek.inc [(172.27.4.253)] by mailgw01.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1461357266; Mon, 16 Aug 2021 12:52:51 +0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS33N1.mediatek.inc (172.27.4.75) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Aug 2021 12:52:46 +0800 Received: from mhfsdcap04 (10.17.3.154) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 16 Aug 2021 12:52:45 +0800 Message-ID: <9f23beea197495d017a548ef483584714a3673f9.camel@mediatek.com> Subject: Re: [PATCH v6 7/9] media: mtk-mdp: use mdp-rdma0 alias to point to MDP master From: houlong wei To: Eizan Miyamoto , "linux-kernel@vger.kernel.org" CC: "wenst@chromium.org" , "Yong Wu =?UTF-8?Q?=28=E5=90=B4=E5=8B=87=29?=" , "enric.balletbo@collabora.com" , "devicetree@vger.kernel.org" , "chunkuang.hu@kernel.org" , "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: Mon, 16 Aug 2021 12:52:46 +0800 In-Reply-To: References: <20210802121215.703023-1-eizan@chromium.org> <20210802220943.v6.7.I2049e180dca12e0d1b3178bfc7292dcf9e05ac28@changeid> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-TM-SNTS-SMTP: 35E70F7DC1EA9E7AEE3404716D5151E4F049E8C73B3DAC8435CA59D5C6B44D412000:8 X-MTK: N Content-Transfer-Encoding: base64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org T24gTW9uLCAyMDIxLTA4LTE2IGF0IDExOjAwICswODAwLCBob3Vsb25nIHdlaSB3cm90ZToNCj4g T24gTW9uLCAyMDIxLTA4LTAyIGF0IDIwOjEyICswODAwLCBFaXphbiBNaXlhbW90byB3cm90ZToN Cj4gPiAuLi4gSW5zdGVhZCBvZiBkZXBlbmRpbmcgb24gdGhlIHByZXNlbmNlIG9mIGEgbWVkaWF0 ZWssdnB1IHByb3BlcnR5DQo+ID4gaW4NCj4gPiB0aGUgZGV2aWNlIG5vZGUuDQo+ID4gDQo+ID4g VGhhdCBwcm9wZXJ0eSB3YXMgb3JpZ2luYWxseSBhZGRlZCB0byBsaW5rIHRvIHRoZSB2cHUgbm9k ZSBzbyB0aGF0DQo+ID4gdGhlDQo+ID4gbXRrX21kcF9jb3JlIGRyaXZlciBjb3VsZCBwYXNzIHRo ZSByaWdodCBkZXZpY2UgdG8NCj4gPiB2cHVfd2R0X3JlZ19oYW5kbGVyKCkuIEhvd2V2ZXIgaW4g YSBwcmV2aW91cyBwYXRjaCBpbiB0aGlzIHNlcmllcywNCj4gPiB0aGUgZHJpdmVyIGhhcyBiZWVu IG1vZGlmaWVkIHRvIHNlYXJjaCB0aGUgZGV2aWNlIHRyZWUgZm9yIHRoYXQNCj4gPiBub2RlDQo+ ID4gaW5zdGVhZC4NCj4gPiANCj4gPiBUaGF0IHByb3BlcnR5IHdhcyBhbHNvIHVzZWQgdG8gaW5k aWNhdGUgdGhlIHByaW1hcnkgTURQIGRldmljZSwgc28NCj4gPiB0aGF0DQo+ID4gaXQgY2FuIGJl IHBhc3NlZCB0byB0aGUgVjRMMiBzdWJzeXN0ZW0gYXMgd2VsbCBhcyByZWdpc3RlciBpdCB0byBi ZQ0KPiA+IHVzZWQgd2hlbiBzZXR0aW5nIHVwIHF1ZXVlcyBpbiB0aGUgb3BlbigpIGNhbGxiYWNr IGZvciB0aGUNCj4gPiBmaWxlc3lzdGVtDQo+ID4gZGV2aWNlIG5vZGUgdGhhdCBpcyBjcmVhdGVk LiBJbiB0aGlzIGNhc2UsIGFzc3VtaW5nIHRoYXQgdGhlDQo+ID4gcHJpbWFyeQ0KPiA+IE1EUCBk ZXZpY2UgaXMgdGhlIG9uZSB3aXRoIGEgc3BlY2lmaWMgYWxpYXMgc2VlbXMgdXNlYWJsZSBiZWNh dXNlDQo+ID4gdGhlDQo+ID4gYWx0ZXJuYXRpdmUgaXMgdG8gYWRkIGEgcHJvcGVydHkgdG8gdGhl IGRldmljZSB0cmVlIHdoaWNoIGRvZXNuJ3QNCj4gPiBhY3R1YWxseSByZXByZXNlbnQgYW55IGZh Y2V0IG9mIGhhcmR3YXJlIChpLmUuLCB0aGlzIGJlaW5nIHRoZQ0KPiA+IHByaW1hcnkNCj4gPiBN RFAgZGV2aWNlIGlzIGEgc29mdHdhcmUgZGVjaXNpb24pLiBJbiBvdGhlciB3b3JkcywgdGhpcyBz b2x1dGlvbg0KPiA+IGlzDQo+ID4gZXF1YWxseSBhcyBhcmJpdHJhcnksIGJ1dCBhdCBsZWFzdCBp dCBkb2Vzbid0IGFkZCBhIHByb3BlcnR5IHRvIGENCj4gPiBkZXZpY2Ugbm9kZSB3aGVyZSBzYWlk IHByb3BlcnR5IGlzIHVucmVsYXRlZCB0byB0aGUgaGFyZHdhcmUNCj4gPiBwcmVzZW50Lg0KPiA+ IA0KPiA+IFNpZ25lZC1vZmYtYnk6IEVpemFuIE1peWFtb3RvIDxlaXphbkBjaHJvbWl1bS5vcmc+ DQo+ID4gLS0tDQo+ID4gDQo+ID4gKG5vIGNoYW5nZXMgc2luY2UgdjEpDQo+ID4gDQo+ID4gIGRy aXZlcnMvbWVkaWEvcGxhdGZvcm0vbXRrLW1kcC9tdGtfbWRwX2NvbXAuYyB8IDU2ICsrKysrKysr KysrKystLQ0KPiA+IC0tLS0NCj4gPiAgZHJpdmVycy9tZWRpYS9wbGF0Zm9ybS9tdGstbWRwL210 a19tZHBfY29yZS5jIHwgMzYgKysrKysrKystLS0tDQo+ID4gIDIgZmlsZXMgY2hhbmdlZCwgNjQg aW5zZXJ0aW9ucygrKSwgMjggZGVsZXRpb25zKC0pDQo+ID4gDQo+ID4gZGlmZiAtLWdpdCBhL2Ry aXZlcnMvbWVkaWEvcGxhdGZvcm0vbXRrLW1kcC9tdGtfbWRwX2NvbXAuYw0KPiA+IGIvZHJpdmVy cy9tZWRpYS9wbGF0Zm9ybS9tdGstbWRwL210a19tZHBfY29tcC5jDQo+ID4gaW5kZXggODVlZjI3 NDg0MWEzLi45NTI3NjQ5ZGU5OGUgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9tZWRpYS9wbGF0 Zm9ybS9tdGstbWRwL210a19tZHBfY29tcC5jDQo+ID4gKysrIGIvZHJpdmVycy9tZWRpYS9wbGF0 Zm9ybS9tdGstbWRwL210a19tZHBfY29tcC5jDQo+ID4gQEAgLTE1MSwyOSArMTUxLDUwIEBAIHZv aWQgbXRrX21kcF9jb21wX2Nsb2NrX29mZihzdHJ1Y3QNCj4gPiBtdGtfbWRwX2NvbXANCj4gPiAq Y29tcCkNCj4gPiAgCQltdGtfc21pX2xhcmJfcHV0KGNvbXAtPmxhcmJfZGV2KTsNCj4gPiAgfQ0K PiA+ICANCj4gPiAtc3RhdGljIGludCBtdGtfbWRwX2NvbXBfYmluZChzdHJ1Y3QgZGV2aWNlICpk ZXYsIHN0cnVjdCBkZXZpY2UNCj4gPiAqbWFzdGVyLCB2b2lkICpkYXRhKQ0KPiA+ICsvKg0KPiA+ ICsgKiBUaGUgTURQIG1hc3RlciBkZXZpY2Ugbm9kZSBpcyBpZGVudGlmaWVkIGJ5IHRoZSBkZXZp Y2UgdHJlZQ0KPiA+IGFsaWFzDQo+ID4gKyAqICJtZHAtcmRtYTAiLg0KPiA+ICsgKi8NCj4gPiAr c3RhdGljIGJvb2wgaXNfbWRwX21hc3RlcihzdHJ1Y3QgZGV2aWNlICpkZXYpDQo+ID4gK3sNCj4g PiArCXN0cnVjdCBkZXZpY2Vfbm9kZSAqYWxpYXNlcywgKm1kcF9yZG1hMF9ub2RlOw0KPiA+ICsJ Y29uc3QgY2hhciAqbWRwX3JkbWEwX3BhdGg7DQo+ID4gKw0KPiA+ICsJaWYgKCFkZXYtPm9mX25v ZGUpDQo+ID4gKwkJcmV0dXJuIGZhbHNlOw0KPiA+ICsNCj4gPiArCWFsaWFzZXMgPSBvZl9maW5k X25vZGVfYnlfcGF0aCgiL2FsaWFzZXMiKTsNCj4gPiArCWlmICghYWxpYXNlcykgew0KPiA+ICsJ CWRldl9lcnIoZGV2LCAibm8gYWxpYXNlcyBmb3VuZCBmb3IgbWRwLXJkbWEwIik7DQo+ID4gKwkJ cmV0dXJuIGZhbHNlOw0KPiA+ICsJfQ0KPiA+ICsNCj4gPiArCW1kcF9yZG1hMF9wYXRoID0gb2Zf Z2V0X3Byb3BlcnR5KGFsaWFzZXMsICJtZHAtcmRtYTAiLCBOVUxMKTsNCj4gPiArCWlmICghbWRw X3JkbWEwX3BhdGgpIHsNCj4gPiArCQlkZXZfZXJyKGRldiwgImdldCBtZHAtcmRtYTAgcHJvcGVy dHkgb2YgL2FsaWFzZXMNCj4gPiBmYWlsZWQiKTsNCj4gPiArCQlyZXR1cm4gZmFsc2U7DQo+ID4g Kwl9DQo+ID4gKw0KPiA+ICsJbWRwX3JkbWEwX25vZGUgPSBvZl9maW5kX25vZGVfYnlfcGF0aCht ZHBfcmRtYTBfcGF0aCk7DQo+ID4gKwlpZiAoIW1kcF9yZG1hMF9ub2RlKSB7DQo+ID4gKwkJZGV2 X2VycihkZXYsICJwYXRoIHJlc29sdXRpb24gZmFpbGVkIGZvciAlcyIsDQo+ID4gbWRwX3JkbWEw X3BhdGgpOw0KPiA+ICsJCXJldHVybiBmYWxzZTsNCj4gPiArCX0NCj4gPiArDQo+IA0KPiBIaSBF aXphbiwNCj4gDQo+ICJtZHAtcmRtYTAiIG1heSBiZSBub3QgdGhlIG9ubHkgb25lIG1hc3RlciBk ZXZpY2Ugbm9kZS4gSW4gZmFjdCwNCj4gdGhlcmUNCj4gYXJlIDIgIm1kcC1yZG1hIiBpbiBtdDgx NzMuIFlvdSBjYW4gc2VlICJtZHBfcmRtYTEiIHZpYSBiZWxvdyBsaW5rLg0KPiANCj4gDQpodHRw czovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC9zdGFibGUvbGludXgu Z2l0L3RyZWUvYXJjaC9hcm02NC9ib290L2R0cy9tZWRpYXRlay9tdDgxNzMuZHRzaT9oPXY1LjEz LjExI24xMDE2DQo+IElmIHdlIGFkZCAibWVkaWF0ZWssbXQ4MTczLW1kcCIgdG8gIm1kcF9yZG1h MSIgbGlrZSBiZWxvdywgd2Ugd2lsbA0KPiBoYXZlDQo+IG9uZSBtb3JlIFY0TDIgdmlkZW8gZGV2 aWUgbm9kZS4NCj4gDQo+IAkJbWRwX3JkbWExOiByZG1hQDE0MDAyMDAwIHsNCj4gCQkJY29tcGF0 aWJsZSA9ICJtZWRpYXRlayxtdDgxNzMtbWRwLXJkbWEiLA0KPiAJCQkJICAgICAibWVkaWF0ZWss bXQ4MTczLW1kcCI7DQo+IAkJCS4uLg0KPiAJCX0NCj4gDQo+IFdlIHNob3VsZCBjb25zaWRlciB0 aGUgY2FzZSB0aGF0IHRoZXJlIGFyZSBtb3JlIHRoYW4gb25lICJNRFBfUkRNQSINCj4gY29tcG9u ZW50cy4gDQo+IA0KPiBSZWdhcmRzLA0KPiBIb3Vsb25nDQo+IA0KPiA+ICsJcmV0dXJuIGRldi0+ b2Zfbm9kZSA9PSBtZHBfcmRtYTBfbm9kZTsNCj4gPiArfQ0KPiA+ICsNCj4gPiArc3RhdGljIGlu dCBtdGtfbWRwX2NvbXBfYmluZChzdHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVjdCBkZXZpY2UNCj4g PiAqbWFzdGVyLA0KPiA+ICsJCQl2b2lkICpkYXRhKQ0KPiA+ICB7DQo+ID4gIAlzdHJ1Y3QgbXRr X21kcF9jb21wICpjb21wID0gZGV2X2dldF9kcnZkYXRhKGRldik7DQo+ID4gIAlzdHJ1Y3QgbXRr X21kcF9kZXYgKm1kcCA9IGRhdGE7DQo+ID4gLQlzdHJ1Y3QgZGV2aWNlX25vZGUgKnZwdV9ub2Rl Ow0KPiA+ICANCj4gPiAgCW10a19tZHBfcmVnaXN0ZXJfY29tcG9uZW50KG1kcCwgY29tcCk7DQo+ ID4gIA0KPiA+IC0JLyoNCj4gPiAtCSAqIElmIHRoaXMgY29tcG9uZW50IGhhcyBhICJtZWRpYXRl ay12cHUiIHByb3BlcnR5LCBpdCBpcw0KPiA+IHJlc3BvbnNpYmxlIGZvcg0KPiA+IC0JICogbm90 aWZ5aW5nIHRoZSBtZHAgbWFzdGVyIGRyaXZlciBhYm91dCBpdCBzbyBpdCBjYW4gYmUNCj4gPiBm dXJ0aGVyIGluaXRpYWxpemVkDQo+ID4gLQkgKiBsYXRlci4NCj4gPiAtCSAqLw0KPiA+IC0JdnB1 X25vZGUgPSBvZl9wYXJzZV9waGFuZGxlKGRldi0+b2Zfbm9kZSwgIm1lZGlhdGVrLHZwdSIsIDAp Ow0KPiA+IC0JaWYgKHZwdV9ub2RlKSB7DQo+ID4gKwlpZiAoaXNfbWRwX21hc3RlcihkZXYpKSB7 DQo+ID4gIAkJaW50IHJldDsNCj4gPiAgDQo+ID4gLQkJbWRwLT52cHVfZGV2ID0gb2ZfZmluZF9k ZXZpY2VfYnlfbm9kZSh2cHVfbm9kZSk7DQo+ID4gLQkJaWYgKFdBUk5fT04oIW1kcC0+dnB1X2Rl dikpIHsNCj4gPiAtCQkJZGV2X2VycihkZXYsICJ2cHUgcGRldiBmYWlsZWRcbiIpOw0KPiA+IC0J CQlvZl9ub2RlX3B1dCh2cHVfbm9kZSk7DQo+ID4gLQkJfQ0KPiA+IC0NCj4gPiAgCQlyZXQgPSB2 NGwyX2RldmljZV9yZWdpc3RlcihkZXYsICZtZHAtPnY0bDJfZGV2KTsNCj4gPiAgCQlpZiAocmV0 KSB7DQo+ID4gIAkJCWRldl9lcnIoZGV2LCAiRmFpbGVkIHRvIHJlZ2lzdGVyIHY0bDINCj4gPiBk ZXZpY2VcbiIpOw0KPiA+IEBAIC0xODcsOSArMjA4LDggQEAgc3RhdGljIGludCBtdGtfbWRwX2Nv bXBfYmluZChzdHJ1Y3QgZGV2aWNlDQo+ID4gKmRldiwNCj4gPiBzdHJ1Y3QgZGV2aWNlICptYXN0 ZXIsIHZvaWQgKmRhDQo+ID4gIAkJfQ0KPiA+ICANCj4gPiAgCQkvKg0KPiA+IC0JCSAqIHByZXNl bmNlIG9mIHRoZSAibWVkaWF0ZWssdnB1IiBwcm9wZXJ0eSBpbiBhIGRldmljZQ0KPiA+IG5vZGUN Cj4gPiAtCQkgKiBpbmRpY2F0ZXMgdGhhdCBpdCBpcyB0aGUgcHJpbWFyeSBNRFAgcmRtYSBkZXZp Y2UgYW5kDQo+ID4gTURQIERNQQ0KPiA+IC0JCSAqIG9wcyBzaG91bGQgYmUgaGFuZGxlZCBieSBp dHMgRE1BIGNhbGxiYWNrcy4NCj4gPiArCQkgKiBNRFAgRE1BIG9wcyB3aWxsIGJlIGhhbmRsZWQg YnkgdGhlIERNQSBjYWxsYmFja3MNCj4gPiBhc3NvY2lhdGVkIHdpdGggdGhpcw0KPiA+ICsJCSAq IGRldmljZTsNCj4gPiAgCQkgKi8NCj4gPiAgCQltZHAtPnJkbWFfZGV2ID0gZGV2Ow0KPiA+ICAJ fQ0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21k cF9jb3JlLmMNCj4gPiBiL2RyaXZlcnMvbWVkaWEvcGxhdGZvcm0vbXRrLW1kcC9tdGtfbWRwX2Nv cmUuYw0KPiA+IGluZGV4IDUwZWFmY2M5OTkzZC4uNmE3NzU0NjMzOTljIDEwMDY0NA0KPiA+IC0t LSBhL2RyaXZlcnMvbWVkaWEvcGxhdGZvcm0vbXRrLW1kcC9tdGtfbWRwX2NvcmUuYw0KPiA+ICsr KyBiL2RyaXZlcnMvbWVkaWEvcGxhdGZvcm0vbXRrLW1kcC9tdGtfbWRwX2NvcmUuYw0KPiA+IEBA IC0xNTAsOCArMTUwLDkgQEAgc3RhdGljIHZvaWQgcmVsZWFzZV9vZihzdHJ1Y3QgZGV2aWNlICpk ZXYsIHZvaWQNCj4gPiAqZGF0YSkNCj4gPiAgDQo+ID4gIHN0YXRpYyBpbnQgbXRrX21kcF9tYXN0 ZXJfYmluZChzdHJ1Y3QgZGV2aWNlICpkZXYpDQo+ID4gIHsNCj4gPiAtCWludCBzdGF0dXM7DQo+ ID4gIAlzdHJ1Y3QgbXRrX21kcF9kZXYgKm1kcCA9IGRldl9nZXRfZHJ2ZGF0YShkZXYpOw0KPiA+ ICsJc3RydWN0IGRldmljZV9ub2RlICp2cHVfbm9kZTsNCj4gPiArCWludCBzdGF0dXM7DQo+ID4g IA0KPiA+ICAJc3RhdHVzID0gY29tcG9uZW50X2JpbmRfYWxsKGRldiwgbWRwKTsNCj4gPiAgCWlm IChzdGF0dXMpIHsNCj4gPiBAQCAtMTU5LDE1ICsxNjAsMzAgQEAgc3RhdGljIGludCBtdGtfbWRw X21hc3Rlcl9iaW5kKHN0cnVjdCBkZXZpY2UNCj4gPiAqZGV2KQ0KPiA+ICAJCWdvdG8gZXJyX2Nv bXBvbmVudF9iaW5kX2FsbDsNCj4gPiAgCX0NCj4gPiAgDQo+ID4gLQlpZiAobWRwLT52cHVfZGV2 KSB7DQo+ID4gLQkJaW50IHJldCA9IHZwdV93ZHRfcmVnX2hhbmRsZXIobWRwLT52cHVfZGV2LA0K PiA+IG10a19tZHBfcmVzZXRfaGFuZGxlciwgbWRwLA0KPiA+IC0JCQkJCSAgVlBVX1JTVF9NRFAp Ow0KPiA+IC0JCWlmIChyZXQpIHsNCj4gPiAtCQkJZGV2X2VycihkZXYsICJGYWlsZWQgdG8gcmVn aXN0ZXIgcmVzZXQNCj4gPiBoYW5kbGVyXG4iKTsNCj4gPiAtCQkJZ290byBlcnJfd2R0X3JlZzsN Cj4gPiAtCQl9DQo+ID4gLQl9IGVsc2Ugew0KPiA+IC0JCWRldl9lcnIoZGV2LCAibm8gdnB1X2Rl diBmb3VuZFxuIik7DQo+ID4gKwlpZiAobWRwLT5yZG1hX2RldiA9PSBOVUxMKSB7DQo+ID4gKwkJ ZGV2X2VycihkZXYsICJQcmltYXJ5IE1EUCBkZXZpY2Ugbm90IGZvdW5kIik7DQo+ID4gKwkJc3Rh dHVzID0gLUVOT0RFVjsNCj4gPiArCQlnb3RvIGVycl9jb21wb25lbnRfYmluZF9hbGw7DQo+ID4g Kwl9DQo+ID4gKw0KPiA+ICsJdnB1X25vZGUgPSBvZl9maW5kX25vZGVfYnlfbmFtZShOVUxMLCAi dnB1Iik7DQo+ID4gKwlpZiAoIXZwdV9ub2RlKSB7DQo+ID4gKwkJZGV2X2VycihkZXYsICJ1bmFi bGUgdG8gZmluZCB2cHUgbm9kZSIpOw0KPiA+ICsJCXN0YXR1cyA9IC1FTk9ERVY7DQo+ID4gKwkJ Z290byBlcnJfd2R0X3JlZzsNCj4gPiArCX0NCg0KSGkgRWl6YW4sDQoNCklzIHlvdXIgcmVtb3Zp bmcgIm1lZGlhdGVrLHZwdSIgbmVjZXNzYXJ5IGZvciB0aGlzIHNlcmllcyAiUmVmYWN0b3IgTVRL DQpNRFAgZHJpdmVyIGludG8gY29yZS9jb21wb25lbnRzIiA/DQoNCkluIHNvbWUgTWVkaWFUZWsg cHJvamVjdHMgKG5vdCB1cHN0cmVhbSB5ZXQpLCB0aGUgZGV2aWNlLXRyZWUgbm9kZSBuYW1lDQoi dnB1IiBtYXkgYmUgY2hhbmdlZCB0byBzb21ldGhpbmcgbGlrZSAidnB1MCIsICJ2cHUxIiBvciBv dGhlciBuYW1lLA0Kd2hpY2ggZGVwZW5kcyBvbiB0aGUgaW1wbGVtZW50YXRpb24gb2YgIm10ay12 cHUiIGRyaXZlci4gV2UgY2FuIHNwZWNpZnkNCnRoZSBkaWZmZXJlbnQgcGhhbmRsZSB0byAibWVk aWF0ZWssdnB1IiBpbiAuZHRzaSBmaWxlLiBJZiB3ZSB1c2UNCm9mX2ZpbmRfbm9kZV9ieV9uYW1l KCkgdG8gZ2V0IHRoZSB2cHVfbm9kZSwgd2UgaGF2ZSB0byBtb2RpZnkgdGhlIG5hbWUNCnN0cmlu ZyBpbiBkaWZmZXJlbnQgcHJvamVjdC4NCklmIHRoZSBhbnN3ZXIgb2YgbXkgcHJldmlvdXMgcXVl c3Rpb25zIGlzICJObyIsIEkgcHJlZmVyIHRvIHNsb3cgZG93bg0KdGhlIG1vZGlmaWNhdGlvbiBv ZiByZW1vdmluZyAibWVkaWF0ZWssdnB1Ii4NCg0KU29ycnkgZm9yIGxhdGUgcmVwbHkuDQoNClJl Z2FyZHMsDQpIb3Vsb25nDQoNCj4gPiArDQo+ID4gKwltZHAtPnZwdV9kZXYgPSBvZl9maW5kX2Rl dmljZV9ieV9ub2RlKHZwdV9ub2RlKTsNCj4gPiArCWlmICghbWRwLT52cHVfZGV2KSB7DQo+ID4g KwkJZGV2X2VycihkZXYsICJ1bmFibGUgdG8gZmluZCB2cHUgZGV2aWNlIik7DQo+ID4gKwkJc3Rh dHVzID0gLUVOT0RFVjsNCj4gPiArCQlnb3RvIGVycl93ZHRfcmVnOw0KPiA+ICsJfQ0KPiA+ICsN Cj4gPiArCXN0YXR1cyA9IHZwdV93ZHRfcmVnX2hhbmRsZXIobWRwLT52cHVfZGV2LA0KPiA+IG10 a19tZHBfcmVzZXRfaGFuZGxlciwgbWRwLCBWUFVfUlNUX01EUCk7DQo+ID4gKwlpZiAoc3RhdHVz KSB7DQo+ID4gKwkJZGV2X2VycihkZXYsICJGYWlsZWQgdG8gcmVnaXN0ZXIgcmVzZXQgaGFuZGxl clxuIik7DQo+ID4gKwkJZ290byBlcnJfd2R0X3JlZzsNCj4gPiAgCX0NCj4gPiAgDQo+ID4gIAlz dGF0dXMgPSBtdGtfbWRwX3JlZ2lzdGVyX20ybV9kZXZpY2UobWRwKTsNCj4gPiAtLSANCj4gPiAy LjMyLjAuNTU0LmdlMWIzMjcwNmQ4LWdvb2cNCj4gPiANCj4gDQo+IA0K From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-20.9 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,MENTIONS_GIT_HOSTING,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 79ABAC4338F for ; Mon, 16 Aug 2021 04:53:28 +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 3B48A619E0 for ; Mon, 16 Aug 2021 04:53:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3B48A619E0 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=Br+QOKlwesMQWPUmr1O9kvIRVoBnlylTidEuSj++1nw=; b=lnDVSZ1jNa0bMP ELSsx+WYZnV/d8Mgidts/RP7UX8IAodrMM5z50Ks5wprxLtC3uKbK2v4TzXy+YL7b7qee5u4ffXS8 p67uKAkyZ5hmKE4Jn5X9VO1z9xsB5UOL3l4lztQGdbmHrZ0DSKv8rIyQbOcO1lk4OpKO0hFcL2/lC xiXveYnW4vahdWVIzpvZgbzpn2AV4hvyGzPu/wPqCwx7eTUzGCEOKyLL2jujj5+pfEw5ywxw1J9U+ HCON/mnraFGf8T4x51BdMKVF1Sg97bitWQ4FI3V4pKmgVogCRTbwfCu+5ahHMwJDRHfpBf3+8acau RxHN+j2ZB5oN/Twe380g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mFUcb-00G71V-B8; Mon, 16 Aug 2021 04:53:13 +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 1mFUcM-00G70G-66; Mon, 16 Aug 2021 04:53:02 +0000 X-UUID: fabd852555e343d59fa73e8f8606a827-20210815 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=aPfveejJG/uf1hsSa7IBENHohu6hzoRJjQmF5egFfyE=; b=uutZ4le4yj2eaYFuMwkRqb9VrZ5Lz3DZYxnLGWVVdj6l/p2Ai4/03K0jJ/jJ1W3TW2RDYJP+ySKv680dhLkgJKimRRneJXoNe1OtY5PmOAd6w9kI/PkUJgr/No12shA6j1WsIjXeH4qFeaEgl4gaUShveamd3IB1UqfyrLQ5EgI=; X-UUID: fabd852555e343d59fa73e8f8606a827-20210815 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1657484671; Sun, 15 Aug 2021 21:52:54 -0700 Received: from MTKMBS33N1.mediatek.inc (172.27.4.75) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 15 Aug 2021 21:52:52 -0700 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS33N1.mediatek.inc (172.27.4.75) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Aug 2021 12:52:46 +0800 Received: from mhfsdcap04 (10.17.3.154) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 16 Aug 2021 12:52:45 +0800 Message-ID: <9f23beea197495d017a548ef483584714a3673f9.camel@mediatek.com> Subject: Re: [PATCH v6 7/9] media: mtk-mdp: use mdp-rdma0 alias to point to MDP master From: houlong wei To: Eizan Miyamoto , "linux-kernel@vger.kernel.org" CC: "wenst@chromium.org" , Yong Wu =?UTF-8?Q?=28=E5=90=B4=E5=8B=87=29?= , "enric.balletbo@collabora.com" , "devicetree@vger.kernel.org" , "chunkuang.hu@kernel.org" , 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: Mon, 16 Aug 2021 12:52:46 +0800 In-Reply-To: References: <20210802121215.703023-1-eizan@chromium.org> <20210802220943.v6.7.I2049e180dca12e0d1b3178bfc7292dcf9e05ac28@changeid> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-TM-SNTS-SMTP: 35E70F7DC1EA9E7AEE3404716D5151E4F049E8C73B3DAC8435CA59D5C6B44D412000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210815_215258_287120_B09BF581 X-CRM114-Status: GOOD ( 48.16 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Mon, 2021-08-16 at 11:00 +0800, houlong wei wrote: > On Mon, 2021-08-02 at 20:12 +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 > > --- > > > > (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; > > + } > > + > > Hi Eizan, > > "mdp-rdma0" may be not the only one master device node. In fact, > there > are 2 "mdp-rdma" in mt8173. You can see "mdp_rdma1" via below link. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v5.13.11#n1016 > If we add "mediatek,mt8173-mdp" to "mdp_rdma1" like below, we will > have > one more V4L2 video devie node. > > mdp_rdma1: rdma@14002000 { > compatible = "mediatek,mt8173-mdp-rdma", > "mediatek,mt8173-mdp"; > ... > } > > We should consider the case that there are more than one "MDP_RDMA" > components. > > Regards, > Houlong > > > + return dev->of_node == mdp_rdma0_node; > > +} > > + > > +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; > > + } Hi Eizan, Is your removing "mediatek,vpu" necessary for this series "Refactor MTK MDP driver into core/components" ? In some MediaTek projects (not upstream yet), the device-tree node name "vpu" may be changed to something like "vpu0", "vpu1" or other name, which depends on the implementation of "mtk-vpu" driver. We can specify the different phandle to "mediatek,vpu" in .dtsi file. If we use of_find_node_by_name() to get the vpu_node, we have to modify the name string in different project. If the answer of my previous questions is "No", I prefer to slow down the modification of removing "mediatek,vpu". Sorry for late reply. Regards, Houlong > > + > > + mdp->vpu_dev = of_find_device_by_node(vpu_node); > > + 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); > > -- > > 2.32.0.554.ge1b32706d8-goog > > > > _______________________________________________ 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=-20.9 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,MENTIONS_GIT_HOSTING,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 18C13C4338F for ; Mon, 16 Aug 2021 04:55:28 +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 C5C68619E0 for ; Mon, 16 Aug 2021 04:55:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C5C68619E0 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=+pFsmWYlfiFS+trXjPmdbigiIhMOS4dwT19N9DLMRv4=; b=XDOqSowpZfZQ/z TVcHF/PERPJsXOmHV+y8LjMnmx2YWIqi0ZtRA3tfyytU/AY3wtDb1gloK8G9MGkwlc4YVptqPxWXD nVWZljN4iQAtpvrUjeHTbN1C13liq+7/NKblxv6I6U8lixoc5HgOuYCsrqN77+/Y+4n58C4j+24Mf zJDNHvfCDz9OcMgw92G1k3vHAOFOS3rrwqIfV7MjwrbK3RM0O7HnAeej+sxkkBcH8rwhLcRqkQjuc NAAjvpOHTNQ+FjK5jxFE9EUXpq/EaXTqW1eV+zjFC6+jr5XfadTtzA8bMSQyutJqRjvR5/IsDic/m qmrvEZ4WHqyGJ5GmZEAA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mFUcS-00G712-4r; Mon, 16 Aug 2021 04:53:04 +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 1mFUcM-00G70G-66; Mon, 16 Aug 2021 04:53:02 +0000 X-UUID: fabd852555e343d59fa73e8f8606a827-20210815 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=aPfveejJG/uf1hsSa7IBENHohu6hzoRJjQmF5egFfyE=; b=uutZ4le4yj2eaYFuMwkRqb9VrZ5Lz3DZYxnLGWVVdj6l/p2Ai4/03K0jJ/jJ1W3TW2RDYJP+ySKv680dhLkgJKimRRneJXoNe1OtY5PmOAd6w9kI/PkUJgr/No12shA6j1WsIjXeH4qFeaEgl4gaUShveamd3IB1UqfyrLQ5EgI=; X-UUID: fabd852555e343d59fa73e8f8606a827-20210815 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1657484671; Sun, 15 Aug 2021 21:52:54 -0700 Received: from MTKMBS33N1.mediatek.inc (172.27.4.75) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 15 Aug 2021 21:52:52 -0700 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by MTKMBS33N1.mediatek.inc (172.27.4.75) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Aug 2021 12:52:46 +0800 Received: from mhfsdcap04 (10.17.3.154) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 16 Aug 2021 12:52:45 +0800 Message-ID: <9f23beea197495d017a548ef483584714a3673f9.camel@mediatek.com> Subject: Re: [PATCH v6 7/9] media: mtk-mdp: use mdp-rdma0 alias to point to MDP master From: houlong wei To: Eizan Miyamoto , "linux-kernel@vger.kernel.org" CC: "wenst@chromium.org" , Yong Wu =?UTF-8?Q?=28=E5=90=B4=E5=8B=87=29?= , "enric.balletbo@collabora.com" , "devicetree@vger.kernel.org" , "chunkuang.hu@kernel.org" , 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: Mon, 16 Aug 2021 12:52:46 +0800 In-Reply-To: References: <20210802121215.703023-1-eizan@chromium.org> <20210802220943.v6.7.I2049e180dca12e0d1b3178bfc7292dcf9e05ac28@changeid> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-TM-SNTS-SMTP: 35E70F7DC1EA9E7AEE3404716D5151E4F049E8C73B3DAC8435CA59D5C6B44D412000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210815_215258_287120_B09BF581 X-CRM114-Status: GOOD ( 48.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 2021-08-16 at 11:00 +0800, houlong wei wrote: > On Mon, 2021-08-02 at 20:12 +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 > > --- > > > > (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; > > + } > > + > > Hi Eizan, > > "mdp-rdma0" may be not the only one master device node. In fact, > there > are 2 "mdp-rdma" in mt8173. You can see "mdp_rdma1" via below link. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v5.13.11#n1016 > If we add "mediatek,mt8173-mdp" to "mdp_rdma1" like below, we will > have > one more V4L2 video devie node. > > mdp_rdma1: rdma@14002000 { > compatible = "mediatek,mt8173-mdp-rdma", > "mediatek,mt8173-mdp"; > ... > } > > We should consider the case that there are more than one "MDP_RDMA" > components. > > Regards, > Houlong > > > + return dev->of_node == mdp_rdma0_node; > > +} > > + > > +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; > > + } Hi Eizan, Is your removing "mediatek,vpu" necessary for this series "Refactor MTK MDP driver into core/components" ? In some MediaTek projects (not upstream yet), the device-tree node name "vpu" may be changed to something like "vpu0", "vpu1" or other name, which depends on the implementation of "mtk-vpu" driver. We can specify the different phandle to "mediatek,vpu" in .dtsi file. If we use of_find_node_by_name() to get the vpu_node, we have to modify the name string in different project. If the answer of my previous questions is "No", I prefer to slow down the modification of removing "mediatek,vpu". Sorry for late reply. Regards, Houlong > > + > > + mdp->vpu_dev = of_find_device_by_node(vpu_node); > > + 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); > > -- > > 2.32.0.554.ge1b32706d8-goog > > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel