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, 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 C879BC432BE for ; Wed, 25 Aug 2021 15:18:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A424B610FB for ; Wed, 25 Aug 2021 15:18:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241358AbhHYPTK (ORCPT ); Wed, 25 Aug 2021 11:19:10 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:60932 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S237968AbhHYPTG (ORCPT ); Wed, 25 Aug 2021 11:19:06 -0400 X-UUID: 232abbacc72143919fd6bbc527f269dc-20210825 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=AvZ/1szMK7QPpc3wUkxkUpWTIZXC+pUg9drjZUKq8Jc=; b=uwYTQkR21g/Kt750m8J0sJkhwmwj+zsOuM55g7W7u+IScjCwFhKAKuxzYSvO5MqHMvV4tJpTpW4ns8R8y6BFww0I3FSYibfgopC/Yn+wKPh4dkdNj8Oqb1+kWNJ8sE08mx9YcA/+WFxkPUP2G+6JIbHEOo9ET9CMtKf/BGDj9ss=; X-UUID: 232abbacc72143919fd6bbc527f269dc-20210825 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 703267072; Wed, 25 Aug 2021 23:18:20 +0800 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by mtkmbs05n2.mediatek.inc (172.21.101.140) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Aug 2021 23:18:18 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Wed, 25 Aug 2021 23:18:17 +0800 Message-ID: <1629904697.15752.11.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: Wed, 25 Aug 2021 23:18:17 +0800 In-Reply-To: <0c9fa482-57dd-d4ef-c65b-01f137c57359@collabora.com> References: <20210825063323.3607738-1-eizan@chromium.org> <20210825163247.v7.7.I2049e180dca12e0d1b3178bfc7292dcf9e05ac28@changeid> <1629880999.12893.17.camel@mhfsdcap03> <0c9fa482-57dd-d4ef-c65b-01f137c57359@collabora.com> 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 T24gV2VkLCAyMDIxLTA4LTI1IGF0IDE3OjA3ICswODAwLCBFbnJpYyBCYWxsZXRibyBpIFNlcnJh IHdyb3RlOg0KPiBIaSBIb3Vsb25nLA0KPiANCj4gVGhhbmsgeW91IGZvciBmb2xsb3dpbmcgdXAg dGhpcyBwYXRjaHNldC4gSSBoYXZlIHNvbWUgcXVlc3Rpb25zIHRvIHRyeSB0bw0KPiB1bmRlcnN0 YW5kIGJldHRlciB0aGUgaGFyZHdhcmUgdGhvdWdoLg0KPiANCj4gT24gMjUvOC8yMSAxMDo0Mywg aG91bG9uZyB3ZWkgd3JvdGU6DQo+ID4gSGkgRWl6YW4sDQo+ID4gDQo+ID4gVGhhbmtzIGZvciB5 b3UgcGF0Y2guIEkgaGF2ZSBpbmxpbmUgY29tbWVudCBiZWxvdy4NCj4gPiANCj4gPiBSZWdhcmRz LA0KPiA+IEhvdWxvbmcNCj4gPiANCj4gPiBPbiBXZWQsIDIwMjEtMDgtMjUgYXQgMTQ6MzMgKzA4 MDAsIEVpemFuIE1peWFtb3RvIHdyb3RlOg0KPiA+PiAuLi4gSW5zdGVhZCBvZiBkZXBlbmRpbmcg b24gdGhlIHByZXNlbmNlIG9mIGEgbWVkaWF0ZWssdnB1IHByb3BlcnR5IGluDQo+ID4+IHRoZSBk ZXZpY2Ugbm9kZS4NCj4gPj4NCj4gPj4gVGhhdCBwcm9wZXJ0eSB3YXMgb3JpZ2luYWxseSBhZGRl ZCB0byBsaW5rIHRvIHRoZSB2cHUgbm9kZSBzbyB0aGF0IHRoZQ0KPiA+PiBtdGtfbWRwX2NvcmUg ZHJpdmVyIGNvdWxkIHBhc3MgdGhlIHJpZ2h0IGRldmljZSB0bw0KPiA+PiB2cHVfd2R0X3JlZ19o YW5kbGVyKCkuIEhvd2V2ZXIgaW4gYSBwcmV2aW91cyBwYXRjaCBpbiB0aGlzIHNlcmllcywNCj4g Pj4gdGhlIGRyaXZlciBoYXMgYmVlbiBtb2RpZmllZCB0byBzZWFyY2ggdGhlIGRldmljZSB0cmVl IGZvciB0aGF0IG5vZGUNCj4gPj4gaW5zdGVhZC4NCj4gPj4NCj4gPj4gVGhhdCBwcm9wZXJ0eSB3 YXMgYWxzbyB1c2VkIHRvIGluZGljYXRlIHRoZSBwcmltYXJ5IE1EUCBkZXZpY2UsIHNvIHRoYXQN Cj4gPj4gaXQgY2FuIGJlIHBhc3NlZCB0byB0aGUgVjRMMiBzdWJzeXN0ZW0gYXMgd2VsbCBhcyBy ZWdpc3RlciBpdCB0byBiZQ0KPiA+PiB1c2VkIHdoZW4gc2V0dGluZyB1cCBxdWV1ZXMgaW4gdGhl IG9wZW4oKSBjYWxsYmFjayBmb3IgdGhlIGZpbGVzeXN0ZW0NCj4gPj4gZGV2aWNlIG5vZGUgdGhh dCBpcyBjcmVhdGVkLiBJbiB0aGlzIGNhc2UsIGFzc3VtaW5nIHRoYXQgdGhlIHByaW1hcnkNCj4g Pj4gTURQIGRldmljZSBpcyB0aGUgb25lIHdpdGggYSBzcGVjaWZpYyBhbGlhcyBzZWVtcyB1c2Vh YmxlIGJlY2F1c2UgdGhlDQo+ID4+IGFsdGVybmF0aXZlIGlzIHRvIGFkZCBhIHByb3BlcnR5IHRv IHRoZSBkZXZpY2UgdHJlZSB3aGljaCBkb2Vzbid0DQo+ID4+IGFjdHVhbGx5IHJlcHJlc2VudCBh bnkgZmFjZXQgb2YgaGFyZHdhcmUgKGkuZS4sIHRoaXMgYmVpbmcgdGhlIHByaW1hcnkNCj4gPj4g TURQIGRldmljZSBpcyBhIHNvZnR3YXJlIGRlY2lzaW9uKS4gSW4gb3RoZXIgd29yZHMsIHRoaXMg c29sdXRpb24gaXMNCj4gPj4gZXF1YWxseSBhcyBhcmJpdHJhcnksIGJ1dCBhdCBsZWFzdCBpdCBk b2Vzbid0IGFkZCBhIHByb3BlcnR5IHRvIGENCj4gPj4gZGV2aWNlIG5vZGUgd2hlcmUgc2FpZCBw cm9wZXJ0eSBpcyB1bnJlbGF0ZWQgdG8gdGhlIGhhcmR3YXJlIHByZXNlbnQuDQo+ID4+DQo+ID4+ IFNpZ25lZC1vZmYtYnk6IEVpemFuIE1peWFtb3RvIDxlaXphbkBjaHJvbWl1bS5vcmc+DQo+ID4+ IFJldmlld2VkLWJ5OiBFbnJpYyBCYWxsZXRibyBpIFNlcnJhIDxlbnJpYy5iYWxsZXRib0Bjb2xs YWJvcmEuY29tPg0KPiA+PiAtLS0NCj4gPj4NCj4gPj4gKG5vIGNoYW5nZXMgc2luY2UgdjEpDQo+ ID4+DQo+ID4+ICBkcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb21wLmMg fCA1NiArKysrKysrKysrKysrLS0tLS0tDQo+ID4+ICBkcml2ZXJzL21lZGlhL3BsYXRmb3JtL210 ay1tZHAvbXRrX21kcF9jb3JlLmMgfCAzNiArKysrKysrKy0tLS0NCj4gPj4gIDIgZmlsZXMgY2hh bmdlZCwgNjQgaW5zZXJ0aW9ucygrKSwgMjggZGVsZXRpb25zKC0pDQo+ID4+DQo+ID4+IGRpZmYg LS1naXQgYS9kcml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb21wLmMgYi9k cml2ZXJzL21lZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb21wLmMNCj4gPj4gaW5kZXgg ODVlZjI3NDg0MWEzLi45NTI3NjQ5ZGU5OGUgMTAwNjQ0DQo+ID4+IC0tLSBhL2RyaXZlcnMvbWVk aWEvcGxhdGZvcm0vbXRrLW1kcC9tdGtfbWRwX2NvbXAuYw0KPiA+PiArKysgYi9kcml2ZXJzL21l ZGlhL3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb21wLmMNCj4gPj4gQEAgLTE1MSwyOSArMTUx LDUwIEBAIHZvaWQgbXRrX21kcF9jb21wX2Nsb2NrX29mZihzdHJ1Y3QgbXRrX21kcF9jb21wICpj b21wKQ0KPiA+PiAgCQltdGtfc21pX2xhcmJfcHV0KGNvbXAtPmxhcmJfZGV2KTsNCj4gPj4gIH0N Cj4gPj4gIA0KPiA+PiAtc3RhdGljIGludCBtdGtfbWRwX2NvbXBfYmluZChzdHJ1Y3QgZGV2aWNl ICpkZXYsIHN0cnVjdCBkZXZpY2UgKm1hc3Rlciwgdm9pZCAqZGF0YSkNCj4gPj4gKy8qDQo+ID4+ ICsgKiBUaGUgTURQIG1hc3RlciBkZXZpY2Ugbm9kZSBpcyBpZGVudGlmaWVkIGJ5IHRoZSBkZXZp Y2UgdHJlZSBhbGlhcw0KPiA+PiArICogIm1kcC1yZG1hMCIuDQo+ID4+ICsgKi8NCj4gPj4gK3N0 YXRpYyBib29sIGlzX21kcF9tYXN0ZXIoc3RydWN0IGRldmljZSAqZGV2KQ0KPiA+PiArew0KPiA+ PiArCXN0cnVjdCBkZXZpY2Vfbm9kZSAqYWxpYXNlcywgKm1kcF9yZG1hMF9ub2RlOw0KPiA+PiAr CWNvbnN0IGNoYXIgKm1kcF9yZG1hMF9wYXRoOw0KPiA+PiArDQo+ID4+ICsJaWYgKCFkZXYtPm9m X25vZGUpDQo+ID4+ICsJCXJldHVybiBmYWxzZTsNCj4gPj4gKw0KPiA+PiArCWFsaWFzZXMgPSBv Zl9maW5kX25vZGVfYnlfcGF0aCgiL2FsaWFzZXMiKTsNCj4gPj4gKwlpZiAoIWFsaWFzZXMpIHsN Cj4gPj4gKwkJZGV2X2VycihkZXYsICJubyBhbGlhc2VzIGZvdW5kIGZvciBtZHAtcmRtYTAiKTsN Cj4gPj4gKwkJcmV0dXJuIGZhbHNlOw0KPiA+PiArCX0NCj4gPj4gKw0KPiA+PiArCW1kcF9yZG1h MF9wYXRoID0gb2ZfZ2V0X3Byb3BlcnR5KGFsaWFzZXMsICJtZHAtcmRtYTAiLCBOVUxMKTsNCj4g Pj4gKwlpZiAoIW1kcF9yZG1hMF9wYXRoKSB7DQo+ID4+ICsJCWRldl9lcnIoZGV2LCAiZ2V0IG1k cC1yZG1hMCBwcm9wZXJ0eSBvZiAvYWxpYXNlcyBmYWlsZWQiKTsNCj4gPj4gKwkJcmV0dXJuIGZh bHNlOw0KPiA+PiArCX0NCj4gPj4gKw0KPiA+PiArCW1kcF9yZG1hMF9ub2RlID0gb2ZfZmluZF9u b2RlX2J5X3BhdGgobWRwX3JkbWEwX3BhdGgpOw0KPiA+PiArCWlmICghbWRwX3JkbWEwX25vZGUp IHsNCj4gPj4gKwkJZGV2X2VycihkZXYsICJwYXRoIHJlc29sdXRpb24gZmFpbGVkIGZvciAlcyIs IG1kcF9yZG1hMF9wYXRoKTsNCj4gPj4gKwkJcmV0dXJuIGZhbHNlOw0KPiA+PiArCX0NCj4gPj4g Kw0KPiA+PiArCXJldHVybiBkZXYtPm9mX25vZGUgPT0gbWRwX3JkbWEwX25vZGU7DQo+ID4gDQo+ ID4gDQo+ID4gQWJvdXQgaG93IHRvIGRldGVybWluZSB0aGUgbWFzdGVyIG1kcCBkcml2ZXIsIHdl IGFsc28gY2FuDQo+ID4ganVkZ2UgdGhlIGNvbXBvbmVudCB0eXBlLiBUaGUgY29tcG9uZW50IHR5 cGUgY2FuIGJlIGdvdHRlbiBieSBjYWxsaW5nDQo+ID4gb2ZfZGV2aWNlX2dldF9tYXRjaF9kYXRh KGRldikuIElmIHRoZSBjb21wb25lbnQgaXMgTVRLX01EUF9SRE1BLCBpdCBpcw0KPiA+IHRoZSBt YXN0ZXIgZHJpdmVyLiBObyBtYXR0ZXIgaXQgaXMgbWRwX3JkbWEwIG9yIG1kcF9yZG1hMS4NCj4g DQo+IA0KPiBJJ20gY29uZnVzZWQsIHlvdSBtZWFuIHRoYXQgdGhlIGNvbXBvbmVudCB0eXBlLCBh a2EgTVRLX01EUF9SRE1BIGlzIG9ubHkgc2V0IGZvcg0KPiBtdGtfbWRwX3JkbWEwPyBpc24ndCBt dGtfZG1wX3JkbWExIGFsc28gYSBNVEtfTURQX1JETUEgdHlwZT8gQmVjYXVzZSBsb29rcyB3ZWly ZA0KPiB0byBtZSB0aGF0IHR3byByZG1hIGhhdmUgZGlmZmVudCB0eXBlcy4NCj4gDQpIaSBFbnJp YywNCg0KSSBjYW4gdW5kZXJzdGFuZCB5b3VyIGRvdWJ0cy4gRm9yIG10ay1tZHAgZGlydmVyLCBp dCBpcyByZWFsbHkgZGlmZmljdWx0DQp0byB1bmRlcnN0YW5kIHRoZSByZWxhdGlvbnNoaXAgYW1v bmcgdGhlIGNvbXBvbmVudHMuIEJlY2F1c2UgdGhlIE1EUA0KaGFyZHdhcmUgcGF0aCBpcyBjb25m aWd1cmVkIGFuZCBjb25uZWN0ZWQgaW4gdGhlIFZQVSBmaXJtd2FyZS4NCkZvciBNVDgxNzMsIHRo ZSBjb21wb25lbnQgdHlwZSBvZiBtdGtfbWRwX3JkbWEwIGFuZCBtdGtfbWRwX3JkbWExIGFyZQ0K Ym90aCBNVEtfTURQX1JETUEuIEV2ZW4gdGhvdWdoIHRoZSBtdGstbWRwIGRyaXZlcidzIGNvbXBv bmVudCBsaXN0DQpjb250YWlucyBib3RoIG9mIHRoZW0sIG9ubHkgb25lIGNvcnJlc3BvbmRpbmcg aGFyZHdhcmUgY29tcG9uZW50IHRha2VzDQplZmZlY3QgZHVyaW5nIHRoZSBwcm9jZXNzaW5nIG9m IGEgZnJhbWUsIHRoZSBWUFUgZGVjaWRlcyBpdC4NCg0KUmVnYXJkcywNCkhvdWxvbmcNCj4gDQo+ ID4gaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvcGlwZXJtYWlsL2xpbnV4LW1lZGlhdGVrLzIw MjEtQXVndXN0LzAyODUzMy5odG1sDQo+ID4gDQo+ID4gSU1PLCBqdWRnaW5nIGl0IGJ5IGNvbXBv bmVudCB0eXBlIGlzIG1vcmUgZmxleGlibGUgYmVjYXVzZSBpdCBkb2VzIG5vdA0KPiA+IGxpbWl0 IHRvICdtZHBfcmRtYTAnLg0KPiA+IA0KPiANCj4gVXNpbmcgYW4gYWxpYXMgbGlrZSBFaXphbiBk aWQgaXMgYWxzbyBmbGV4aWJsZSwgeW91IG9ubHkgbmVlZCB0byBzZXQgbWRwLXJkbWEwDQo+IHRv IHBvaW50IHRoZSBtZHBfcmRtYTEgbm9kZS4NCj4gDQo+IFdoYXQgSSBhbSByZWFsbHkgaW50ZXJl c3RlZCB0byBrbm93IGlzIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBwbGF0Zm9ybXMgdG8N Cj4gdW5kZXJzdGFuZCBpZiB0aGlzIGlzIHJlYWxseSBhIHBsYXRmb3JtIGhhcmR3YXJlIHByb3Bl cnR5IG9yIGEgc29mdHdhcmUNCj4gY29uZmlndXJhYmxlIHRoaW5nLCBzbyB3b3VsZCBoZWxwIGlm IHlvdSBjYW4gZ2l2ZSB1c2UgdGhlIGRpZmZlcmVudCB1c2UgY2FzZXMNCj4gZm9yIGRpZmZlcmVu dCBTb0NzLg0KPiANCj4gRm9yIE1UODE3MyB3aGljaCBpcyB0aGUgbWFzdGVyIGRldmljZT8gaXMg X2Fsd2F5c18gcmRtYTAgb3IgY2FuIGFsc28gYmUgcmRtYTE/DQo+IA0KPiBPciBtYXliZSB3aGF0 IGlzIG5vdCBjbGVhciBoZXJlIGlzIHdoYXQgZXhhY3RseSBtZWFucyBiZSBhIG1hc3RlciBkZXZp Y2U/DQo+IA0KPiBXaGF0IGFib3V0IE1UODE4MyBhbmQgb3RoZXIgU29Dcz8NCj4gDQo+IFRoYW5r cywNCj4gICBFbnJpYw0KPiANCkhpIEVucmljLA0KDQpCZWZvcmUgYW5zd2VyIHlvdXIgcXVlc3Rp b25zLCBsZXQncyB1bmlmeSB0aGUgY29uY2VwdCBvZiB0aGUgbWFzdGVyDQpkZXZpY2UuSWYgYW4g TURQIGRldmljZS10cmVlIG5vZGUgY2FuIG5vdCBvbmx5IGdlbmVyYXRlIGEgL2Rldi92aWRlbw0K ZGV2aWNlIG5vZGUsIGJ1dCBhbHNvIGNhbiBnZW5lcmF0ZSBhIG10ayBjb21wb25lbnQgZGV2aWNl IG5vZGUsIHRoZW4NCnRoaXMgY29tcG9uZW50IGRldmljZSBpcyB0aGUgbWFzdGVyIGRldmljZS4N CkZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBkZXZpY2UgdHJlZSBub2RlLCB0aGUgY29tcGF0 aWJsZSBvZiBhIE1EUA0KZGV2aWNlIHRyZWUgbm9kZSBjb250YWlucyBib3RoICJtZWRpYXRlayxt dDgxNzMtbWRwLXJkbWEiIGFuZA0KIm1lZGlhdGVrLG10ODE3My1tZHAiLCB0aGVuIGl0cyBjb3Jy ZXNwb25kaW5nIG10ayBjb21wb25lbnQgZGV2aWNlIGlzDQp0aGUgbWFzdGVyIGRldmljZS4NClNp bmNlIHRoaXMgY29uY2VwdCBjb21lcyBmcm9tIEVpemFuJ3MgcGF0Y2hlcywgaWYgbXkgdW5kZXJz dGFuZGluZyBpcw0KZGlmZmVyZW50IGZyb20geW91cnMsIHBsZWFzZSBsZXQgbWUga25vdywgdGhh bmtzLg0KDQpJZiB0aGVyZSBpcyBvbmx5IG9uZSBtYXN0ZXIgZGV2aWNlLCBJIGZ1bGx5IGFncmVl IHdpdGggeW91LiBGb3IgTVQ4MTczLA0KYm90aCBtZHBfcmRtYTAgYW5kIG1kcF9yZG1hMSBjYW4g YmUgbWFzdGVyIGRldmljZSBhdCB0aGUgc2FtZSB0aW1lLg0KQnV0IG5vdyBvbmx5IG1kcF9yZG1h MCB0YWtlcyB0aGlzIHJvbGUsIHBlcmhhcHMgYmVjYXVzZSBvbmUgTURQIGhhcmR3YXJlDQpwYXRo IGNvdWxkIG1lZXQgdGhlIHByb2plY3QncyB0aGUgcmVxdWlyZW1lbnQgc2l4IHllYXJzIGFnby4N CkluIHNvbWUgcHJvamVjdCwgd2UgaGF2ZSB0d28gb3IgbW9yZSBNRFAgaGFyZHdhcmUgcGF0aHMs IHdlIGNhbg0KY29uZmlndXJlIGFsbCB0aGUgbWRwX3JkbWEgY29tcG9uZW50cyBhcyBtYXN0ZXIg ZGV2aWNlcywgYW5kIHRoZXJlIHdpbGwNCmJlIHNldmVyYWwgL2Rldi92aWRlbyBkZXZpY2Ugbm9k ZXMuIFRoZSB1c2VyIGNhbiBjb250cm9sIHRoZW0NCmNvbmN1cnJlbnRseS4NCg0KUmVnYXJkcywN CkhvdWxvbmcNCg0KPiANCj4gPj4gK30NCj4gPj4gKw0KPiA+PiArc3RhdGljIGludCBtdGtfbWRw X2NvbXBfYmluZChzdHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVjdCBkZXZpY2UgKm1hc3RlciwNCj4g Pj4gKwkJCXZvaWQgKmRhdGEpDQo+ID4+ICB7DQo+ID4+ICAJc3RydWN0IG10a19tZHBfY29tcCAq Y29tcCA9IGRldl9nZXRfZHJ2ZGF0YShkZXYpOw0KPiA+PiAgCXN0cnVjdCBtdGtfbWRwX2RldiAq bWRwID0gZGF0YTsNCj4gPj4gLQlzdHJ1Y3QgZGV2aWNlX25vZGUgKnZwdV9ub2RlOw0KPiA+PiAg DQo+ID4+ICAJbXRrX21kcF9yZWdpc3Rlcl9jb21wb25lbnQobWRwLCBjb21wKTsNCj4gPj4gIA0K PiA+PiAtCS8qDQo+ID4+IC0JICogSWYgdGhpcyBjb21wb25lbnQgaGFzIGEgIm1lZGlhdGVrLXZw dSIgcHJvcGVydHksIGl0IGlzIHJlc3BvbnNpYmxlIGZvcg0KPiA+PiAtCSAqIG5vdGlmeWluZyB0 aGUgbWRwIG1hc3RlciBkcml2ZXIgYWJvdXQgaXQgc28gaXQgY2FuIGJlIGZ1cnRoZXIgaW5pdGlh bGl6ZWQNCj4gPj4gLQkgKiBsYXRlci4NCj4gPj4gLQkgKi8NCj4gPj4gLQl2cHVfbm9kZSA9IG9m X3BhcnNlX3BoYW5kbGUoZGV2LT5vZl9ub2RlLCAibWVkaWF0ZWssdnB1IiwgMCk7DQo+ID4+IC0J aWYgKHZwdV9ub2RlKSB7DQo+ID4+ICsJaWYgKGlzX21kcF9tYXN0ZXIoZGV2KSkgew0KPiA+PiAg CQlpbnQgcmV0Ow0KPiA+PiAgDQo+ID4+IC0JCW1kcC0+dnB1X2RldiA9IG9mX2ZpbmRfZGV2aWNl X2J5X25vZGUodnB1X25vZGUpOw0KPiA+PiAtCQlpZiAoV0FSTl9PTighbWRwLT52cHVfZGV2KSkg ew0KPiA+PiAtCQkJZGV2X2VycihkZXYsICJ2cHUgcGRldiBmYWlsZWRcbiIpOw0KPiA+PiAtCQkJ b2Zfbm9kZV9wdXQodnB1X25vZGUpOw0KPiA+PiAtCQl9DQo+ID4+IC0NCj4gPj4gIAkJcmV0ID0g djRsMl9kZXZpY2VfcmVnaXN0ZXIoZGV2LCAmbWRwLT52NGwyX2Rldik7DQo+ID4+ICAJCWlmIChy ZXQpIHsNCj4gPj4gIAkJCWRldl9lcnIoZGV2LCAiRmFpbGVkIHRvIHJlZ2lzdGVyIHY0bDIgZGV2 aWNlXG4iKTsNCj4gPj4gQEAgLTE4Nyw5ICsyMDgsOCBAQCBzdGF0aWMgaW50IG10a19tZHBfY29t cF9iaW5kKHN0cnVjdCBkZXZpY2UgKmRldiwgc3RydWN0IGRldmljZSAqbWFzdGVyLCB2b2lkICpk YQ0KPiA+PiAgCQl9DQo+ID4+ICANCj4gPj4gIAkJLyoNCj4gPj4gLQkJICogcHJlc2VuY2Ugb2Yg dGhlICJtZWRpYXRlayx2cHUiIHByb3BlcnR5IGluIGEgZGV2aWNlIG5vZGUNCj4gPj4gLQkJICog aW5kaWNhdGVzIHRoYXQgaXQgaXMgdGhlIHByaW1hcnkgTURQIHJkbWEgZGV2aWNlIGFuZCBNRFAg RE1BDQo+ID4+IC0JCSAqIG9wcyBzaG91bGQgYmUgaGFuZGxlZCBieSBpdHMgRE1BIGNhbGxiYWNr cy4NCj4gPj4gKwkJICogTURQIERNQSBvcHMgd2lsbCBiZSBoYW5kbGVkIGJ5IHRoZSBETUEgY2Fs bGJhY2tzIGFzc29jaWF0ZWQgd2l0aCB0aGlzDQo+ID4+ICsJCSAqIGRldmljZTsNCj4gPj4gIAkJ ICovDQo+ID4+ICAJCW1kcC0+cmRtYV9kZXYgPSBkZXY7DQo+ID4+ICAJfQ0KPiA+PiBkaWZmIC0t Z2l0IGEvZHJpdmVycy9tZWRpYS9wbGF0Zm9ybS9tdGstbWRwL210a19tZHBfY29yZS5jIGIvZHJp dmVycy9tZWRpYS9wbGF0Zm9ybS9tdGstbWRwL210a19tZHBfY29yZS5jDQo+ID4+IGluZGV4IDUw ZWFmY2M5OTkzZC4uNmE3NzU0NjMzOTljIDEwMDY0NA0KPiA+PiAtLS0gYS9kcml2ZXJzL21lZGlh L3BsYXRmb3JtL210ay1tZHAvbXRrX21kcF9jb3JlLmMNCj4gPj4gKysrIGIvZHJpdmVycy9tZWRp YS9wbGF0Zm9ybS9tdGstbWRwL210a19tZHBfY29yZS5jDQo+ID4+IEBAIC0xNTAsOCArMTUwLDkg QEAgc3RhdGljIHZvaWQgcmVsZWFzZV9vZihzdHJ1Y3QgZGV2aWNlICpkZXYsIHZvaWQgKmRhdGEp DQo+ID4+ICANCj4gPj4gIHN0YXRpYyBpbnQgbXRrX21kcF9tYXN0ZXJfYmluZChzdHJ1Y3QgZGV2 aWNlICpkZXYpDQo+ID4+ICB7DQo+ID4+IC0JaW50IHN0YXR1czsNCj4gPj4gIAlzdHJ1Y3QgbXRr X21kcF9kZXYgKm1kcCA9IGRldl9nZXRfZHJ2ZGF0YShkZXYpOw0KPiA+PiArCXN0cnVjdCBkZXZp Y2Vfbm9kZSAqdnB1X25vZGU7DQo+ID4+ICsJaW50IHN0YXR1czsNCj4gPj4gIA0KPiA+PiAgCXN0 YXR1cyA9IGNvbXBvbmVudF9iaW5kX2FsbChkZXYsIG1kcCk7DQo+ID4+ICAJaWYgKHN0YXR1cykg ew0KPiA+PiBAQCAtMTU5LDE1ICsxNjAsMzAgQEAgc3RhdGljIGludCBtdGtfbWRwX21hc3Rlcl9i aW5kKHN0cnVjdCBkZXZpY2UgKmRldikNCj4gPj4gIAkJZ290byBlcnJfY29tcG9uZW50X2JpbmRf YWxsOw0KPiA+PiAgCX0NCj4gPj4gIA0KPiA+PiAtCWlmIChtZHAtPnZwdV9kZXYpIHsNCj4gPj4g LQkJaW50IHJldCA9IHZwdV93ZHRfcmVnX2hhbmRsZXIobWRwLT52cHVfZGV2LCBtdGtfbWRwX3Jl c2V0X2hhbmRsZXIsIG1kcCwNCj4gPj4gLQkJCQkJICBWUFVfUlNUX01EUCk7DQo+ID4+IC0JCWlm IChyZXQpIHsNCj4gPj4gLQkJCWRldl9lcnIoZGV2LCAiRmFpbGVkIHRvIHJlZ2lzdGVyIHJlc2V0 IGhhbmRsZXJcbiIpOw0KPiA+PiAtCQkJZ290byBlcnJfd2R0X3JlZzsNCj4gPj4gLQkJfQ0KPiA+ PiAtCX0gZWxzZSB7DQo+ID4+IC0JCWRldl9lcnIoZGV2LCAibm8gdnB1X2RldiBmb3VuZFxuIik7 DQo+ID4+ICsJaWYgKG1kcC0+cmRtYV9kZXYgPT0gTlVMTCkgew0KPiA+PiArCQlkZXZfZXJyKGRl diwgIlByaW1hcnkgTURQIGRldmljZSBub3QgZm91bmQiKTsNCj4gPj4gKwkJc3RhdHVzID0gLUVO T0RFVjsNCj4gPj4gKwkJZ290byBlcnJfY29tcG9uZW50X2JpbmRfYWxsOw0KPiA+PiArCX0NCj4g Pj4gKw0KPiA+PiArCXZwdV9ub2RlID0gb2ZfZmluZF9ub2RlX2J5X25hbWUoTlVMTCwgInZwdSIp Ow0KPiA+PiArCWlmICghdnB1X25vZGUpIHsNCj4gPj4gKwkJZGV2X2VycihkZXYsICJ1bmFibGUg dG8gZmluZCB2cHUgbm9kZSIpOw0KPiA+PiArCQlzdGF0dXMgPSAtRU5PREVWOw0KPiA+PiArCQln b3RvIGVycl93ZHRfcmVnOw0KPiA+PiArCX0NCj4gPj4gKw0KPiA+PiArCW1kcC0+dnB1X2RldiA9 IG9mX2ZpbmRfZGV2aWNlX2J5X25vZGUodnB1X25vZGUpOw0KPiA+IA0KPiA+IFRoZSAndnB1X25v ZGUnIHNob3VsZCBiZSBwdXQgYnkgY2FsbGluZyAnb2Zfbm9kZV9wdXQodnB1X25vZGUpJyB3aGVu IGl0DQo+ID4gaXMgbm90IHVzZWQuDQo+ID4gDQo+ID4+ICsJaWYgKCFtZHAtPnZwdV9kZXYpIHsN Cj4gPj4gKwkJZGV2X2VycihkZXYsICJ1bmFibGUgdG8gZmluZCB2cHUgZGV2aWNlIik7DQo+ID4+ ICsJCXN0YXR1cyA9IC1FTk9ERVY7DQo+ID4+ICsJCWdvdG8gZXJyX3dkdF9yZWc7DQo+ID4+ICsJ fQ0KPiA+PiArDQo+ID4+ICsJc3RhdHVzID0gdnB1X3dkdF9yZWdfaGFuZGxlcihtZHAtPnZwdV9k ZXYsIG10a19tZHBfcmVzZXRfaGFuZGxlciwgbWRwLCBWUFVfUlNUX01EUCk7DQo+ID4+ICsJaWYg KHN0YXR1cykgew0KPiA+PiArCQlkZXZfZXJyKGRldiwgIkZhaWxlZCB0byByZWdpc3RlciByZXNl dCBoYW5kbGVyXG4iKTsNCj4gPj4gKwkJZ290byBlcnJfd2R0X3JlZzsNCj4gPj4gIAl9DQo+ID4+ ICANCj4gPj4gIAlzdGF0dXMgPSBtdGtfbWRwX3JlZ2lzdGVyX20ybV9kZXZpY2UobWRwKTsNCj4g PiANCg0K 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=-16.0 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, 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 57D2DC4320A for ; Wed, 25 Aug 2021 15:18:49 +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 198D9610FD for ; Wed, 25 Aug 2021 15:18:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 198D9610FD 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=/lso+AN6T02K92+3F5b+vHB1hIG3foQLLAhemsTrtos=; b=wE5UCi470YLdwA gMvRUiz7RWnJ7hAeuJF5FSnyzt6IUa2v7r57r0jVlQ8IN6H2l1NxsaImj3VgjL/k5hbNTMz0KJcqJ NF/pguLaHVrg1CGuHrA1IcU8YMcx2fOKM5jJixRCX5xK8S8ipyK/rBrabaYvWFIY5eizOC2e4KviW IU1sR/hG+MY4lY2izL18rVOAxdi/P3KpxI0A0p/JOhl3KfOZxtqHCQpLbGplqBewOzBeBLDPUo/fC Dw3M55IbfhSrNcKJ7bo0gyKMY2fB+jkD9mo1bYlvwRs8x7Uv6AkykhmqQF4nAvQ/8KlNw54wma7DN rq+QqC/Ih4bP0zjt5Wow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIufh-007Vgb-8N; Wed, 25 Aug 2021 15:18:33 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIufb-007Veu-Nh; Wed, 25 Aug 2021 15:18:31 +0000 X-UUID: 1efacd26ce524f5b892974c39c806bf7-20210825 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=AvZ/1szMK7QPpc3wUkxkUpWTIZXC+pUg9drjZUKq8Jc=; b=BSdsjZpz1ezSbni7ggqRdbycR9DLpSQ0nhHiLOzxsn71z3uVnlpKa1nHLdjZGKLC7m1sWihRdkkq9uAl+Xt9RHTDJjBqoeHWAnDgqrbTvj4EL/+RWztWe6qSbWDlJHVC5I2cbnjQ5QUfb5EASsovKyREYLSDx9ytU93790PWt8E=; X-UUID: 1efacd26ce524f5b892974c39c806bf7-20210825 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 375637768; Wed, 25 Aug 2021 08:18:21 -0700 Received: from mtkmbs05n2.mediatek.inc (172.21.101.140) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Aug 2021 08:18:20 -0700 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by mtkmbs05n2.mediatek.inc (172.21.101.140) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Aug 2021 23:18:18 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Wed, 25 Aug 2021 23:18:17 +0800 Message-ID: <1629904697.15752.11.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: Wed, 25 Aug 2021 23:18:17 +0800 In-Reply-To: <0c9fa482-57dd-d4ef-c65b-01f137c57359@collabora.com> References: <20210825063323.3607738-1-eizan@chromium.org> <20210825163247.v7.7.I2049e180dca12e0d1b3178bfc7292dcf9e05ac28@changeid> <1629880999.12893.17.camel@mhfsdcap03> <0c9fa482-57dd-d4ef-c65b-01f137c57359@collabora.com> 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-20210825_081827_825618_7CEC61CD X-CRM114-Status: GOOD ( 56.47 ) 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 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. 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. 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. >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. 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=-16.0 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, 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 74E1FC4338F for ; Wed, 25 Aug 2021 15:21:03 +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 324D16108D for ; Wed, 25 Aug 2021 15:21:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 324D16108D 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=ZFKSABDBuRUhuc9lUbBm0TrQ7tQgN9nM8KmetGfX0SU=; b=qRaUO5/H95e5lB tHzflsQoS3bfYroSzmqZYV+Odz0XbeQeVa7ArIPNIiXG4JPmnxWuwOjVNbE0FSPX+nNWf/FEAdYVC 9LcngP7Ur7qg4MYxahJVqAEwkhrQrfqYWkR6OdcsAG1ICe2VB2LyREgkByLZvK7gLaYGRTI85FvHN bMmKyNBVuzHWLWQfHBZGnv9wNoRZVIPt5UzzzV3UBKV0dYOlA+lsMhmkxJlG3iUYQ5NqHXpR0oub/ /Bq4iPHMymRogs6YavCjUVmXvKBppRX9AuzC7d5Ey2KcysINrJuaQslHs/FVM0rJEfXZze/QsLCda XW2cg8c3dofZBnZsqwzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIufj-007Vgr-VV; Wed, 25 Aug 2021 15:18:36 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIufb-007Veu-Nh; Wed, 25 Aug 2021 15:18:31 +0000 X-UUID: 1efacd26ce524f5b892974c39c806bf7-20210825 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=AvZ/1szMK7QPpc3wUkxkUpWTIZXC+pUg9drjZUKq8Jc=; b=BSdsjZpz1ezSbni7ggqRdbycR9DLpSQ0nhHiLOzxsn71z3uVnlpKa1nHLdjZGKLC7m1sWihRdkkq9uAl+Xt9RHTDJjBqoeHWAnDgqrbTvj4EL/+RWztWe6qSbWDlJHVC5I2cbnjQ5QUfb5EASsovKyREYLSDx9ytU93790PWt8E=; X-UUID: 1efacd26ce524f5b892974c39c806bf7-20210825 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 375637768; Wed, 25 Aug 2021 08:18:21 -0700 Received: from mtkmbs05n2.mediatek.inc (172.21.101.140) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Aug 2021 08:18:20 -0700 Received: from MTKCAS36.mediatek.inc (172.27.4.186) by mtkmbs05n2.mediatek.inc (172.21.101.140) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Aug 2021 23:18:18 +0800 Received: from [10.17.3.153] (10.17.3.153) by MTKCAS36.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Wed, 25 Aug 2021 23:18:17 +0800 Message-ID: <1629904697.15752.11.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: Wed, 25 Aug 2021 23:18:17 +0800 In-Reply-To: <0c9fa482-57dd-d4ef-c65b-01f137c57359@collabora.com> References: <20210825063323.3607738-1-eizan@chromium.org> <20210825163247.v7.7.I2049e180dca12e0d1b3178bfc7292dcf9e05ac28@changeid> <1629880999.12893.17.camel@mhfsdcap03> <0c9fa482-57dd-d4ef-c65b-01f137c57359@collabora.com> 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-20210825_081827_825618_7CEC61CD X-CRM114-Status: GOOD ( 56.47 ) 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 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. 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. 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. >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. 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