From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A336DC43214 for ; Mon, 30 Aug 2021 06:07:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7942060FD9 for ; Mon, 30 Aug 2021 06:07:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232583AbhH3GIm (ORCPT ); Mon, 30 Aug 2021 02:08:42 -0400 Received: from mailgw01.mediatek.com ([60.244.123.138]:55042 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S231911AbhH3GIl (ORCPT ); Mon, 30 Aug 2021 02:08:41 -0400 X-UUID: 6bfd825d6cfe4f84936fb0666c811423-20210830 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=yumP0/IwY8D7km3Voc8rlArhIG+mQ1XqIA8K80OLgb0=; b=cOYBKC0dz5tHSS3fs2CmlAfd+S9Y98RqoXr8P1v1qhmrDo22YBsTaJZXL83rv9ppVAaka9XwlJqW+GOgYgHaquXt4dlwhL5cB5sL59doFVcyUq74459JLWyHh9wAUyfWz7TdU3V+D+8dVOGGPd9gIR9mi8u4sTddxo8hxABW9wQ=; X-UUID: 6bfd825d6cfe4f84936fb0666c811423-20210830 Received: from mtkcas07.mediatek.inc [(172.21.101.84)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1232984155; Mon, 30 Aug 2021 14:07:45 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Aug 2021 14:07:44 +0800 Received: from mhfsdcap04 (10.17.3.154) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 30 Aug 2021 14:07:43 +0800 Message-ID: <885db6cd26907939511ff132c0fa3ad122c0e588.camel@mediatek.com> Subject: Re: [PATCH v5, 13/15] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192 From: "yunfei.dong@mediatek.com" To: Ezequiel Garcia , Laurent Pinchart CC: Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , "Tiffany Lin" , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , Hsin-Yi Wang , Fritz Koenig , Irui Wang , linux-media , devicetree , Linux Kernel Mailing List , linux-arm-kernel , srv_heupstream , "moderated list:ARM/Mediatek SoC support" , Project_Global_Chrome_Upstream_Group , George Sun Date: Mon, 30 Aug 2021 14:07:44 +0800 In-Reply-To: References: <20210811025801.21597-1-yunfei.dong@mediatek.com> <20210811025801.21597-14-yunfei.dong@mediatek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N Content-Transfer-Encoding: base64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org T24gU3VuLCAyMDIxLTA4LTI5IGF0IDE3OjUwIC0wMzAwLCBFemVxdWllbCBHYXJjaWEgd3JvdGU6 DQo+IE9uIFdlZCwgMTEgQXVnIDIwMjEgYXQgMTQ6NTksIExhdXJlbnQgUGluY2hhcnQNCj4gPGxh dXJlbnQucGluY2hhcnRAaWRlYXNvbmJvYXJkLmNvbT4gd3JvdGU6DQo+ID4gDQo+ID4gSGkgWXVu ZmVpLA0KPiA+IA0KPiA+IFRoYW5rIHlvdSBmb3IgdGhlIHBhdGNoLg0KPiA+IA0KPiA+IE9uIFdl ZCwgQXVnIDExLCAyMDIxIGF0IDEwOjU3OjU5QU0gKzA4MDAsIFl1bmZlaSBEb25nIHdyb3RlOg0K PiA+ID4gQWRkcyBkZWNvZGVyIGR0LWJpbmRpbmdzIGZvciBtdDgxOTIuDQo+ID4gPiANCj4gPiA+ IFNpZ25lZC1vZmYtYnk6IFl1bmZlaSBEb25nIDx5dW5mZWkuZG9uZ0BtZWRpYXRlay5jb20+DQo+ ID4gPiAtLS0NCj4gPiA+IHY1OiBubyBjaGFuZ2VzDQo+ID4gPiANCj4gPiA+IFRoaXMgcGF0Y2gg ZGVwZW5kcyBvbiAiTWVkaWF0ZWsgTVQ4MTkyIGNsb2NrIHN1cHBvcnQiWzFdLg0KPiA+ID4gDQo+ ID4gPiBUaGUgZGVmaW5pdGlvbiBvZiBkZWNvZGVyIGNsb2NrcyBhcmUgaW4gbXQ4MTkyLWNsay5o LCBuZWVkIHRvDQo+ID4gPiBpbmNsdWRlIHRoZW0gaW4gY2FzZSBvZiBidWlsZCBmYWlsIFsxXS4N Cj4gPiA+IA0KPiA+ID4gWzFdDQo+ID4gPiBodHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3By b2plY3QvbGludXgtbWVkaWF0ZWsvbGlzdC8/c2VyaWVzPTUxMTE3NQ0KPiA+ID4gLS0tDQo+ID4g PiAgLi4uL21lZGlhL21lZGlhdGVrLHZjb2RlYy1jb21wLWRlY29kZXIueWFtbCAgIHwgMTcyDQo+ ID4gPiArKysrKysrKysrKysrKysrKysNCj4gPiA+ICAxIGZpbGUgY2hhbmdlZCwgMTcyIGluc2Vy dGlvbnMoKykNCj4gPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQNCj4gPiA+IERvY3VtZW50YXRpb24v ZGV2aWNldHJlZS9iaW5kaW5ncy9tZWRpYS9tZWRpYXRlayx2Y29kZWMtY29tcC0NCj4gPiA+IGRl Y29kZXIueWFtbA0KPiA+ID4gDQo+ID4gPiBkaWZmIC0tZ2l0DQo+ID4gPiBhL0RvY3VtZW50YXRp b24vZGV2aWNldHJlZS9iaW5kaW5ncy9tZWRpYS9tZWRpYXRlayx2Y29kZWMtY29tcC0NCj4gPiA+ IGRlY29kZXIueWFtbA0KPiA+ID4gYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3Mv bWVkaWEvbWVkaWF0ZWssdmNvZGVjLWNvbXAtDQo+ID4gPiBkZWNvZGVyLnlhbWwNCj4gPiA+IG5l dyBmaWxlIG1vZGUgMTAwNjQ0DQo+ID4gPiBpbmRleCAwMDAwMDAwMDAwMDAuLjA4M2M4OTkzMzkx Nw0KPiA+ID4gLS0tIC9kZXYvbnVsbA0KPiA+ID4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0 cmVlL2JpbmRpbmdzL21lZGlhL21lZGlhdGVrLHZjb2RlYy0NCj4gPiA+IGNvbXAtZGVjb2Rlci55 YW1sDQo+ID4gPiBAQCAtMCwwICsxLDE3MiBAQA0KPiA+ID4gKyMgU1BEWC1MaWNlbnNlLUlkZW50 aWZpZXI6IChHUEwtMi4wLW9ubHkgT1IgQlNELTItQ2xhdXNlKQ0KPiA+ID4gKyVZQU1MIDEuMg0K PiA+ID4gKy0tLQ0KPiA+ID4gKyRpZDogDQo+ID4gPiBodHRwOi8vZGV2aWNldHJlZS5vcmcvc2No ZW1hcy9pb21tdS9tZWRpYXRlayx2Y29kZWMtY29tcC1kZWNvZGVyLnlhbWwjDQo+ID4gPiArJHNj aGVtYTogaHR0cDovL2RldmljZXRyZWUub3JnL21ldGEtc2NoZW1hcy9jb3JlLnlhbWwjDQo+ID4g PiArDQo+ID4gPiArdGl0bGU6IE1lZGlhdGVrIFZpZGVvIERlY29kZSBBY2NlbGVyYXRvciBXaXRo IENvbXBvbmVudA0KPiA+ID4gKw0KPiA+ID4gK21haW50YWluZXJzOg0KPiA+ID4gKyAgLSBZdW5m ZWkgRG9uZyA8eXVuZmVpLmRvbmdAbWVkaWF0ZWsuY29tPg0KPiA+ID4gKw0KPiA+ID4gK2Rlc2Ny aXB0aW9uOiB8Kw0KPiA+ID4gKyAgTWVkaWF0ZWsgVmlkZW8gRGVjb2RlIGlzIHRoZSB2aWRlbyBk ZWNvZGUgaGFyZHdhcmUgcHJlc2VudCBpbg0KPiA+ID4gTWVkaWF0ZWsNCj4gPiA+ICsgIFNvQ3Mg d2hpY2ggc3VwcG9ydHMgaGlnaCByZXNvbHV0aW9uIGRlY29kaW5nIGZ1bmN0aW9uYWxpdGllcy4N Cj4gPiA+IFJlcXVpcmVkDQo+ID4gPiArICBtYXN0ZXIgYW5kIGNvbXBvbmVudCBub2RlLg0KPiA+ IA0KPiA+IFRoaXMgc2hvdWxkIGV4cGxhaW4gaG93IHRoZSB0aHJlZSBJUCBjb3JlcyByZWxhdGUg dG8gZWFjaCBvdGhlci4NCj4gPiANCj4gPiA+ICsNCj4gPiA+ICtwcm9wZXJ0aWVzOg0KPiA+ID4g KyAgY29tcGF0aWJsZToNCj4gPiA+ICsgICAgb25lT2Y6DQo+ID4gPiArICAgICAgLSBlbnVtOg0K PiA+ID4gKyAgICAgICAgICAtIG1lZGlhdGVrLG10ODE5Mi12Y29kZWMtZGVjICAjIGZvciBsYXQg aGFyZHdhcmUNCj4gPiA+ICsgICAgICAgICAgLSBtZWRpYXRlayxtdGstdmNvZGVjLWxhdCAgICAg IyBmb3IgY29yZSBoYXJkd2FyZQ0KPiA+ID4gKyAgICAgICAgICAtIG1lZGlhdGVrLG10ay12Y29k ZWMtY29yZQ0KPiA+ID4gKw0KPiA+ID4gKyAgcmVnOg0KPiA+ID4gKyAgICBtYXhJdGVtczogMQ0K PiA+ID4gKw0KPiA+ID4gKyAgaW50ZXJydXB0czoNCj4gPiA+ICsgICAgbWF4SXRlbXM6IDENCj4g PiA+ICsNCj4gPiA+ICsgIGNsb2NrczoNCj4gPiA+ICsgICAgbWF4SXRlbXM6IDUNCj4gPiA+ICsN Cj4gPiA+ICsgIGNsb2NrLW5hbWVzOg0KPiA+ID4gKyAgICBpdGVtczoNCj4gPiA+ICsgICAgICAt IGNvbnN0OiB2ZGVjLXNlbA0KPiA+ID4gKyAgICAgIC0gY29uc3Q6IHZkZWMtc29jLXZkZWMNCj4g PiA+ICsgICAgICAtIGNvbnN0OiB2ZGVjLXNvYy1sYXQNCj4gPiA+ICsgICAgICAtIGNvbnN0OiB2 ZGVjLXZkZWMNCj4gPiA+ICsgICAgICAtIGNvbnN0OiB2ZGVjLXRvcA0KPiA+ID4gKw0KPiA+ID4g KyAgYXNzaWduZWQtY2xvY2tzOiB0cnVlDQo+ID4gPiArDQo+ID4gPiArICBhc3NpZ25lZC1jbG9j ay1wYXJlbnRzOiB0cnVlDQo+ID4gPiArDQo+ID4gPiArICBwb3dlci1kb21haW5zOg0KPiA+ID4g KyAgICBtYXhJdGVtczogMQ0KPiA+ID4gKw0KPiA+ID4gKyAgaW9tbXVzOg0KPiA+ID4gKyAgICBt aW5JdGVtczogMQ0KPiA+ID4gKyAgICBtYXhJdGVtczogMzINCj4gPiA+ICsgICAgZGVzY3JpcHRp b246IHwNCj4gPiA+ICsgICAgICBMaXN0IG9mIHRoZSBoYXJkd2FyZSBwb3J0IGluIHJlc3BlY3Rp dmUgSU9NTVUgYmxvY2sgZm9yDQo+ID4gPiBjdXJyZW50IFNvY3MuDQo+ID4gPiArICAgICAgUmVm ZXIgdG8gYmluZGluZ3MvaW9tbXUvbWVkaWF0ZWssaW9tbXUueWFtbC4NCj4gPiA+ICsNCj4gPiA+ ICsgIGRtYS1yYW5nZXM6DQo+ID4gPiArICAgIG1heEl0ZW1zOiAxDQo+ID4gPiArICAgIGRlc2Ny aXB0aW9uOiB8DQo+ID4gPiArICAgICAgRGVzY3JpYmVzIHRoZSBwaHlzaWNhbCBhZGRyZXNzIHNw YWNlIG9mIElPTU1VIG1hcHMgdG8NCj4gPiA+IG1lbW9yeS4NCj4gPiA+ICsNCj4gPiA+ICsgIG1l ZGlhdGVrLHNjcDoNCj4gPiA+ICsgICAgJHJlZjogL3NjaGVtYXMvdHlwZXMueWFtbCMvZGVmaW5p dGlvbnMvcGhhbmRsZQ0KPiA+ID4gKyAgICBtYXhJdGVtczogMQ0KPiA+ID4gKyAgICBkZXNjcmlw dGlvbjoNCj4gPiA+ICsgICAgICBEZXNjcmliZXMgcG9pbnQgdG8gc2NwLg0KPiA+ID4gKw0KPiA+ ID4gK3JlcXVpcmVkOg0KPiA+ID4gKyAgICAgIC0gY29tcGF0aWJsZQ0KPiA+ID4gKyAgICAgIC0g cmVnDQo+ID4gPiArICAgICAgLSBpb21tdXMNCj4gPiA+ICsgICAgICAtIGRtYS1yYW5nZXMNCj4g PiA+ICsNCj4gPiA+ICthbGxPZjoNCj4gPiA+ICsgIC0gaWY6ICNtYXN0ZXIgbm9kZQ0KPiA+ID4g KyAgICAgIHByb3BlcnRpZXM6DQo+ID4gPiArICAgICAgICBjb21wYXRpYmxlOg0KPiA+ID4gKyAg ICAgICAgICBjb250YWluczoNCj4gPiA+ICsgICAgICAgICAgICBlbnVtOg0KPiA+ID4gKyAgICAg ICAgICAgICAgLSBtZWRpYXRlayxtdDgxOTItdmNvZGVjLWRlYyAgIyBmb3IgbGF0IGhhcmR3YXJl DQo+ID4gPiArDQo+ID4gPiArICAgIHRoZW46DQo+ID4gPiArICAgICAgcmVxdWlyZWQ6DQo+ID4g PiArICAgICAgICAtIG1lZGlhdGVrLHNjcA0KPiA+ID4gKw0KPiA+ID4gKyAgLSBpZjogI2NvbXBv bmVudCBub2RlDQo+ID4gPiArICAgICAgcHJvcGVydGllczoNCj4gPiA+ICsgICAgICAgIGNvbXBh dGlibGU6DQo+ID4gPiArICAgICAgICAgIGNvbnRhaW5zOg0KPiA+ID4gKyAgICAgICAgICAgIGVu dW06DQo+ID4gPiArICAgICAgICAgICAgICAtIG1lZGlhdGVrLG10ay12Y29kZWMtbGF0ICAgICAj IGZvciBjb3JlIGhhcmR3YXJlDQo+ID4gPiArICAgICAgICAgICAgICAtIG1lZGlhdGVrLG10ay12 Y29kZWMtY29yZQ0KPiA+ID4gKw0KPiA+ID4gKyAgICB0aGVuOg0KPiA+ID4gKyAgICAgIHJlcXVp cmVkOg0KPiA+ID4gKyAgICAgICAgLSBpbnRlcnJ1cHRzDQo+ID4gPiArICAgICAgICAtIGNsb2Nr cw0KPiA+ID4gKyAgICAgICAgLSBjbG9jay1uYW1lcw0KPiA+ID4gKyAgICAgICAgLSBhc3NpZ25l ZC1jbG9ja3MNCj4gPiA+ICsgICAgICAgIC0gYXNzaWduZWQtY2xvY2stcGFyZW50cw0KPiA+ID4g KyAgICAgICAgLSBwb3dlci1kb21haW5zDQo+ID4gPiArDQo+ID4gPiArDQo+ID4gPiArYWRkaXRp b25hbFByb3BlcnRpZXM6IGZhbHNlDQo+ID4gPiArDQo+ID4gPiArZXhhbXBsZXM6DQo+ID4gPiAr ICAtIHwNCj4gPiA+ICsgICAgI2luY2x1ZGUgPGR0LWJpbmRpbmdzL2ludGVycnVwdC1jb250cm9s bGVyL2FybS1naWMuaD4NCj4gPiA+ICsgICAgI2luY2x1ZGUgPGR0LWJpbmRpbmdzL21lbW9yeS9t dDgxOTItbGFyYi1wb3J0Lmg+DQo+ID4gPiArICAgICNpbmNsdWRlIDxkdC1iaW5kaW5ncy9pbnRl cnJ1cHQtY29udHJvbGxlci9pcnEuaD4NCj4gPiA+ICsgICAgI2luY2x1ZGUgPGR0LWJpbmRpbmdz L2Nsb2NrL210ODE5Mi1jbGsuaD4NCj4gPiA+ICsgICAgI2luY2x1ZGUgPGR0LWJpbmRpbmdzL3Bv d2VyL210ODE5Mi1wb3dlci5oPg0KPiA+ID4gKw0KPiA+ID4gKyAgICB2Y29kZWNfZGVjOiB2Y29k ZWNfZGVjQDE2MDAwMDAwIHsNCj4gPiA+ICsgICAgICAgIGNvbXBhdGlibGUgPSAibWVkaWF0ZWss bXQ4MTkyLXZjb2RlYy1kZWMiOw0KPiA+ID4gKyAgICAgICAgcmVnID0gPDAgMHgxNjAwMDAwMCAw IDB4MTAwMD47ICAgICAgICAgICAgICAgLyogVkRFQ19TWVMNCj4gPiA+ICovDQo+ID4gPiArICAg ICAgICBtZWRpYXRlayxzY3AgPSA8JnNjcD47DQo+ID4gPiArICAgICAgICBpb21tdXMgPSA8Jmlv bW11MCBNNFVfUE9SVF9MNF9WREVDX01DX0VYVD47DQo+ID4gPiArICAgICAgICBkbWEtcmFuZ2Vz ID0gPDB4MSAweDAgMHgwIDB4NDAwMDAwMDAgMHgwIDB4ZmZmMDAwMDA+Ow0KPiA+ID4gKyAgICB9 Ow0KPiA+ID4gKw0KPiA+ID4gKyAgICB2Y29kZWNfbGF0OiB2Y29kZWNfbGF0QDB4MTYwMTAwMDAg ew0KPiA+ID4gKyAgICAgICAgY29tcGF0aWJsZSA9ICJtZWRpYXRlayxtdGstdmNvZGVjLWxhdCI7 DQo+ID4gPiArICAgICAgICByZWcgPSA8MCAweDE2MDEwMDAwIDAgMHg4MDA+OyAgICAgICAgICAg ICAgICAvKg0KPiA+ID4gVkRFQ19NSVNDICovDQo+ID4gPiArICAgICAgICBpbnRlcnJ1cHRzID0g PEdJQ19TUEkgNDI2IElSUV9UWVBFX0xFVkVMX0hJR0ggMD47DQo+ID4gPiArICAgICAgICBpb21t dXMgPSA8JmlvbW11MCBNNFVfUE9SVF9MNV9WREVDX0xBVDBfVkxEX0VYVD4sDQo+ID4gPiArICAg ICAgICAgICAgIDwmaW9tbXUwIE00VV9QT1JUX0w1X1ZERUNfTEFUMF9WTEQyX0VYVD4sDQo+ID4g PiArICAgICAgICAgICAgIDwmaW9tbXUwIE00VV9QT1JUX0w1X1ZERUNfTEFUMF9BVkNfTVZfRVhU PiwNCj4gPiA+ICsgICAgICAgICAgICAgPCZpb21tdTAgTTRVX1BPUlRfTDVfVkRFQ19MQVQwX1BS RURfUkRfRVhUPiwNCj4gPiA+ICsgICAgICAgICAgICAgPCZpb21tdTAgTTRVX1BPUlRfTDVfVkRF Q19MQVQwX1RJTEVfRVhUPiwNCj4gPiA+ICsgICAgICAgICAgICAgPCZpb21tdTAgTTRVX1BPUlRf TDVfVkRFQ19MQVQwX1dETUFfRVhUPiwNCj4gPiA+ICsgICAgICAgICAgICAgPCZpb21tdTAgTTRV X1BPUlRfTDVfVkRFQ19MQVQwX1JHX0NUUkxfRE1BX0VYVD4sDQo+ID4gPiArICAgICAgICAgICAg IDwmaW9tbXUwIE00VV9QT1JUX0w1X1ZERUNfVUZPX0VOQ19FWFQ+Ow0KPiA+ID4gKyAgICAgICAg ZG1hLXJhbmdlcyA9IDwweDEgMHgwIDB4MCAweDQwMDAwMDAwIDB4MCAweGZmZjAwMDAwPjsNCj4g PiA+ICsgICAgICAgIGNsb2NrcyA9IDwmdG9wY2tnZW4gQ0xLX1RPUF9WREVDX1NFTD4sDQo+ID4g PiArICAgICAgICAgICAgIDwmdmRlY3N5c19zb2MgQ0xLX1ZERUNfU09DX1ZERUM+LA0KPiA+ID4g KyAgICAgICAgICAgICA8JnZkZWNzeXNfc29jIENMS19WREVDX1NPQ19MQVQ+LA0KPiA+ID4gKyAg ICAgICAgICAgICA8JnZkZWNzeXNfc29jIENMS19WREVDX1NPQ19MQVJCMT4sDQo+ID4gPiArICAg ICAgICAgICAgIDwmdG9wY2tnZW4gQ0xLX1RPUF9NQUlOUExMX0Q0PjsNCj4gPiA+ICsgICAgICAg IGNsb2NrLW5hbWVzID0gInZkZWMtc2VsIiwgInZkZWMtc29jLXZkZWMiLCAidmRlYy1zb2MtDQo+ ID4gPiBsYXQiLA0KPiA+ID4gKyAgICAgICAgICAgICAgInZkZWMtdmRlYyIsICJ2ZGVjLXRvcCI7 DQo+ID4gPiArICAgICAgICBhc3NpZ25lZC1jbG9ja3MgPSA8JnRvcGNrZ2VuIENMS19UT1BfVkRF Q19TRUw+Ow0KPiA+ID4gKyAgICAgICAgYXNzaWduZWQtY2xvY2stcGFyZW50cyA9IDwmdG9wY2tn ZW4gQ0xLX1RPUF9NQUlOUExMX0Q0PjsNCj4gPiA+ICsgICAgICAgIHBvd2VyLWRvbWFpbnMgPSA8 JnNwbSBNVDgxOTJfUE9XRVJfRE9NQUlOX1ZERUM+Ow0KPiA+ID4gKyAgICB9Ow0KPiA+ID4gKw0K PiA+ID4gKyAgICB2Y29kZWNfY29yZTogdmNvZGVjX2NvcmVAMHgxNjAyNTAwMCB7DQo+ID4gPiAr ICAgICAgICBjb21wYXRpYmxlID0gIm1lZGlhdGVrLG10ay12Y29kZWMtY29yZSI7DQo+ID4gPiAr ICAgICAgICByZWcgPSA8MCAweDE2MDI1MDAwIDAgMHgxMDAwPjsgICAgICAgICAgICAgICAvKg0K PiA+ID4gVkRFQ19DT1JFX01JU0MgKi8NCj4gPiA+ICsgICAgICAgIGludGVycnVwdHMgPSA8R0lD X1NQSSA0MjUgSVJRX1RZUEVfTEVWRUxfSElHSCAwPjsNCj4gPiA+ICsgICAgICAgIGlvbW11cyA9 IDwmaW9tbXUwIE00VV9QT1JUX0w0X1ZERUNfTUNfRVhUPiwNCj4gPiA+ICsgICAgICAgICAgICAg PCZpb21tdTAgTTRVX1BPUlRfTDRfVkRFQ19VRk9fRVhUPiwNCj4gPiA+ICsgICAgICAgICAgICAg PCZpb21tdTAgTTRVX1BPUlRfTDRfVkRFQ19QUF9FWFQ+LA0KPiA+ID4gKyAgICAgICAgICAgICA8 JmlvbW11MCBNNFVfUE9SVF9MNF9WREVDX1BSRURfUkRfRVhUPiwNCj4gPiA+ICsgICAgICAgICAg ICAgPCZpb21tdTAgTTRVX1BPUlRfTDRfVkRFQ19QUkVEX1dSX0VYVD4sDQo+ID4gPiArICAgICAg ICAgICAgIDwmaW9tbXUwIE00VV9QT1JUX0w0X1ZERUNfUFBXUkFQX0VYVD4sDQo+ID4gPiArICAg ICAgICAgICAgIDwmaW9tbXUwIE00VV9QT1JUX0w0X1ZERUNfVElMRV9FWFQ+LA0KPiA+ID4gKyAg ICAgICAgICAgICA8JmlvbW11MCBNNFVfUE9SVF9MNF9WREVDX1ZMRF9FWFQ+LA0KPiA+ID4gKyAg ICAgICAgICAgICA8JmlvbW11MCBNNFVfUE9SVF9MNF9WREVDX1ZMRDJfRVhUPiwNCj4gPiA+ICsg ICAgICAgICAgICAgPCZpb21tdTAgTTRVX1BPUlRfTDRfVkRFQ19BVkNfTVZfRVhUPiwNCj4gPiA+ ICsgICAgICAgICAgICAgPCZpb21tdTAgTTRVX1BPUlRfTDRfVkRFQ19SR19DVFJMX0RNQV9FWFQ+ Ow0KPiA+ID4gKyAgICAgICAgZG1hLXJhbmdlcyA9IDwweDEgMHgwIDB4MCAweDQwMDAwMDAwIDB4 MCAweGZmZjAwMDAwPjsNCj4gPiA+ICsgICAgICAgIGNsb2NrcyA9IDwmdG9wY2tnZW4gQ0xLX1RP UF9WREVDX1NFTD4sDQo+ID4gPiArICAgICAgICAgICAgIDwmdmRlY3N5cyBDTEtfVkRFQ19WREVD PiwNCj4gPiA+ICsgICAgICAgICAgICAgPCZ2ZGVjc3lzIENMS19WREVDX0xBVD4sDQo+ID4gPiAr ICAgICAgICAgICAgIDwmdmRlY3N5cyBDTEtfVkRFQ19MQVJCMT4sDQo+ID4gPiArICAgICAgICAg ICAgIDwmdG9wY2tnZW4gQ0xLX1RPUF9NQUlOUExMX0Q0PjsNCj4gPiA+ICsgICAgICAgIGNsb2Nr LW5hbWVzID0gInZkZWMtc2VsIiwgInZkZWMtc29jLXZkZWMiLCAidmRlYy1zb2MtDQo+ID4gPiBs YXQiLA0KPiA+ID4gKyAgICAgICAgICAgICAgInZkZWMtdmRlYyIsICJ2ZGVjLXRvcCI7DQo+ID4g PiArICAgICAgICBhc3NpZ25lZC1jbG9ja3MgPSA8JnRvcGNrZ2VuIENMS19UT1BfVkRFQ19TRUw+ Ow0KPiA+ID4gKyAgICAgICAgYXNzaWduZWQtY2xvY2stcGFyZW50cyA9IDwmdG9wY2tnZW4gQ0xL X1RPUF9NQUlOUExMX0Q0PjsNCj4gPiA+ICsgICAgICAgIHBvd2VyLWRvbWFpbnMgPSA8JnNwbSBN VDgxOTJfUE9XRVJfRE9NQUlOX1ZERUMyPjsNCj4gPiA+ICsgICAgfTsNCj4gPiANCj4gPiBJJ20g YSBiaXQgbGF0ZSBpbiB0aGUgZ2FtZSwgcmV2aWV3aW5nIHY1IG9ubHksIGJ1dCBJJ20gd29uZGVy aW5nIGlmDQo+ID4gdGhvc2UgSVAgY29yZXMgbmVlZCB0byBiZSBtb2RlbGxlZCBpbiBzZXBhcmF0 ZSBub2Rlcy4gSXQgd291bGQgYmUNCj4gPiBtdWNoDQo+ID4gZWFzaWVyLCBmcm9tIGEgc29mdHdh cmUgcG9pbnQgb2YgdmlldywgdG8gaGF2ZSBhIHNpbmdsZSBub2RlLCB3aXRoDQo+ID4gbXVsdGlw bGUgcmVnaXN0ZXIgcmFuZ2VzLg0KPiA+IA0KPiA+IEFyZSBzb21lIG9mIHRob3NlIElQIGNvcmVz IHVzZWQgaW4gZGlmZmVyZW50IFNvQ3MsIGNvbWJpbmVkIGluDQo+ID4gZGlmZmVyZW50DQo+ID4g d2F5cywgdGhhdCBtYWtlIGEgbW9kdWxhciBkZXNpZ24gYmV0dGVyID8NCj4gPiANCj4gDQoxLiBF YWNoIGEgbm9kZSBzaG91bGQgcmVzcGVjdCBhIEhXIG5vZGUuIERlZmluaW5nIGEgY29tcGxleCBu b2RlIHRoYXQNCmNvbnRhaW4gbXVsdGlwbGUgcmVnaXN0ZXIgaXMgbm90IGJldHRlciwgZm9yIHRo ZXkgYmVsb25nIHRvIGRpZmZlcmVudA0KaGFyZHdhcmUuIERpZmZlcmVudCBwbGF0Zm9ybXMgaGFz IGRpZmZlcmVudCBoYXJkd2FyZSBjb3VudCwgbXQ4MTk1IGhhcw0KZml2ZSBoYXJkd2FyZXMuDQoy LiBBbm90aGVyIHJlYXNvbiBpcyBmcm9tIHRoZSBJT01NVSBwb2ludCwgdGhlIHZjb2RlYyBIVyBp bmNsdWRlIGNvcmUNCmFuZCBsYXQgaGFyZHdhcmVzLCBlYWNoIG9mIHRoZW0gY29ubmVjdCB0byB0 aGUgaW5kZXBlbmRlbnQgSU9NTVUNCmhhcmR3YXJlIGZvciBtdDgxOTUsIGNhbid0IHdyaXRlIGFs bCBpb21tdSBwb3J0cyB0b2dldGhlciwgb3IgaGFyZHdhcmUNCmNhbid0IGFjY2VzcyBkcmFtIGRh dGEsIHNvIHdlIG11c3Qgc2VwYXJhdGUgdGhlbS4NCj4gWWVhaCwgSSBhZ3JlZSB3aXRoIExhdXJl bnQgaGVyZS4gVGhpcyB3YXkgb2YgbW9kZWxsaW5nIHRoZSBkaWZmZXJlbnQNCj4gcGFydHMNCj4g b2YgdGhlIENPREVDIGFzIGRpZmZlcmVudCBwaWVjZXMgaXMgdGhlIHJlYXNvbiB3aHkgeW91IG5l ZWQgYQ0KPiBmcmFtZXdvcmsNCj4gdG8gcHVsbCB0aGVtIHRvZ2V0aGVyLCBzdWNoIGFzIHRoZSBj b21wb25lbnQgQVBJIChJIGd1ZXNzIHY0bDItYXN5bmMNCj4gY291bGQgaGF2ZSBiZWVuIHVzZWQg YXMgd2VsbCkuDQo+IA0KV2UgbXVzdCBzZXBhcmF0ZSBlYWNoIGhhcmR3YXJlIG5vZGUsIG9ubHkg bWFzdGVyIG5lZWQgdG8gcmVnaXN0ZXIgdmlkZW8NCmFuZCBtZWRpYSBkZXZpY2UsIGNvbXBvbmVu dCBqdXN0IHVzZWQgZm9yIHN0b3JlIGNsay9wb3dlci9pcnEvcmVnaXN0ZXINCmluZm9ybWF0aW9u IGZvciBjdXJyZW50IGhhcmR3YXJlLg0KPiBJIG5vcm1hbGx5IGRvbid0IGJvdGhlciB3aXRoIGRy aXZlciBpbnRlcm5hbHMsIGFzIGl0cyB1cCB0byBlYWNoDQo+IGRyaXZlcg0KPiBhdXRob3IgdG8g ZGVjaWRlIHdoYXQgaXMgYmVzdC4gSG93ZXZlciwgSSBiZWxpZXZlIHRoaXMgZGVzaWduIGlzIHRv bw0KPiBjb252b2x1dGVkLCBhbmQgaXQgbWF5IGxlYWQgb3RoZXIgZGV2ZWxvcGVycyB0byBmb2xs b3cgdGhlIHNhbWUNCj4gcGF0dGVybiwNCj4gc28gcGxlYXNlIGF2b2lkIGl0Lg0KPiANCkFjY29y ZGluZyB0byB5b3VyIGluZm9ybWF0aW9uLCBpdCBsb29rcyB0aGF0IGNvbXBvbmVudCBhbmQgdjRs MiBhc3luYw0KYXJlIG9rIGZvciB0aGlzIGFyY2hpdGVjdHVyZSwgb25seSBjb21wb25lbnQgaXMg dG9vIGNvbnZvbHV0ZWQoaW9tbXUNCmRyaXZlciBhbHNvIHVzZSBjb21wb25lbnQpLg0KDQpGb3Ig d2UgYXJlIG5vdCB2ZXJ5IGZhbWlsaWFyIHdpdGggdjRsMiBhc3luYywgb3V0IGFyY2hpdGVjdHVy ZSBpcw0KZGVzaWduZWQgZm9yIGNvbXBvbmVudCBpbmNsdWRlIG5leHQgZm9ydHkgcGF0Y2hlcy4g SXQgaXMgYSB2ZXJ5IGJpZw0KY2hhbmdlIGZvciBvdXQgZHJpdmVyLiBJIHdpbGwgdHJ5IHRvIHNw ZW5kIGEgbG90IG9mIHRpbWUgdG8gY2hhbmdlIGl0Lg0KDQo+IFRoZXJlIGFyZSBzZXZlcmFsIHdh eXMgb2YgbW9kZWxsaW5nIHRoaXMgYW5kIGluaXRpYWxpemluZyBvciBwcm9iaW5nDQo+IHRoZSBz dWItZGV2aWNlcywNCj4gd2l0aG91dCB1c2luZyBhbnkgYXN5bmMgZnJhbWV3b3JrLg0KPiANCllv dSBtYXkgbWlzdW5kZXJzdGFuZCwgSSdtIG5vdCBvYmplY3RpbmcgeW91ciBzdWdnZXN0aW9uIGV2 ZXJ5IHRpbWUsDQpmb3Igb3VyIGRyaXZlciBpcyBkZXNpZ25lZCBmb3IgY29tcG9uZW50IGFwaSwg bmVlZCB0byBzcGVuZCBhIGxvdCBvZg0KdGltZSB0byBjaGFuZ2UgaXQgaW4gbWFueSBwbGF0Zm9y bXMuIEkgd2lsbCBjaGFuZ2UgaXQgaWYgdjRsMiBhc3luYyBoYXMNCm1hbnkgYWR2YW50YWdlcyB0 aGVuIGNvbXBvbmVudCBhcyB5b3Ugc2FpZC4gSSB3aWxsIHRyeSB0byB1c2UgdjRsMg0KYXN5bmMg YXMgY29tcGFyZWQuDQoNCj4gVGhhbmtzLA0KPiBFemVxdWllbA0KDQpUaGFua3MgZm9yIHlvdXIg c3VnZ2VzdGlvbi4NCll1bmZlaSBEb25nDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A145BC432BE for ; Mon, 30 Aug 2021 06:08:17 +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 50E6E60FA0 for ; Mon, 30 Aug 2021 06:08:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 50E6E60FA0 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=08bHExllQi7j7dDmERYDn+sMRPEXEQXnv8020I2k5a4=; b=ddLPP2xnTxZXMW wSRXSxBkqqkuKUxzs9VtSSK5vOgriqPF85yQKi3+yDLmqroHiywWj75NRQL9b6qXcVX7ZTxHeB16h aTwU5kGXY07pi0wfjMahu0TC7IMDPLVtvCtEUW8fTaZzqCwKeipoYUumkjPpLPS0cIbEleOBZ6pxI jxP3ROJFYlIfNwCO4mhwdbWfO6G7wMBIUqBaf2HrzIYa/fRJhKmOUiOW5t9N4lQiz4n8Yx/L+WZhW GOJPom/H+AmYeS9noXMbs40w+oZ47Ev4NBhl0eSzga6G17hWo7O0ufPstgLcsgR4Nal6HKd9gaBSh r3CL5eViG8G3AmKdyUWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKaSd-00GW4w-F7; Mon, 30 Aug 2021 06:07:59 +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 1mKaSY-00GW3V-Li; Mon, 30 Aug 2021 06:07:58 +0000 X-UUID: 592126a46f92421f94d1bdbcc5e8b0ca-20210829 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=yumP0/IwY8D7km3Voc8rlArhIG+mQ1XqIA8K80OLgb0=; b=S01r2tIKTAHpWK6hkfm5NZW2U8nNz+DUgUAaErgDWlNTG+YwLoF11C0QPBMMpvnrpmP7mbe8TlQxVPno8QavpBtzHYv5Aifa95po02jNHfz+ZKLmybQjV7zGylq4OUe1ZzdnGyY14iXbKV22dvn7eWOm2WeBzpdaKxiiXagI7Ac=; X-UUID: 592126a46f92421f94d1bdbcc5e8b0ca-20210829 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 673780781; Sun, 29 Aug 2021 23:07:47 -0700 Received: from MTKMBS07N2.mediatek.inc (172.21.101.141) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 29 Aug 2021 23:07:45 -0700 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Aug 2021 14:07:44 +0800 Received: from mhfsdcap04 (10.17.3.154) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 30 Aug 2021 14:07:43 +0800 Message-ID: <885db6cd26907939511ff132c0fa3ad122c0e588.camel@mediatek.com> Subject: Re: [PATCH v5, 13/15] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192 From: "yunfei.dong@mediatek.com" To: Ezequiel Garcia , Laurent Pinchart CC: Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , "Tiffany Lin" , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , Hsin-Yi Wang , "Fritz Koenig" , Irui Wang , linux-media , devicetree , Linux Kernel Mailing List , linux-arm-kernel , srv_heupstream , "moderated list:ARM/Mediatek SoC support" , Project_Global_Chrome_Upstream_Group , George Sun Date: Mon, 30 Aug 2021 14:07:44 +0800 In-Reply-To: References: <20210811025801.21597-1-yunfei.dong@mediatek.com> <20210811025801.21597-14-yunfei.dong@mediatek.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210829_230754_750109_10D38D79 X-CRM114-Status: GOOD ( 34.80 ) 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 Sun, 2021-08-29 at 17:50 -0300, Ezequiel Garcia wrote: > On Wed, 11 Aug 2021 at 14:59, Laurent Pinchart > wrote: > > > > Hi Yunfei, > > > > Thank you for the patch. > > > > On Wed, Aug 11, 2021 at 10:57:59AM +0800, Yunfei Dong wrote: > > > Adds decoder dt-bindings for mt8192. > > > > > > Signed-off-by: Yunfei Dong > > > --- > > > v5: no changes > > > > > > This patch depends on "Mediatek MT8192 clock support"[1]. > > > > > > The definition of decoder clocks are in mt8192-clk.h, need to > > > include them in case of build fail [1]. > > > > > > [1] > > > https://patchwork.kernel.org/project/linux-mediatek/list/?series=511175 > > > --- > > > .../media/mediatek,vcodec-comp-decoder.yaml | 172 > > > ++++++++++++++++++ > > > 1 file changed, 172 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/media/mediatek,vcodec-comp- > > > decoder.yaml > > > > > > diff --git > > > a/Documentation/devicetree/bindings/media/mediatek,vcodec-comp- > > > decoder.yaml > > > b/Documentation/devicetree/bindings/media/mediatek,vcodec-comp- > > > decoder.yaml > > > new file mode 100644 > > > index 000000000000..083c89933917 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec- > > > comp-decoder.yaml > > > @@ -0,0 +1,172 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: > > > http://devicetree.org/schemas/iommu/mediatek,vcodec-comp-decoder.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Mediatek Video Decode Accelerator With Component > > > + > > > +maintainers: > > > + - Yunfei Dong > > > + > > > +description: |+ > > > + Mediatek Video Decode is the video decode hardware present in > > > Mediatek > > > + SoCs which supports high resolution decoding functionalities. > > > Required > > > + master and component node. > > > > This should explain how the three IP cores relate to each other. > > > > > + > > > +properties: > > > + compatible: > > > + oneOf: > > > + - enum: > > > + - mediatek,mt8192-vcodec-dec # for lat hardware > > > + - mediatek,mtk-vcodec-lat # for core hardware > > > + - mediatek,mtk-vcodec-core > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + interrupts: > > > + maxItems: 1 > > > + > > > + clocks: > > > + maxItems: 5 > > > + > > > + clock-names: > > > + items: > > > + - const: vdec-sel > > > + - const: vdec-soc-vdec > > > + - const: vdec-soc-lat > > > + - const: vdec-vdec > > > + - const: vdec-top > > > + > > > + assigned-clocks: true > > > + > > > + assigned-clock-parents: true > > > + > > > + power-domains: > > > + maxItems: 1 > > > + > > > + iommus: > > > + minItems: 1 > > > + maxItems: 32 > > > + description: | > > > + List of the hardware port in respective IOMMU block for > > > current Socs. > > > + Refer to bindings/iommu/mediatek,iommu.yaml. > > > + > > > + dma-ranges: > > > + maxItems: 1 > > > + description: | > > > + Describes the physical address space of IOMMU maps to > > > memory. > > > + > > > + mediatek,scp: > > > + $ref: /schemas/types.yaml#/definitions/phandle > > > + maxItems: 1 > > > + description: > > > + Describes point to scp. > > > + > > > +required: > > > + - compatible > > > + - reg > > > + - iommus > > > + - dma-ranges > > > + > > > +allOf: > > > + - if: #master node > > > + properties: > > > + compatible: > > > + contains: > > > + enum: > > > + - mediatek,mt8192-vcodec-dec # for lat hardware > > > + > > > + then: > > > + required: > > > + - mediatek,scp > > > + > > > + - if: #component node > > > + properties: > > > + compatible: > > > + contains: > > > + enum: > > > + - mediatek,mtk-vcodec-lat # for core hardware > > > + - mediatek,mtk-vcodec-core > > > + > > > + then: > > > + required: > > > + - interrupts > > > + - clocks > > > + - clock-names > > > + - assigned-clocks > > > + - assigned-clock-parents > > > + - power-domains > > > + > > > + > > > +additionalProperties: false > > > + > > > +examples: > > > + - | > > > + #include > > > + #include > > > + #include > > > + #include > > > + #include > > > + > > > + vcodec_dec: vcodec_dec@16000000 { > > > + compatible = "mediatek,mt8192-vcodec-dec"; > > > + reg = <0 0x16000000 0 0x1000>; /* VDEC_SYS > > > */ > > > + mediatek,scp = <&scp>; > > > + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; > > > + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > > + }; > > > + > > > + vcodec_lat: vcodec_lat@0x16010000 { > > > + compatible = "mediatek,mtk-vcodec-lat"; > > > + reg = <0 0x16010000 0 0x800>; /* > > > VDEC_MISC */ > > > + interrupts = ; > > > + iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>; > > > + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > > + clocks = <&topckgen CLK_TOP_VDEC_SEL>, > > > + <&vdecsys_soc CLK_VDEC_SOC_VDEC>, > > > + <&vdecsys_soc CLK_VDEC_SOC_LAT>, > > > + <&vdecsys_soc CLK_VDEC_SOC_LARB1>, > > > + <&topckgen CLK_TOP_MAINPLL_D4>; > > > + clock-names = "vdec-sel", "vdec-soc-vdec", "vdec-soc- > > > lat", > > > + "vdec-vdec", "vdec-top"; > > > + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; > > > + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; > > > + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; > > > + }; > > > + > > > + vcodec_core: vcodec_core@0x16025000 { > > > + compatible = "mediatek,mtk-vcodec-core"; > > > + reg = <0 0x16025000 0 0x1000>; /* > > > VDEC_CORE_MISC */ > > > + interrupts = ; > > > + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_UFO_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_PP_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_PRED_RD_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_PRED_WR_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_PPWRAP_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_TILE_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_VLD_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_VLD2_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_AVC_MV_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>; > > > + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > > + clocks = <&topckgen CLK_TOP_VDEC_SEL>, > > > + <&vdecsys CLK_VDEC_VDEC>, > > > + <&vdecsys CLK_VDEC_LAT>, > > > + <&vdecsys CLK_VDEC_LARB1>, > > > + <&topckgen CLK_TOP_MAINPLL_D4>; > > > + clock-names = "vdec-sel", "vdec-soc-vdec", "vdec-soc- > > > lat", > > > + "vdec-vdec", "vdec-top"; > > > + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; > > > + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; > > > + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC2>; > > > + }; > > > > I'm a bit late in the game, reviewing v5 only, but I'm wondering if > > those IP cores need to be modelled in separate nodes. It would be > > much > > easier, from a software point of view, to have a single node, with > > multiple register ranges. > > > > Are some of those IP cores used in different SoCs, combined in > > different > > ways, that make a modular design better ? > > > 1. Each a node should respect a HW node. Defining a complex node that contain multiple register is not better, for they belong to different hardware. Different platforms has different hardware count, mt8195 has five hardwares. 2. Another reason is from the IOMMU point, the vcodec HW include core and lat hardwares, each of them connect to the independent IOMMU hardware for mt8195, can't write all iommu ports together, or hardware can't access dram data, so we must separate them. > Yeah, I agree with Laurent here. This way of modelling the different > parts > of the CODEC as different pieces is the reason why you need a > framework > to pull them together, such as the component API (I guess v4l2-async > could have been used as well). > We must separate each hardware node, only master need to register video and media device, component just used for store clk/power/irq/register information for current hardware. > I normally don't bother with driver internals, as its up to each > driver > author to decide what is best. However, I believe this design is too > convoluted, and it may lead other developers to follow the same > pattern, > so please avoid it. > According to your information, it looks that component and v4l2 async are ok for this architecture, only component is too convoluted(iommu driver also use component). For we are not very familiar with v4l2 async, out architecture is designed for component include next forty patches. It is a very big change for out driver. I will try to spend a lot of time to change it. > There are several ways of modelling this and initializing or probing > the sub-devices, > without using any async framework. > You may misunderstand, I'm not objecting your suggestion every time, for our driver is designed for component api, need to spend a lot of time to change it in many platforms. I will change it if v4l2 async has many advantages then component as you said. I will try to use v4l2 async as compared. > Thanks, > Ezequiel Thanks for your suggestion. Yunfei Dong _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C632C432BE for ; Mon, 30 Aug 2021 06:10:56 +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 DC98660F9E for ; Mon, 30 Aug 2021 06:10:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DC98660F9E 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=rt/eTAdYz0T0R+AUOjmSr4oUxocrDxwJoVfxZTSzJbQ=; b=gehXjas6JgGE5q CLBgGYpv+mzwQv/yHC2xvn9fpGStL/Ab+CM5ZaE4/IgbdPDpYKWPSESP2YBFEpy4WDBwFtB46cMNx hup0+tZ4qpMtcDr2KMN66+R4cVp+xlUmG6ELy+T/wdRRGKy5jVvRYJ9TwcQYXKkZa4V0jXz72i8fR EnlaLejqHRKm9KLDHduAffjjjj8fQI1t/t7jcF0edP5oBIqahsTq9d6FjovCbckk0QGiESXN2fqR0 HVqJXSw+2LJmKCZ7BoWc/cr+yIJmkbBbPHMsD1cHvYmLcegkU/z5acTSKGn5VNrVVOxuu52EBgtAb Lg9wWtocgK8EWQMUXcdA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKaSf-00GW52-8z; Mon, 30 Aug 2021 06:08:01 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mKaSY-00GW3V-Li; Mon, 30 Aug 2021 06:07:58 +0000 X-UUID: 592126a46f92421f94d1bdbcc5e8b0ca-20210829 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=yumP0/IwY8D7km3Voc8rlArhIG+mQ1XqIA8K80OLgb0=; b=S01r2tIKTAHpWK6hkfm5NZW2U8nNz+DUgUAaErgDWlNTG+YwLoF11C0QPBMMpvnrpmP7mbe8TlQxVPno8QavpBtzHYv5Aifa95po02jNHfz+ZKLmybQjV7zGylq4OUe1ZzdnGyY14iXbKV22dvn7eWOm2WeBzpdaKxiiXagI7Ac=; X-UUID: 592126a46f92421f94d1bdbcc5e8b0ca-20210829 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 673780781; Sun, 29 Aug 2021 23:07:47 -0700 Received: from MTKMBS07N2.mediatek.inc (172.21.101.141) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 29 Aug 2021 23:07:45 -0700 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Aug 2021 14:07:44 +0800 Received: from mhfsdcap04 (10.17.3.154) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 30 Aug 2021 14:07:43 +0800 Message-ID: <885db6cd26907939511ff132c0fa3ad122c0e588.camel@mediatek.com> Subject: Re: [PATCH v5, 13/15] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192 From: "yunfei.dong@mediatek.com" To: Ezequiel Garcia , Laurent Pinchart CC: Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , "Tiffany Lin" , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , Hsin-Yi Wang , "Fritz Koenig" , Irui Wang , linux-media , devicetree , Linux Kernel Mailing List , linux-arm-kernel , srv_heupstream , "moderated list:ARM/Mediatek SoC support" , Project_Global_Chrome_Upstream_Group , George Sun Date: Mon, 30 Aug 2021 14:07:44 +0800 In-Reply-To: References: <20210811025801.21597-1-yunfei.dong@mediatek.com> <20210811025801.21597-14-yunfei.dong@mediatek.com> X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210829_230754_750109_10D38D79 X-CRM114-Status: GOOD ( 34.80 ) 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 Sun, 2021-08-29 at 17:50 -0300, Ezequiel Garcia wrote: > On Wed, 11 Aug 2021 at 14:59, Laurent Pinchart > wrote: > > > > Hi Yunfei, > > > > Thank you for the patch. > > > > On Wed, Aug 11, 2021 at 10:57:59AM +0800, Yunfei Dong wrote: > > > Adds decoder dt-bindings for mt8192. > > > > > > Signed-off-by: Yunfei Dong > > > --- > > > v5: no changes > > > > > > This patch depends on "Mediatek MT8192 clock support"[1]. > > > > > > The definition of decoder clocks are in mt8192-clk.h, need to > > > include them in case of build fail [1]. > > > > > > [1] > > > https://patchwork.kernel.org/project/linux-mediatek/list/?series=511175 > > > --- > > > .../media/mediatek,vcodec-comp-decoder.yaml | 172 > > > ++++++++++++++++++ > > > 1 file changed, 172 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/media/mediatek,vcodec-comp- > > > decoder.yaml > > > > > > diff --git > > > a/Documentation/devicetree/bindings/media/mediatek,vcodec-comp- > > > decoder.yaml > > > b/Documentation/devicetree/bindings/media/mediatek,vcodec-comp- > > > decoder.yaml > > > new file mode 100644 > > > index 000000000000..083c89933917 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec- > > > comp-decoder.yaml > > > @@ -0,0 +1,172 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: > > > http://devicetree.org/schemas/iommu/mediatek,vcodec-comp-decoder.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Mediatek Video Decode Accelerator With Component > > > + > > > +maintainers: > > > + - Yunfei Dong > > > + > > > +description: |+ > > > + Mediatek Video Decode is the video decode hardware present in > > > Mediatek > > > + SoCs which supports high resolution decoding functionalities. > > > Required > > > + master and component node. > > > > This should explain how the three IP cores relate to each other. > > > > > + > > > +properties: > > > + compatible: > > > + oneOf: > > > + - enum: > > > + - mediatek,mt8192-vcodec-dec # for lat hardware > > > + - mediatek,mtk-vcodec-lat # for core hardware > > > + - mediatek,mtk-vcodec-core > > > + > > > + reg: > > > + maxItems: 1 > > > + > > > + interrupts: > > > + maxItems: 1 > > > + > > > + clocks: > > > + maxItems: 5 > > > + > > > + clock-names: > > > + items: > > > + - const: vdec-sel > > > + - const: vdec-soc-vdec > > > + - const: vdec-soc-lat > > > + - const: vdec-vdec > > > + - const: vdec-top > > > + > > > + assigned-clocks: true > > > + > > > + assigned-clock-parents: true > > > + > > > + power-domains: > > > + maxItems: 1 > > > + > > > + iommus: > > > + minItems: 1 > > > + maxItems: 32 > > > + description: | > > > + List of the hardware port in respective IOMMU block for > > > current Socs. > > > + Refer to bindings/iommu/mediatek,iommu.yaml. > > > + > > > + dma-ranges: > > > + maxItems: 1 > > > + description: | > > > + Describes the physical address space of IOMMU maps to > > > memory. > > > + > > > + mediatek,scp: > > > + $ref: /schemas/types.yaml#/definitions/phandle > > > + maxItems: 1 > > > + description: > > > + Describes point to scp. > > > + > > > +required: > > > + - compatible > > > + - reg > > > + - iommus > > > + - dma-ranges > > > + > > > +allOf: > > > + - if: #master node > > > + properties: > > > + compatible: > > > + contains: > > > + enum: > > > + - mediatek,mt8192-vcodec-dec # for lat hardware > > > + > > > + then: > > > + required: > > > + - mediatek,scp > > > + > > > + - if: #component node > > > + properties: > > > + compatible: > > > + contains: > > > + enum: > > > + - mediatek,mtk-vcodec-lat # for core hardware > > > + - mediatek,mtk-vcodec-core > > > + > > > + then: > > > + required: > > > + - interrupts > > > + - clocks > > > + - clock-names > > > + - assigned-clocks > > > + - assigned-clock-parents > > > + - power-domains > > > + > > > + > > > +additionalProperties: false > > > + > > > +examples: > > > + - | > > > + #include > > > + #include > > > + #include > > > + #include > > > + #include > > > + > > > + vcodec_dec: vcodec_dec@16000000 { > > > + compatible = "mediatek,mt8192-vcodec-dec"; > > > + reg = <0 0x16000000 0 0x1000>; /* VDEC_SYS > > > */ > > > + mediatek,scp = <&scp>; > > > + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; > > > + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > > + }; > > > + > > > + vcodec_lat: vcodec_lat@0x16010000 { > > > + compatible = "mediatek,mtk-vcodec-lat"; > > > + reg = <0 0x16010000 0 0x800>; /* > > > VDEC_MISC */ > > > + interrupts = ; > > > + iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>, > > > + <&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>; > > > + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > > + clocks = <&topckgen CLK_TOP_VDEC_SEL>, > > > + <&vdecsys_soc CLK_VDEC_SOC_VDEC>, > > > + <&vdecsys_soc CLK_VDEC_SOC_LAT>, > > > + <&vdecsys_soc CLK_VDEC_SOC_LARB1>, > > > + <&topckgen CLK_TOP_MAINPLL_D4>; > > > + clock-names = "vdec-sel", "vdec-soc-vdec", "vdec-soc- > > > lat", > > > + "vdec-vdec", "vdec-top"; > > > + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; > > > + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; > > > + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; > > > + }; > > > + > > > + vcodec_core: vcodec_core@0x16025000 { > > > + compatible = "mediatek,mtk-vcodec-core"; > > > + reg = <0 0x16025000 0 0x1000>; /* > > > VDEC_CORE_MISC */ > > > + interrupts = ; > > > + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_UFO_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_PP_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_PRED_RD_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_PRED_WR_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_PPWRAP_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_TILE_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_VLD_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_VLD2_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_AVC_MV_EXT>, > > > + <&iommu0 M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>; > > > + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > > + clocks = <&topckgen CLK_TOP_VDEC_SEL>, > > > + <&vdecsys CLK_VDEC_VDEC>, > > > + <&vdecsys CLK_VDEC_LAT>, > > > + <&vdecsys CLK_VDEC_LARB1>, > > > + <&topckgen CLK_TOP_MAINPLL_D4>; > > > + clock-names = "vdec-sel", "vdec-soc-vdec", "vdec-soc- > > > lat", > > > + "vdec-vdec", "vdec-top"; > > > + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; > > > + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; > > > + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC2>; > > > + }; > > > > I'm a bit late in the game, reviewing v5 only, but I'm wondering if > > those IP cores need to be modelled in separate nodes. It would be > > much > > easier, from a software point of view, to have a single node, with > > multiple register ranges. > > > > Are some of those IP cores used in different SoCs, combined in > > different > > ways, that make a modular design better ? > > > 1. Each a node should respect a HW node. Defining a complex node that contain multiple register is not better, for they belong to different hardware. Different platforms has different hardware count, mt8195 has five hardwares. 2. Another reason is from the IOMMU point, the vcodec HW include core and lat hardwares, each of them connect to the independent IOMMU hardware for mt8195, can't write all iommu ports together, or hardware can't access dram data, so we must separate them. > Yeah, I agree with Laurent here. This way of modelling the different > parts > of the CODEC as different pieces is the reason why you need a > framework > to pull them together, such as the component API (I guess v4l2-async > could have been used as well). > We must separate each hardware node, only master need to register video and media device, component just used for store clk/power/irq/register information for current hardware. > I normally don't bother with driver internals, as its up to each > driver > author to decide what is best. However, I believe this design is too > convoluted, and it may lead other developers to follow the same > pattern, > so please avoid it. > According to your information, it looks that component and v4l2 async are ok for this architecture, only component is too convoluted(iommu driver also use component). For we are not very familiar with v4l2 async, out architecture is designed for component include next forty patches. It is a very big change for out driver. I will try to spend a lot of time to change it. > There are several ways of modelling this and initializing or probing > the sub-devices, > without using any async framework. > You may misunderstand, I'm not objecting your suggestion every time, for our driver is designed for component api, need to spend a lot of time to change it in many platforms. I will change it if v4l2 async has many advantages then component as you said. I will try to use v4l2 async as compared. > Thanks, > Ezequiel Thanks for your suggestion. Yunfei Dong _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel