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, 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 4141CC433F5 for ; Sun, 5 Sep 2021 16:26:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 20ED060F14 for ; Sun, 5 Sep 2021 16:26:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238073AbhIEQ15 (ORCPT ); Sun, 5 Sep 2021 12:27:57 -0400 Received: from mailgw02.mediatek.com ([1.203.163.81]:35105 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S231847AbhIEQ1z (ORCPT ); Sun, 5 Sep 2021 12:27:55 -0400 X-UUID: bdd6364aafb040cdaf2dc137b408bffc-20210906 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=EIqz+ZnAUQZmH1HiU63bFHwu9as+swac7cV0J0RfSGs=; b=rewXP08bW62y1vc1ogaDStDnHLXxO/F/DIoWoLGif0Xpd6yhrAEoAcSdxLYBUbeYMpw04gqQqPAypXIzGsQvP/fs8IvOrM+rqIwmGnx+1Adu7+LxGtqbIaMUZd+8hX2T9KLwudc7kf4m8QYh4IxMCbBUmasm/K+AiiDyYZebiR8=; X-UUID: bdd6364aafb040cdaf2dc137b408bffc-20210906 Received: from mtkcas36.mediatek.inc [(172.27.4.253)] by mailgw02.mediatek.com (envelope-from ) (mailgw01.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 2105537368; Mon, 06 Sep 2021 00:23:30 +0800 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by MTKMBS32N2.mediatek.inc (172.27.4.72) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Sep 2021 00:23:18 +0800 Received: from mhfsdcap04 (10.17.3.154) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 6 Sep 2021 00:23:17 +0800 Message-ID: Subject: Re: [PATCH v7 2/7] mtk-mdp: add driver to probe mdp components From: houlong wei To: Ezequiel Garcia , Eizan Miyamoto , Hans Verkuil CC: Linux Kernel Mailing List , "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?= , "Enric Balletbo i Serra" , 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 , linux-media , "moderated list:ARM/Mediatek SoC support" , Date: Mon, 6 Sep 2021 00:23:19 +0800 In-Reply-To: References: <20210825063323.3607738-1-eizan@chromium.org> <20210825163247.v7.2.Ie6d1e6e39cf9b5d6b2108ae1096af34c3d55880b@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: 082D29C5DBC44AB8D275D6244F57556B6E4A615786D52C2D39DE45030E8DE3322000:8 X-MTK: N Content-Transfer-Encoding: base64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org SGkgRXplcXVpZWwsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBhdHRlbnRpb24gdG8gdGhpcyBzZXJp ZXMgb2YgcGF0Y2hlcy4gSSBhbnN3ZXIgcGFydGlhbCBvZiB5b3VyIHF1ZXN0aW9ucyBiZWxvdy4N ClJlZ2FyZHMsDQpIb3Vsb25nDQoNCk9uIFNhdCwgMjAyMS0wOS0wNCBhdCAyMDozNCArMDgwMCwg RXplcXVpZWwgR2FyY2lhIHdyb3RlOg0KPiBIaSBFaXphbiwNCj4gDQo+IFNvcnJ5IGZvciBzZWVp bmcgdGhpcyBzZXJpZXMgc28gbGF0ZS4NCj4gDQo+IE9uIFdlZCwgMjUgQXVnIDIwMjEgYXQgMDM6 MzUsIEVpemFuIE1peWFtb3RvIDxlaXphbkBjaHJvbWl1bS5vcmc+DQo+IHdyb3RlOg0KPiA+IA0K PiA+IEJyb2FkbHksIHRoaXMgcGF0Y2ggKDEpIGFkZHMgYSBkcml2ZXIgZm9yIHZhcmlvdXMgTVRL IE1EUA0KPiA+IGNvbXBvbmVudHMgdG8NCj4gPiBnbyBhbG9uZ3NpZGUgdGhlIG1haW4gTVRLIE1E UCBkcml2ZXIsIGFuZCAoMikgaG9va3MgdGhlbSBhbGwNCj4gPiB0b2dldGhlcg0KPiA+IHVzaW5n IHRoZSBjb21wb25lbnQgZnJhbWV3b3JrLg0KPiA+IA0KPiA+ICgxKSBVcCB1bnRpbCBub3csIHRo ZSBNVEsgTURQIGRyaXZlciBjb250cm9scyA4IGRldmljZXMgaW4gdGhlDQo+ID4gZGV2aWNlDQo+ ID4gdHJlZSBvbiBpdHMgb3duLiBXaGVuIHJ1bm5pbmcgdGVzdHMgZm9yIHRoZSBoYXJkd2FyZSB2 aWRlbyBkZWNvZGVyLA0KPiA+IHdlDQo+ID4gZm91bmQgdGhhdCB0aGUgaW9tbXVzIGFuZCBMQVJC cyB3ZXJlIG5vdCBiZWluZyBwcm9wZXJseSBjb25maWd1cmVkLg0KPiANCj4gV2h5IHdlcmUgbm90 IGJlaW5nIHByb3Blcmx5IGNvbmZpZ3VyZWQ/IFdoYXQgd2FzIHRoZSBwcm9ibGVtPw0KPiBXaHkg bm90IGZpeGluZyB0aGF0IGluc3RlYWQ/DQo+IA0KPiBEb2VzIHRoaXMgbWVhbiB0aGUgZHJpdmVy IGlzIGN1cnJlbnRseSBicm9rZW4gYW5kIHVudXNhYmxlPw0KDQpUaGlzIHNlcmllcyBvZiBwYXRj aGVzIGFyZSBzdXBwbGVtZW50cyB0byBhbm90aGVyIHNlcmllcywgcGxlYXNlIHJlZmVyDQp0byAg DQpodHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3QvbGludXgtbWVkaWF0ZWsvbGlz dC8/c2VyaWVzPTUxNTEyOWMNCiwgd2hpY2ggYWRkIGRldmljZSBsaW5rIGJldHdlZW4gdGhlIG10 ay1pb21tdSBjb25zdW1lciBhbmQgdGhlIG10ay1sYXJiIA0KZGV2aWNlcy4gV2l0aG91dCB0aGF0 IHNlcmllcyBvZiBwYXRjaGVzLCB0aGUgbXRrLW1kcCBkcml2ZXIgY2FuIHdvcmsNCndlbGwgc28g ZmFyLg0KQnV0IHdpdGggdGhhdCBzZXJpZXMsIGl0IHNlZW1zIHRoZSBkZXZpY2UgbGluayBvbmx5 IGNhbiBiZSBlc3RhYmxpc2hlZA0KZm9yIHRoZSBkZXZpY2Ugd2hpY2ggaXMgcmVnaXN0ZXJlZCBh cyBhIHBsYXRmb3JtIGRyaXZlci4gVGhhdCdzIHdoeQ0KRWl6YW4gYWRkcyB0aGlzIHNlcmllcyBv ZiBwYXRjaGVzIHRvIG1ha2UgYWxsIG1kcCBjb21wb25lbnRzIHRvIGJlDQpyZWdpc3RlcmVkIGFz IHBsYXRmb3JtIGRyaXZlcnMuDQoNCj4gDQo+ID4gVG8NCj4gPiBjb25maWd1cmUgdGhlbSwgYSBk cml2ZXIgZm9yIGVhY2ggYmUgYWRkZWQgdG8gbXRrX21kcF9jb21wIHNvIHRoYXQNCj4gPiBtdGtf aW9tbXVfYWRkX2RldmljZSgpIGNhbiAoZXZlbnR1YWxseSkgYmUgY2FsbGVkIGZyb20NCj4gPiBk bWFfY29uZmlndXJlKCkNCj4gPiBpbnNpZGUgcmVhbGx5X3Byb2JlKCkuDQo+ID4gDQo+ID4gKDIp IFRoZSBpbnRlZ3JhdGlvbiBpbnRvIHRoZSBjb21wb25lbnQgZnJhbWV3b3JrIGFsbG93cyB1cyB0 byBkZWZlcg0KPiA+IHRoZQ0KPiA+IHJlZ2lzdHJhdGlvbiB3aXRoIHRoZSB2NGwyIHN1YnN5c3Rl bSB1bnRpbCBhbGwgdGhlIE1EUC1yZWxhdGVkDQo+ID4gZGV2aWNlcw0KPiA+IGhhdmUgYmVlbiBw cm9iZWQsIHNvIHRoYXQgdGhlIHJlbGV2YW50IGRldmljZSBub2RlIGRvZXMgbm90IGJlY29tZQ0K PiA+IGF2YWlsYWJsZSB1bnRpbCBpbml0aWFsaXphdGlvbiBvZiBhbGwgdGhlIGNvbXBvbmVudHMg aXMgY29tcGxldGUuDQo+ID4gDQo+ID4gU29tZSBub3RlcyBhYm91dCBob3cgdGhlIGNvbXBvbmVu dCBmcmFtZXdvcmsgaGFzIGJlZW4gaW50ZWdyYXRlZDoNCj4gPiANCj4gPiAtIFRoZSBkcml2ZXIg Zm9yIHRoZSByZG1hMCBjb21wb25lbnQgc2VydmVzIGRvdWJsZSBkdXR5IGFzIHRoZQ0KPiA+ICJt YXN0ZXIiDQo+ID4gICAoYWdncmVnYXRlKSBkcml2ZXIgYXMgd2VsbCBhcyBhIGNvbXBvbmVudCBk cml2ZXIuIFRoaXMgaXMgYSBub24tDQo+ID4gaWRlYWwNCj4gPiAgIGNvbXByb21pc2UgdW50aWwg YSBiZXR0ZXIgc29sdXRpb24gaXMgZGV2ZWxvcGVkLiBUaGlzIGRldmljZSBpcw0KPiA+ICAgZGlm ZmVyZW50aWF0ZWQgZnJvbSB0aGUgcmVzdCBieSBjaGVja2luZyBmb3IgYSAibWVkaWF0ZWssdnB1 Ig0KPiA+IHByb3BlcnR5DQo+ID4gICBpbiB0aGUgZGV2aWNlIG5vZGUuDQo+ID4gDQo+IA0KPiBB cyBJIGhhdmUgc3RhdGVkIGluIFl1bmZlaSwgSSBhbSBub3QgY29udmluY2VkIHlvdSBuZWVkIGFu IGFzeW5jDQo+IGZyYW1ld29yaw0KPiBhdCBhbGwuIEl0IHNlZW1zIGFsbCB0aGVzZSBkZXZpY2Vz IGNvdWxkIGhhdmUgYmVlbiBsaW5rZWQgdG9nZXRoZXINCj4gaW4gdGhlIGRldmljZSB0cmVlLCBh bmQgdGhlbiBoYXZlIGEgbWFzdGVyIGRldmljZSB0byB0aWUgdGhlbS4NCj4gDQo+IEkuZS4gc29t ZXRoaW5nIGxpa2UNCj4gDQo+IG1kcCB7DQo+ICAgbWRwX3JkbWEwIHsNCj4gICB9DQo+ICAgbWRw X3JzejAgew0KPiAgIH0NCj4gICBtZHBfcnN6MSB7DQo+ICAgfQ0KPiB9DQo+IA0KDQpUaGUgY29t bWl0IG1lc3NhZ2Ugb2YgdGhlIHBhdGNoIGJlbG93IGV4cGxhaW5zIHRoYXQgIiBJZiB0aGUgbWRw XyoNCm5vZGVzIGFyZSB1bmRlciBhbiBtZHAgc3ViLW5vZGUsIHRoZWlyIGNvcnJlc3BvbmRpbmcg cGxhdGZvcm0gZGV2aWNlDQpkb2VzIG5vdCBhdXRvbWF0aWNhbGx5IGdldCBpdHMgaW9tbXUgYXNz aWduZWQgcHJvcGVybHkuIg0KUGxlYXNlIHJlZmVyIHRvIA0KaHR0cHM6Ly9naXQua2VybmVsLm9y Zy9wdWIvc2NtL2xpbnV4L2tlcm5lbC9naXQvc3RhYmxlL2xpbnV4LmdpdC9jb21taXQvYXJjaC9h cm02NC9ib290L2R0cy9tZWRpYXRlay9tdDgxNzMuZHRzaT9oPXY1LjE0LjEmaWQ9ODEyNzg4MWY3 NDFkYmJmOWExZGE5ZTliYzU5MTMzODIwMTYwYjIxNw0KDQo+IEFsbCB0aGlzIGFzeW5jIGdhbWVz IHNlZW0gbGlrZSBtYWtpbmcgdGhlIGRyaXZlciByZWFsbHkgb2JmdXNjYXRlZCwNCj4gd2hpY2gg d2lsbCBtZWFuIGhhcmRlciB0byBkZWJ1ZyBhbmQgbWFpbnRhaW4uDQo+IEkgYW0gbm90IHN1cmUg d2Ugd2FudCB0aGF0IGJ1cmRlbi4NCj4gDQo+IEV2ZW4gaWYgd2UgYXJlIGFsbCBmdWxseSBjb252 aW5jZWQgdGhhdCB5b3UgYWJzb2x1dGVseSBuZWVkDQo+IGFuIGFzeW5jIGZyYW1ld29yaywgdGhl biB3aGF0J3Mgd3Jvbmcgd2l0aCB2NGwyLWFzeW5jPw0KPiANCj4gSSB3b3VsZCBzdGFydCBieSBh ZGRyZXNzaW5nIHdoYXQgaXMgd3Jvbmcgd2l0aCB0aGUgSU9NTVVzDQo+IGluIHRoZSBjdXJyZW50 IGRlc2lnbi4NCj4gDQo+IFRoYW5rcywNCj4gRXplcXVpZWwNCj4gDQo+ID4gLSBUaGUgbGlzdCBv ZiBtZHAgY29tcG9uZW50cyByZW1haW5zIGhhcmQtY29kZWQgYXMNCj4gPiBtdGtfbWRwX2NvbXBf ZHRfaWRzW10NCj4gPiAgIGluIG10a19tZHBfY29yZS5jLCBhbmQgYXMgbXRrX21kcF9jb21wX2Ry aXZlcl9kdF9tYXRjaFtdIGluDQo+ID4gICBtdGtfbWRwX2NvbXAuYy4gVGhpcyB1bmZvcnR1bmF0 ZSBkdXBsaWNhdGlvbiBvZiBpbmZvcm1hdGlvbiBpcw0KPiA+ICAgYWRkcmVzc2VkIGluIGEgZm9s bG93aW5nIHBhdGNoIGluIHRoaXMgc2VyaWVzLg0KPiA+IA0KPiA+IC0gVGhlIGNvbXBvbmVudCBk cml2ZXIgY2FsbHMgY29tcG9uZW50X2FkZCgpIGZvciBlYWNoIGRldmljZSB0aGF0DQo+ID4gaXMN Cj4gPiAgIHByb2JlZC4NCj4gPiANCj4gPiAtIEluIG10a19tZHBfcHJvYmUgKHRoZSAibWFzdGVy IiBkZXZpY2UpLCB3ZSBzY2FuIHRoZSBkZXZpY2UgdHJlZQ0KPiA+IGZvcg0KPiA+ICAgYW55IG1h dGNoaW5nIG5vZGVzIGFnYWluc3QgbXRrX21kcF9jb21wX2R0X2lkcywgYW5kIGFkZCBjb21wb25l bnQNCj4gPiAgIG1hdGNoZXMgZm9yIHRoZW0uIFRoZSBtYXRjaCBjcml0ZXJpYSBpcyBhIG1hdGNo aW5nIGRldmljZSBub2RlDQo+ID4gICBwb2ludGVyLg0KPiA+IA0KPiA+IC0gV2hlbiB0aGUgc2V0 IG9mIGNvbXBvbmVudHMgZGV2aWNlcyB0aGF0IGhhdmUgYmVlbiBwcm9iZWQNCj4gPiBjb3JyZXNw b25kcw0KPiA+ICAgd2l0aCB0aGUgbGlzdCB0aGF0IGlzIGdlbmVyYXRlZCBieSB0aGUgIm1hc3Rl ciIsIHRoZSBjYWxsYmFjayB0bw0KPiA+ICAgbXRrX21kcF9tYXN0ZXJfYmluZCgpIGlzIG1hZGUs IHdoaWNoIHRoZW4gY2FsbHMgdGhlIGNvbXBvbmVudA0KPiA+IGJpbmQNCj4gPiAgIGZ1bmN0aW9u cy4NCj4gPiANCj4gPiAtIEluc2lkZSBtdGtfbWRwX21hc3Rlcl9iaW5kKCksIG9uY2UgYWxsIHRo ZSBjb21wb25lbnQgYmluZA0KPiA+IGZ1bmN0aW9ucw0KPiA+ICAgaGF2ZSBiZWVuIGNhbGxlZCwg d2UgY2FuIHRoZW4gcmVnaXN0ZXIgb3VyIGRldmljZSB0byB0aGUgdjRsMg0KPiA+ICAgc3Vic3lz dGVtLg0KPiA+IA0KPiA+IC0gVGhlIGNhbGwgdG8gcG1fcnVudGltZV9lbmFibGUoKSBpbiB0aGUg bWFzdGVyIGRldmljZSBpcyBjYWxsZWQNCj4gPiBhZnRlcg0KPiA+ICAgYWxsIHRoZSBjb21wb25l bnRzIGhhdmUgYmVlbiByZWdpc3RlcmVkIGJ5IHRoZWlyIGJpbmQoKSBmdW5jdGlvbnMNCj4gPiAg IGNhbGxlZCBieSBtdGtfbXRwX21hc3Rlcl9iaW5kKCkuIEFzIGEgcmVzdWx0LCB0aGUgbGlzdCBv Zg0KPiA+IGNvbXBvbmVudHMNCj4gPiAgIHdpbGwgbm90IGNoYW5nZSB3aGlsZSBwb3dlciBtYW5h Z2VtZW50IGNhbGxiYWNrcw0KPiA+IG10a19tZHBfc3VzcGVuZCgpLw0KPiA+ICAgcmVzdW1lKCkg YXJlIGFjY2Vzc2luZyB0aGUgbGlzdCBvZiBjb21wb25lbnRzLg0KPiA+IA0KPiA+IFNpZ25lZC1v ZmYtYnk6IEVpemFuIE1peWFtb3RvIDxlaXphbkBjaHJvbWl1bS5vcmc+DQo+ID4gUmV2aWV3ZWQt Ynk6IEVucmljIEJhbGxldGJvIGkgU2VycmEgPGVucmljLmJhbGxldGJvQGNvbGxhYm9yYS5jb20+ DQo+ID4gUmV2aWV3ZWQtYnk6IEhvdWxvbmcgV2VpIDxob3Vsb25nLndlaUBtZWRpYXRlay5jb20+ DQo+ID4gLS0tDQo+ID4gDQoNCg== 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, 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 DB392C433EF for ; Sun, 5 Sep 2021 16:34:01 +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 8113460EE6 for ; Sun, 5 Sep 2021 16:34:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8113460EE6 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=hC44rXUGgIwP4HJarTqz8yZQvIegq6cSZct5guq9u54=; b=0d6VDfG7H5Vkbm T5kE990U8NHfiuCsDd+8Tj6n2rxiXMp7pe5EW0T5fsNdAAA3DDdUJNceoLLvgspX60xSgHjhhX5us lONyS/ech2O+TGAr01cIotDQ0fJ+0ix7wzH+kO80+PgwuQ/VIZi8UxaQd25yV/AOGY5JizpEbrlOu GSA21w/pMUVx42exSUKPrW4M3cDf5bsvUdsAok6b7xytVgHaaVXFK5Zgx4QeYb/DEFcjoqNCebBvI OnhiYPL8YIh86f80XEz/WAkdPQel8uoKHQky6sCR5CmlXUN3v0soDtRD5jPF980b0DoQV6fU6VqNP 2FYQyNuw+I28hD2TLd5w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mMv5Z-00G6Eo-K9; Sun, 05 Sep 2021 16:33:49 +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 1mMv5U-00G6EK-P2; Sun, 05 Sep 2021 16:33:48 +0000 X-UUID: 20f26382c8d54d4c913d7fe563ef90eb-20210905 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=EIqz+ZnAUQZmH1HiU63bFHwu9as+swac7cV0J0RfSGs=; b=rewXP08bW62y1vc1ogaDStDnHLXxO/F/DIoWoLGif0Xpd6yhrAEoAcSdxLYBUbeYMpw04gqQqPAypXIzGsQvP/fs8IvOrM+rqIwmGnx+1Adu7+LxGtqbIaMUZd+8hX2T9KLwudc7kf4m8QYh4IxMCbBUmasm/K+AiiDyYZebiR8=; X-UUID: 20f26382c8d54d4c913d7fe563ef90eb-20210905 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 101096204; Sun, 05 Sep 2021 09:33:39 -0700 Received: from MTKMBS32N2.mediatek.inc (172.27.4.72) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 5 Sep 2021 09:23:30 -0700 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by MTKMBS32N2.mediatek.inc (172.27.4.72) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Sep 2021 00:23:18 +0800 Received: from mhfsdcap04 (10.17.3.154) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 6 Sep 2021 00:23:17 +0800 Message-ID: Subject: Re: [PATCH v7 2/7] mtk-mdp: add driver to probe mdp components From: houlong wei To: Ezequiel Garcia , Eizan Miyamoto , Hans Verkuil CC: Linux Kernel Mailing List , "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?= , "Enric Balletbo i Serra" , 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 , linux-media , "moderated list:ARM/Mediatek SoC support" , Date: Mon, 6 Sep 2021 00:23:19 +0800 In-Reply-To: References: <20210825063323.3607738-1-eizan@chromium.org> <20210825163247.v7.2.Ie6d1e6e39cf9b5d6b2108ae1096af34c3d55880b@changeid> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-TM-SNTS-SMTP: 082D29C5DBC44AB8D275D6244F57556B6E4A615786D52C2D39DE45030E8DE3322000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210905_093346_260041_3BBB4D16 X-CRM114-Status: GOOD ( 45.96 ) 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 Ezequiel, Thank you for your attention to this series of patches. I answer partial of your questions below. Regards, Houlong On Sat, 2021-09-04 at 20:34 +0800, Ezequiel Garcia wrote: > Hi Eizan, > > Sorry for seeing this series so late. > > On Wed, 25 Aug 2021 at 03:35, Eizan Miyamoto > wrote: > > > > Broadly, this patch (1) adds a driver for various MTK MDP > > components to > > go alongside the main MTK MDP driver, and (2) hooks them all > > together > > using the component framework. > > > > (1) Up until now, the MTK MDP driver controls 8 devices in the > > device > > tree on its own. When running tests for the hardware video decoder, > > we > > found that the iommus and LARBs were not being properly configured. > > Why were not being properly configured? What was the problem? > Why not fixing that instead? > > Does this mean the driver is currently broken and unusable? This series of patches are supplements to another series, please refer to https://patchwork.kernel.org/project/linux-mediatek/list/?series=515129c , which add device link between the mtk-iommu consumer and the mtk-larb devices. Without that series of patches, the mtk-mdp driver can work well so far. But with that series, it seems the device link only can be established for the device which is registered as a platform driver. That's why Eizan adds this series of patches to make all mdp components to be registered as platform drivers. > > > To > > configure them, a driver for each be added to mtk_mdp_comp so that > > mtk_iommu_add_device() can (eventually) be called from > > dma_configure() > > inside really_probe(). > > > > (2) The integration into the component framework allows us to defer > > the > > registration with the v4l2 subsystem until all the MDP-related > > devices > > have been probed, so that the relevant device node does not become > > available until initialization of all the components is complete. > > > > Some notes about how the component framework has been integrated: > > > > - The driver for the rdma0 component serves double duty as the > > "master" > > (aggregate) driver as well as a component driver. This is a non- > > ideal > > compromise until a better solution is developed. This device is > > differentiated from the rest by checking for a "mediatek,vpu" > > property > > in the device node. > > > > As I have stated in Yunfei, I am not convinced you need an async > framework > at all. It seems all these devices could have been linked together > in the device tree, and then have a master device to tie them. > > I.e. something like > > mdp { > mdp_rdma0 { > } > mdp_rsz0 { > } > mdp_rsz1 { > } > } > The commit message of the patch below explains that " If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly." Please refer to https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v5.14.1&id=8127881f741dbbf9a1da9e9bc59133820160b217 > All this async games seem like making the driver really obfuscated, > which will mean harder to debug and maintain. > I am not sure we want that burden. > > Even if we are all fully convinced that you absolutely need > an async framework, then what's wrong with v4l2-async? > > I would start by addressing what is wrong with the IOMMUs > in the current design. > > Thanks, > Ezequiel > > > - The list of mdp components remains hard-coded as > > mtk_mdp_comp_dt_ids[] > > in mtk_mdp_core.c, and as mtk_mdp_comp_driver_dt_match[] in > > mtk_mdp_comp.c. This unfortunate duplication of information is > > addressed in a following patch in this series. > > > > - The component driver calls component_add() for each device that > > is > > probed. > > > > - In mtk_mdp_probe (the "master" device), we scan the device tree > > for > > any matching nodes against mtk_mdp_comp_dt_ids, and add component > > matches for them. The match criteria is a matching device node > > pointer. > > > > - When the set of components devices that have been probed > > corresponds > > with the list that is generated by the "master", the callback to > > mtk_mdp_master_bind() is made, which then calls the component > > bind > > functions. > > > > - Inside mtk_mdp_master_bind(), once all the component bind > > functions > > have been called, we can then register our device to the v4l2 > > subsystem. > > > > - The call to pm_runtime_enable() in the master device is called > > after > > all the components have been registered by their bind() functions > > called by mtk_mtp_master_bind(). As a result, the list of > > components > > will not change while power management callbacks > > mtk_mdp_suspend()/ > > resume() are accessing the list of components. > > > > Signed-off-by: Eizan Miyamoto > > Reviewed-by: Enric Balletbo i Serra > > Reviewed-by: Houlong Wei > > --- > > _______________________________________________ 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, 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 72B71C433EF for ; Sun, 5 Sep 2021 16:36:06 +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 3B57960EC0 for ; Sun, 5 Sep 2021 16:36:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3B57960EC0 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=OBbqoVV2a67y+YFzwqhlmz1GH8xkjf0JcHGrXgEMCUU=; b=fw3o8Zcs/fNp5q q/d0uITuWKnd8yeWiMDVrGVbcY6uRtakLd2mXUdeMaSMRmyy5s2KCRw0EQfypHm/90VyckTvMkvdJ 7NsPQ+UzQLw5P8q64oqAlnHQn3/e5YqiTc2PRKA6FFvZbiIaPt8V+tY2+oa9cB+j15nddYNnllEme PfG/s63Be3hG+/1QXn5gk+ithtORxzcnxTuDSbBjaXrU4It7iBGc/OGXACqfCZMmxlGQ9R4Tan4fG W9PLYv/yOzrBYFqwIuh2lxx5EgYZGsRDtxYBECT/BNUu8rP7/4j1fCpaC+EzlICQ7QjUZIQ9A727v kRovInlrcNXsWwO5+9MA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mMv5b-00G6Ev-EG; Sun, 05 Sep 2021 16:33:51 +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 1mMv5U-00G6EK-P2; Sun, 05 Sep 2021 16:33:48 +0000 X-UUID: 20f26382c8d54d4c913d7fe563ef90eb-20210905 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=EIqz+ZnAUQZmH1HiU63bFHwu9as+swac7cV0J0RfSGs=; b=rewXP08bW62y1vc1ogaDStDnHLXxO/F/DIoWoLGif0Xpd6yhrAEoAcSdxLYBUbeYMpw04gqQqPAypXIzGsQvP/fs8IvOrM+rqIwmGnx+1Adu7+LxGtqbIaMUZd+8hX2T9KLwudc7kf4m8QYh4IxMCbBUmasm/K+AiiDyYZebiR8=; X-UUID: 20f26382c8d54d4c913d7fe563ef90eb-20210905 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 101096204; Sun, 05 Sep 2021 09:33:39 -0700 Received: from MTKMBS32N2.mediatek.inc (172.27.4.72) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 5 Sep 2021 09:23:30 -0700 Received: from MTKCAS32.mediatek.inc (172.27.4.184) by MTKMBS32N2.mediatek.inc (172.27.4.72) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Sep 2021 00:23:18 +0800 Received: from mhfsdcap04 (10.17.3.154) by MTKCAS32.mediatek.inc (172.27.4.170) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 6 Sep 2021 00:23:17 +0800 Message-ID: Subject: Re: [PATCH v7 2/7] mtk-mdp: add driver to probe mdp components From: houlong wei To: Ezequiel Garcia , Eizan Miyamoto , Hans Verkuil CC: Linux Kernel Mailing List , "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?= , "Enric Balletbo i Serra" , 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 , linux-media , "moderated list:ARM/Mediatek SoC support" , Date: Mon, 6 Sep 2021 00:23:19 +0800 In-Reply-To: References: <20210825063323.3607738-1-eizan@chromium.org> <20210825163247.v7.2.Ie6d1e6e39cf9b5d6b2108ae1096af34c3d55880b@changeid> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-TM-SNTS-SMTP: 082D29C5DBC44AB8D275D6244F57556B6E4A615786D52C2D39DE45030E8DE3322000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210905_093346_260041_3BBB4D16 X-CRM114-Status: GOOD ( 45.96 ) 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 Ezequiel, Thank you for your attention to this series of patches. I answer partial of your questions below. Regards, Houlong On Sat, 2021-09-04 at 20:34 +0800, Ezequiel Garcia wrote: > Hi Eizan, > > Sorry for seeing this series so late. > > On Wed, 25 Aug 2021 at 03:35, Eizan Miyamoto > wrote: > > > > Broadly, this patch (1) adds a driver for various MTK MDP > > components to > > go alongside the main MTK MDP driver, and (2) hooks them all > > together > > using the component framework. > > > > (1) Up until now, the MTK MDP driver controls 8 devices in the > > device > > tree on its own. When running tests for the hardware video decoder, > > we > > found that the iommus and LARBs were not being properly configured. > > Why were not being properly configured? What was the problem? > Why not fixing that instead? > > Does this mean the driver is currently broken and unusable? This series of patches are supplements to another series, please refer to https://patchwork.kernel.org/project/linux-mediatek/list/?series=515129c , which add device link between the mtk-iommu consumer and the mtk-larb devices. Without that series of patches, the mtk-mdp driver can work well so far. But with that series, it seems the device link only can be established for the device which is registered as a platform driver. That's why Eizan adds this series of patches to make all mdp components to be registered as platform drivers. > > > To > > configure them, a driver for each be added to mtk_mdp_comp so that > > mtk_iommu_add_device() can (eventually) be called from > > dma_configure() > > inside really_probe(). > > > > (2) The integration into the component framework allows us to defer > > the > > registration with the v4l2 subsystem until all the MDP-related > > devices > > have been probed, so that the relevant device node does not become > > available until initialization of all the components is complete. > > > > Some notes about how the component framework has been integrated: > > > > - The driver for the rdma0 component serves double duty as the > > "master" > > (aggregate) driver as well as a component driver. This is a non- > > ideal > > compromise until a better solution is developed. This device is > > differentiated from the rest by checking for a "mediatek,vpu" > > property > > in the device node. > > > > As I have stated in Yunfei, I am not convinced you need an async > framework > at all. It seems all these devices could have been linked together > in the device tree, and then have a master device to tie them. > > I.e. something like > > mdp { > mdp_rdma0 { > } > mdp_rsz0 { > } > mdp_rsz1 { > } > } > The commit message of the patch below explains that " If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly." Please refer to https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v5.14.1&id=8127881f741dbbf9a1da9e9bc59133820160b217 > All this async games seem like making the driver really obfuscated, > which will mean harder to debug and maintain. > I am not sure we want that burden. > > Even if we are all fully convinced that you absolutely need > an async framework, then what's wrong with v4l2-async? > > I would start by addressing what is wrong with the IOMMUs > in the current design. > > Thanks, > Ezequiel > > > - The list of mdp components remains hard-coded as > > mtk_mdp_comp_dt_ids[] > > in mtk_mdp_core.c, and as mtk_mdp_comp_driver_dt_match[] in > > mtk_mdp_comp.c. This unfortunate duplication of information is > > addressed in a following patch in this series. > > > > - The component driver calls component_add() for each device that > > is > > probed. > > > > - In mtk_mdp_probe (the "master" device), we scan the device tree > > for > > any matching nodes against mtk_mdp_comp_dt_ids, and add component > > matches for them. The match criteria is a matching device node > > pointer. > > > > - When the set of components devices that have been probed > > corresponds > > with the list that is generated by the "master", the callback to > > mtk_mdp_master_bind() is made, which then calls the component > > bind > > functions. > > > > - Inside mtk_mdp_master_bind(), once all the component bind > > functions > > have been called, we can then register our device to the v4l2 > > subsystem. > > > > - The call to pm_runtime_enable() in the master device is called > > after > > all the components have been registered by their bind() functions > > called by mtk_mtp_master_bind(). As a result, the list of > > components > > will not change while power management callbacks > > mtk_mdp_suspend()/ > > resume() are accessing the list of components. > > > > Signed-off-by: Eizan Miyamoto > > Reviewed-by: Enric Balletbo i Serra > > Reviewed-by: Houlong Wei > > --- > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel