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=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=no 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 D2352C49361 for ; Tue, 15 Jun 2021 02:34:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B7EE2613F5 for ; Tue, 15 Jun 2021 02:34:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230390AbhFOCgr (ORCPT ); Mon, 14 Jun 2021 22:36:47 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:48848 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S229809AbhFOCgq (ORCPT ); Mon, 14 Jun 2021 22:36:46 -0400 X-UUID: b244fbb211c9499e8c058deaf065f444-20210615 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=JNXKNmpy51jBAsMEkhMZ98xjcuU+lc4j1vj8Rx5Ai8I=; b=pGi71SOzJXO1tj0nUNmn32NhoizTYmfootxQ2xckZVUdU2xFVvllMrFugcJ87D9CmVpL9c26088cfc/PJAah0GkL22rKI8CRTUxbxez/KcJNGLvnHLM5K3Up/oBR1wiuZKZjXOMr77ls8v6yiX+HkasoK/VZeSwrHBu3zVIC6RU=; X-UUID: b244fbb211c9499e8c058deaf065f444-20210615 Received: from mtkcas10.mediatek.inc [(172.21.101.39)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1001541838; Tue, 15 Jun 2021 10:34:38 +0800 Received: from mtkcas10.mediatek.inc (172.21.101.39) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Jun 2021 10:34:37 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas10.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 15 Jun 2021 10:34:37 +0800 Message-ID: Subject: Re: [PATCH v9 01/22] dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c wrapper controller From: Chun-Jie Chen To: Matthias Brugger , Stephen Boyd , Rob Herring CC: Nicolas Boichat , , , , , , , , Weiyi Lu Date: Tue, 15 Jun 2021 10:34:37 +0800 In-Reply-To: References: <20210524122053.17155-1-chun-jie.chen@mediatek.com> <20210524122053.17155-2-chun-jie.chen@mediatek.com> <20210602171201.GA3566462@robh.at.kernel.org> <66e017401ab93aa02c5d2bbf11be9589b36649ac.camel@mediatek.com> <1f59ed31-4a0e-9719-bf84-1fe4cdd6c57d@gmail.com> <162334689784.9598.2709970788186333494@swboyd.mtv.corp.google.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 T24gRnJpLCAyMDIxLTA2LTExIGF0IDExOjU2ICswMjAwLCBNYXR0aGlhcyBCcnVnZ2VyIHdyb3Rl Og0KPiANCj4gT24gMTAvMDYvMjAyMSAxOTo0MSwgU3RlcGhlbiBCb3lkIHdyb3RlOg0KPiA+IFF1 b3RpbmcgTWF0dGhpYXMgQnJ1Z2dlciAoMjAyMS0wNi0wOCAwNzo0NTo0OSkNCj4gPiA+IA0KPiA+ ID4gDQo+ID4gPiBPbiAwNy8wNi8yMDIxIDA3OjIwLCBDaHVuLUppZSBDaGVuIHdyb3RlOg0KPiA+ ID4gPiBPbiBXZWQsIDIwMjEtMDYtMDIgYXQgMTI6MTIgLTA1MDAsIFJvYiBIZXJyaW5nIHdyb3Rl Og0KPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gK2Rlc2NyaXB0aW9uOg0KPiA+ID4gPiA+ID4g KyAgVGhlIE1lZGlhdGVrIGltcCBpMmMgd3JhcHBlciBjb250cm9sbGVyIHByb3ZpZGVzDQo+ID4g PiA+ID4gPiBmdW5jdGlvbmFsDQo+ID4gPiA+ID4gPiBjb25maWd1cmF0aW9ucyBhbmQgY2xvY2tz IHRvIHRoZSBzeXN0ZW0uDQo+ID4gPiA+ID4gPiArDQo+ID4gPiA+ID4gPiArcHJvcGVydGllczoN Cj4gPiA+ID4gPiA+ICsgIGNvbXBhdGlibGU6DQo+ID4gPiA+ID4gPiArICAgIGl0ZW1zOg0KPiA+ ID4gPiA+ID4gKyAgICAgIC0gZW51bToNCj4gPiA+ID4gPiA+ICsgICAgICAgICAgLSBtZWRpYXRl ayxtdDgxOTItaW1wX2lpY193cmFwX2MNCj4gPiA+ID4gPiA+ICsgICAgICAgICAgLSBtZWRpYXRl ayxtdDgxOTItaW1wX2lpY193cmFwX2UNCj4gPiA+ID4gPiA+ICsgICAgICAgICAgLSBtZWRpYXRl ayxtdDgxOTItaW1wX2lpY193cmFwX3MNCj4gPiA+ID4gPiA+ICsgICAgICAgICAgLSBtZWRpYXRl ayxtdDgxOTItaW1wX2lpY193cmFwX3dzDQo+ID4gPiA+ID4gPiArICAgICAgICAgIC0gbWVkaWF0 ZWssbXQ4MTkyLWltcF9paWNfd3JhcF93DQo+ID4gPiA+ID4gPiArICAgICAgICAgIC0gbWVkaWF0 ZWssbXQ4MTkyLWltcF9paWNfd3JhcF9uDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gTG9va3MgdG8g bWUgbGlrZSB0aGVzZSBhcmUgYWxsIHRoZSBzYW1lIGgvdywgYnV0IGp1c3QgaGF2ZQ0KPiA+ID4g PiA+IGRpZmZlcmluZyANCj4gPiA+ID4gPiBzZXRzIG9mIGNsb2Nrcy4gVGhhdCdzIG5vdCByZWFs bHkgYSByZWFzb24gdG8gaGF2ZSBkaWZmZXJlbnQgDQo+ID4gPiA+ID4gY29tcGF0aWJsZXMuIA0K PiA+ID4gPiA+IA0KPiA+ID4gPiA+IElmIHlvdSBuZWVkIHRvIGtub3cgd2hhdCBjbG9ja3MgYXJl IHByZXNlbnQsIHlvdSBjYW4gd2FsayB0aGUNCj4gPiA+ID4gPiBEVCBmb3IgDQo+ID4gPiA+ID4g YWxsICdjbG9ja3MnIHByb3BlcnRpZXMgbWF0Y2hpbmcgdGhpcyBjbG9jayBjb250cm9sbGVyDQo+ ID4gPiA+ID4gaW5zdGFuY2UuIE9yDQo+ID4gPiA+ID4gdXNlIA0KPiA+ID4gPiA+ICdjbG9jay1p bmRpY2VzJyB0byBkZWZpbmUgd2hpY2ggb25lcyBhcmUgcHJlc2VudC4NCj4gPiANCj4gPiBJcyB0 aGUgaWRlYSB0byB1c2UgY2xvY2staW5kaWNlcyBhbmQgdGhlbiBsaXN0IGFsbCB0aGUgY2xvY2sg aWRzIGluDQo+ID4gdGhlcmUgYW5kIG1hdGNoIHRoZW0gdXAgYXQgZHJpdmVyIHByb2JlIHRpbWUg dG8gcmVnaXN0ZXIgdGhlIGNsb2Nrcw0KPiA+IHByb3ZpZGVkIGJ5IHRoZSBJTyByZWdpb24/IEZl ZWxzIGxpa2Ugd2UnbGwgZG8gYSBsb3Qgb2YgcGFyc2luZyBhdA0KPiA+IGVhY2gNCj4gPiBib290 IHRvIG1hdGNoIHVwIHN0cnVjdHVyZXMgYW5kIHJlZ2lzdGVyIGNsa3Mgd2l0aCB0aGUgY2xrDQo+ ID4gZnJhbWV3b3JrLg0KPiA+IA0KPiA+IElmIGl0J3MgbGlrZSBvdGhlciBTb0NzIHRoZW4gdGhl IGNsayBpZCBtYXBzIHRvIGEgaGFyZCBtYWNybyBmb3IgYQ0KPiA+IHR5cGUNCj4gPiBvZiBjbGss IGFuZCB0aG9zZSBoYXJkIG1hY3JvcyBoYXZlIGJlZW4gZ2x1ZWQgdG9nZXRoZXIgd2l0aCBvdGhl cg0KPiA+IGNsa3MNCj4gPiBhbmQgdGhlbiBwYXJ0aXRpb25lZCBpbnRvIGRpZmZlcmVudCBJTyBy ZWdpb25zIHRvIG1ha2UgdXAgYSBjbG9jaw0KPiA+IGNvbnRyb2xsZXIuIE9yIG1heWJlIGluIHRo aXMgY2FzZSwgdGhvc2UgY2xrIGhhcmQgbWFjcm9zIGhhdmUgYmVlbg0KPiA+IHNjYXR0ZXJlZCBp bnRvIGVhY2ggSVAgYmxvY2sgbGlrZSBTUEksIGkyYywgdWFydCwgZXRjLiBzbyB0aGF0IHRoZQ0K PiA+IGNsb2NrDQo+ID4gY29udHJvbGxlciBkb2Vzbid0IHJlYWxseSBleGlzdCBhbmQgbWVyZWx5 IHRoZSBnYXRlcyBhbmQgcmF0ZQ0KPiA+IGNvbnRyb2wNCj4gPiAobXV4L2RpdmlkZXIpIGZvciB0 aGUgY2xrIHRoYXQncyBjbG9ja2luZyBzb21lIHBhcnRpY3VsYXIgSVAgYmxvY2sNCj4gPiBhbGwN Cj4gPiBsaXZlIGluc2lkZSB0aGUgSVAgd3JhcHBlci4gSWYgaXQncyB0aGlzIGNhc2UgdGhlbiBJ IGhvcGUgdGhlcmUgYXJlDQo+ID4gYQ0KPiA+IGJ1bmNoIG9mIFBMTHMgdGhhdCBhcmUgZml4ZWQg cmF0ZSBzbyB0aGF0IHRoZSBpMmMgY2xrIGRvZXNuJ3QgaGF2ZQ0KPiA+IHRvIGdvDQo+ID4gb3V0 c2lkZSB0aGUgd3JhcHBlciB0byBjaGFuZ2UgZnJlcXVlbmN5IChvZiB3aGljaCB0aGVyZSBzaG91 bGQgYmUNCj4gPiB0d28NCj4gPiAic3RhbmRhcmQiIGZyZXF1ZW5jaWVzIGFueXdheSkuDQo+ID4g DQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gUm9iDQo+ID4gPiA+IA0KPiA+ID4gPiBTb21lIG1vZHVs ZSBpcyBkaXZpZGVkIHRvIHN1Yi1tb2R1bGVzIHdoaWNoIGFyZSBkZXNpZ25lZCBpbg0KPiA+ID4g PiBkaWZmZXJlbnQNCj4gPiA+ID4gaC93IGJsb2NrcyBmb3IgZGlmZmVyZW50IHVzYWdlLCBhbmQg aWYgd2Ugd2FudCB0byB1c2UgdGhlIHNhbWUNCj4gPiA+ID4gY29tcGF0aWJsZSB0byBwcmVzZW50 IHRoZXNlIGgvdyBibG9ja3MsIHdlIG5lZWQgdG8gbW92ZSB0aGUNCj4gPiA+ID4gY2xvY2sgZGF0 YQ0KPiA+ID4gPiBwcm92aWRlZCBieSB0aGVzZSBoL3cgYmxvY2tzIHRvIGR0cywgYnV0IHdlIHVz dWFsbHkgdXNlDQo+ID4gPiA+IGRpZmZlcmVudA0KPiA+ID4gPiBjb21wYXRpYmxlIHRvIGdldCB0 aGUgaC93IGJsb2NrcyBkYXRhIGluDQo+ID4gPiA+IE1lZGlhdGVrJ3MgY2xvY2sgZHJpdmVyLCBz byBkbyB5b3Ugc3VnZ2VzdCB0byByZWdpc3RlciBjbG9jaw0KPiA+ID4gPiBwcm92aWRlZA0KPiA+ ID4gPiBieSBkaWZmZXJlbnQgaC93IGJsb2NrcyB1c2luZyBzYW1lIGNvbXBhdGlibGU/DQo+ID4g PiA+IA0KPiA+ID4gDQo+ID4gPiBUaGUgbWFwcGluZyBvZiB0aGVtIGlzIGFzIGZvbGxvd2luZzoN Cj4gPiA+IGltcF9paWNfd3JhcF9jOiAgMTEwMDcwMDANCj4gPiA+IGltcF9paWNfd3JhcF9lOiAg MTFjYjEwMDANCj4gPiA+IGltcF9paWNfd3JhcF9zOiAgMTFkMDMwMDANCj4gPiA+IGltcF9paWNf d3JhcF93czogMTFkMjMwMDANCj4gPiA+IGltcF9paWNfd3JhcF93OiAgMTFlMDEwMDANCj4gPiA+ IGltcF9paWNfd3JhcF9uOiAgMTFmMDIwMDANCj4gPiA+IA0KPiA+IA0KPiA+IFN1cmUuIFdoYXQg aXMgdGhlaXIgcHVycG9zZSB0aG91Z2g/IEFyZSB0aGV5IHNpbXBseSBhIGJ1bmNoIG9mDQo+ID4g ZGlmZmVyZW50DQo+ID4gaTJjIGNsa3M/DQo+ID4gDQo+IA0KPiBUaGF0IHdvdWxkIGJlIG5lZWQg dG8gYmUgYW5zd2VyZWQgYnkgTWVkaWFUZWsgYXMgSSBkb24ndCBoYXZlIGFjY2Vzcw0KPiB0byBh bnkNCj4gZG9jdW1lbnRhdGlvbi4NCj4gDQo+IFJlZ2FyZHMsDQo+IE1hdHRoaWFzDQoNCldlIGRl c2NyaWJlIHdoaWNoIGNsb2NrIGNvbnRyb2xsZXJzIGFyZSBleGlzdCBpbiBkdHMgYW5kDQpnZXQg dGhlIGNsb2NrIGRhdGEgcHJvdmlkZWQgYnkgY2xvY2sgY29udHJvbGxlciBpbiBkcml2ZXIgZGF0 YQ0KYnkgbWF0Y2hpbmcgZGV2aWNlIGNvbXBhdGlibGUuDQoNClRoZSBjbG9jayBkYXRhIGNvbnRh aW5zIHNldmVyYWwgY2xvY2tzIHdoaWNoIGluY2x1ZGVzIHRoZSBjbG9jayBpbmRleCwNCnBhcmVu dCBjbG9jayBzb3VyY2UgYW5kIHRoZSBkZXRhaWxzIG9mIHJlZyBjb250cm9sIGluc2lkZSB0aGUg SVAgYmxvY2sNCm9mIGNsb2NrIGNvbnRyb2xsZXIuDQoNCkluIE1UODE5MiBwbGF0Zm9ybSwgc29t ZSBJUCBibG9jayBpcyBkaXZpZGUgdG8gc2V2ZXJhbCBzdWItYmxvY2tzIGFuZA0KZWFjaCBzdWIt YmxvY2sgcHJvdmlkZXMgY2xvY2sgY29udHJvbCBieSBpdHNlbGYuDQoNCkJlc3QgUmVnYXJkcywN CkNodW4tSmllDQo= 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=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=no 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 12E10C48BE5 for ; Tue, 15 Jun 2021 18: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 CFBCB61209 for ; Tue, 15 Jun 2021 18:34:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CFBCB61209 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@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=1D/xb3bVOFiwKVE74yOWamfO9w55qTSTch9s1F48TtU=; b=rKCQnxLdUlmug3 2DYPbCmxKPYkWBF1dluQYWwl2o3nS9pdjeeKpzywT2KLTUbMqNNF+TZC9i3ksq36HNjdiTN6Jdr7e F7nMIDP5I2GVQMjoA+0eWYPfJumaNZEVDxDhtDq89csCtHaBE++tr2AcY01jMc8lBFoULK5bn8Xhq JzeCm8T1grRDyiiuCJpquIwm8oF+bFTgWiBKn3ZE34HiRaCY6GHHUkGTGditStvvaprmqTd1yy9Od Nw9jbPLpEycmv3s5Ff8AuXG1bVbyaIv9j3Vta+zYInA34OEP3fuyjkPJABcnVOnJmlOrwQfaxztmL keZOUPlaYd7y7u+Izr5w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltDsj-0029rq-LE; Tue, 15 Jun 2021 18:33:49 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lt9Pz-000E8e-4k; Tue, 15 Jun 2021 13:47:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:MIME-Version :Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID: Sender:Reply-To:Content-ID:Content-Description; bh=JNXKNmpy51jBAsMEkhMZ98xjcuU+lc4j1vj8Rx5Ai8I=; b=krts4tl479NKvWX6fvGAzXzqoW HpulymS7KwpTJAxHsOgFQSDCsUnYN0nJQPeiUcNcuOeAxz5eZueH+DwLNiEh72CTiZg2a3U2MDilI 1r745g/r9kce7kGmXXhwaw+dc+cEC7z64FqE/nVDHr2gOzyd0mFMWUTLC21UxqJthvN3LVgKUm/go ELDwXzWhsLTmAqNJtCBglPuV/qFBEZ9g/xUmmhMuRh0E8EEfFywG0hPcoKXxQOWZGfaIkFbyxtiz8 KKvEhz5PyVHCtLeWwVwVex+i1ncNFyQnFfrTYxapVHCtYYpUydmMEKuNc0QxmWsAkWegm70wsOQOp j95xaxig==; Received: from mailgw01.mediatek.com ([216.200.240.184]) by desiato.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lsyuW-007Gaf-0M; Tue, 15 Jun 2021 02:34:49 +0000 X-UUID: 4e238dad13774550939a5239ca9b8451-20210614 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=JNXKNmpy51jBAsMEkhMZ98xjcuU+lc4j1vj8Rx5Ai8I=; b=pGi71SOzJXO1tj0nUNmn32NhoizTYmfootxQ2xckZVUdU2xFVvllMrFugcJ87D9CmVpL9c26088cfc/PJAah0GkL22rKI8CRTUxbxez/KcJNGLvnHLM5K3Up/oBR1wiuZKZjXOMr77ls8v6yiX+HkasoK/VZeSwrHBu3zVIC6RU=; X-UUID: 4e238dad13774550939a5239ca9b8451-20210614 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 2098576690; Mon, 14 Jun 2021 19:34:40 -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; Mon, 14 Jun 2021 19:34:38 -0700 Received: from mtkcas10.mediatek.inc (172.21.101.39) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Jun 2021 10:34:37 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas10.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 15 Jun 2021 10:34:37 +0800 Message-ID: Subject: Re: [PATCH v9 01/22] dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c wrapper controller From: Chun-Jie Chen To: Matthias Brugger , Stephen Boyd , Rob Herring CC: Nicolas Boichat , , , , , , , , Weiyi Lu Date: Tue, 15 Jun 2021 10:34:37 +0800 In-Reply-To: References: <20210524122053.17155-1-chun-jie.chen@mediatek.com> <20210524122053.17155-2-chun-jie.chen@mediatek.com> <20210602171201.GA3566462@robh.at.kernel.org> <66e017401ab93aa02c5d2bbf11be9589b36649ac.camel@mediatek.com> <1f59ed31-4a0e-9719-bf84-1fe4cdd6c57d@gmail.com> <162334689784.9598.2709970788186333494@swboyd.mtv.corp.google.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-20210615_033447_240770_2433134A X-CRM114-Status: GOOD ( 35.77 ) 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 Fri, 2021-06-11 at 11:56 +0200, Matthias Brugger wrote: > > On 10/06/2021 19:41, Stephen Boyd wrote: > > Quoting Matthias Brugger (2021-06-08 07:45:49) > > > > > > > > > On 07/06/2021 07:20, Chun-Jie Chen wrote: > > > > On Wed, 2021-06-02 at 12:12 -0500, Rob Herring wrote: > > > > > > + > > > > > > +description: > > > > > > + The Mediatek imp i2c wrapper controller provides > > > > > > functional > > > > > > configurations and clocks to the system. > > > > > > + > > > > > > +properties: > > > > > > + compatible: > > > > > > + items: > > > > > > + - enum: > > > > > > + - mediatek,mt8192-imp_iic_wrap_c > > > > > > + - mediatek,mt8192-imp_iic_wrap_e > > > > > > + - mediatek,mt8192-imp_iic_wrap_s > > > > > > + - mediatek,mt8192-imp_iic_wrap_ws > > > > > > + - mediatek,mt8192-imp_iic_wrap_w > > > > > > + - mediatek,mt8192-imp_iic_wrap_n > > > > > > > > > > Looks to me like these are all the same h/w, but just have > > > > > differing > > > > > sets of clocks. That's not really a reason to have different > > > > > compatibles. > > > > > > > > > > If you need to know what clocks are present, you can walk the > > > > > DT for > > > > > all 'clocks' properties matching this clock controller > > > > > instance. Or > > > > > use > > > > > 'clock-indices' to define which ones are present. > > > > Is the idea to use clock-indices and then list all the clock ids in > > there and match them up at driver probe time to register the clocks > > provided by the IO region? Feels like we'll do a lot of parsing at > > each > > boot to match up structures and register clks with the clk > > framework. > > > > If it's like other SoCs then the clk id maps to a hard macro for a > > type > > of clk, and those hard macros have been glued together with other > > clks > > and then partitioned into different IO regions to make up a clock > > controller. Or maybe in this case, those clk hard macros have been > > scattered into each IP block like SPI, i2c, uart, etc. so that the > > clock > > controller doesn't really exist and merely the gates and rate > > control > > (mux/divider) for the clk that's clocking some particular IP block > > all > > live inside the IP wrapper. If it's this case then I hope there are > > a > > bunch of PLLs that are fixed rate so that the i2c clk doesn't have > > to go > > outside the wrapper to change frequency (of which there should be > > two > > "standard" frequencies anyway). > > > > > > > > > > > > Rob > > > > > > > > Some module is divided to sub-modules which are designed in > > > > different > > > > h/w blocks for different usage, and if we want to use the same > > > > compatible to present these h/w blocks, we need to move the > > > > clock data > > > > provided by these h/w blocks to dts, but we usually use > > > > different > > > > compatible to get the h/w blocks data in > > > > Mediatek's clock driver, so do you suggest to register clock > > > > provided > > > > by different h/w blocks using same compatible? > > > > > > > > > > The mapping of them is as following: > > > imp_iic_wrap_c: 11007000 > > > imp_iic_wrap_e: 11cb1000 > > > imp_iic_wrap_s: 11d03000 > > > imp_iic_wrap_ws: 11d23000 > > > imp_iic_wrap_w: 11e01000 > > > imp_iic_wrap_n: 11f02000 > > > > > > > Sure. What is their purpose though? Are they simply a bunch of > > different > > i2c clks? > > > > That would be need to be answered by MediaTek as I don't have access > to any > documentation. > > Regards, > Matthias We describe which clock controllers are exist in dts and get the clock data provided by clock controller in driver data by matching device compatible. The clock data contains several clocks which includes the clock index, parent clock source and the details of reg control inside the IP block of clock controller. In MT8192 platform, some IP block is divide to several sub-blocks and each sub-block provides clock control by itself. Best Regards, Chun-Jie _______________________________________________ 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=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=no 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 C5FFBC48BE5 for ; Tue, 15 Jun 2021 18:36:26 +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 7931B61185 for ; Tue, 15 Jun 2021 18:36:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7931B61185 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@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=rajiMJ+yFaxfbuyJAEClPlRqh3dN+6TUDdbfMmE2qHc=; b=B6EVICoGod5ozu w4I4LQrT9kkz9LJp5RdxNOvdnTMjhNB/PewWMHH3cgX8UTq+2n5hzv7DBE1kc3Mdlm2+Doa1HZApo OAMsy6o8DONI1t2Cn5OsCP8LAgnoOjheTejGOozVk0Sg8p0J9DDlyIMXdLPPvwwmHyY6Nw44tdmFP mdczoU81UlWPS38oakF+D8ap9lhEJiqKSHSx1uzXEDBKHNqNcbWpmisQ8wuqgRr3m/ZBq3a5O4MUD UbwYTzskblRLSe2f9CEr0NT9bTNHiwNfG994U3E7rEo3B//pClj2fqsnCCGjFslYg+Yg2TpI1GyXR Nt6rZEZlYN55gzcSSOzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ltDsv-0029su-6k; Tue, 15 Jun 2021 18:34:02 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lt9Pz-000E8e-4k; Tue, 15 Jun 2021 13:47:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:MIME-Version :Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID: Sender:Reply-To:Content-ID:Content-Description; bh=JNXKNmpy51jBAsMEkhMZ98xjcuU+lc4j1vj8Rx5Ai8I=; b=krts4tl479NKvWX6fvGAzXzqoW HpulymS7KwpTJAxHsOgFQSDCsUnYN0nJQPeiUcNcuOeAxz5eZueH+DwLNiEh72CTiZg2a3U2MDilI 1r745g/r9kce7kGmXXhwaw+dc+cEC7z64FqE/nVDHr2gOzyd0mFMWUTLC21UxqJthvN3LVgKUm/go ELDwXzWhsLTmAqNJtCBglPuV/qFBEZ9g/xUmmhMuRh0E8EEfFywG0hPcoKXxQOWZGfaIkFbyxtiz8 KKvEhz5PyVHCtLeWwVwVex+i1ncNFyQnFfrTYxapVHCtYYpUydmMEKuNc0QxmWsAkWegm70wsOQOp j95xaxig==; Received: from mailgw01.mediatek.com ([216.200.240.184]) by desiato.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lsyuW-007Gaf-0M; Tue, 15 Jun 2021 02:34:49 +0000 X-UUID: 4e238dad13774550939a5239ca9b8451-20210614 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=JNXKNmpy51jBAsMEkhMZ98xjcuU+lc4j1vj8Rx5Ai8I=; b=pGi71SOzJXO1tj0nUNmn32NhoizTYmfootxQ2xckZVUdU2xFVvllMrFugcJ87D9CmVpL9c26088cfc/PJAah0GkL22rKI8CRTUxbxez/KcJNGLvnHLM5K3Up/oBR1wiuZKZjXOMr77ls8v6yiX+HkasoK/VZeSwrHBu3zVIC6RU=; X-UUID: 4e238dad13774550939a5239ca9b8451-20210614 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 2098576690; Mon, 14 Jun 2021 19:34:40 -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; Mon, 14 Jun 2021 19:34:38 -0700 Received: from mtkcas10.mediatek.inc (172.21.101.39) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Jun 2021 10:34:37 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas10.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 15 Jun 2021 10:34:37 +0800 Message-ID: Subject: Re: [PATCH v9 01/22] dt-bindings: ARM: Mediatek: Add new document bindings of imp i2c wrapper controller From: Chun-Jie Chen To: Matthias Brugger , Stephen Boyd , Rob Herring CC: Nicolas Boichat , , , , , , , , Weiyi Lu Date: Tue, 15 Jun 2021 10:34:37 +0800 In-Reply-To: References: <20210524122053.17155-1-chun-jie.chen@mediatek.com> <20210524122053.17155-2-chun-jie.chen@mediatek.com> <20210602171201.GA3566462@robh.at.kernel.org> <66e017401ab93aa02c5d2bbf11be9589b36649ac.camel@mediatek.com> <1f59ed31-4a0e-9719-bf84-1fe4cdd6c57d@gmail.com> <162334689784.9598.2709970788186333494@swboyd.mtv.corp.google.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-20210615_033447_240770_2433134A X-CRM114-Status: GOOD ( 35.77 ) 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 Fri, 2021-06-11 at 11:56 +0200, Matthias Brugger wrote: > > On 10/06/2021 19:41, Stephen Boyd wrote: > > Quoting Matthias Brugger (2021-06-08 07:45:49) > > > > > > > > > On 07/06/2021 07:20, Chun-Jie Chen wrote: > > > > On Wed, 2021-06-02 at 12:12 -0500, Rob Herring wrote: > > > > > > + > > > > > > +description: > > > > > > + The Mediatek imp i2c wrapper controller provides > > > > > > functional > > > > > > configurations and clocks to the system. > > > > > > + > > > > > > +properties: > > > > > > + compatible: > > > > > > + items: > > > > > > + - enum: > > > > > > + - mediatek,mt8192-imp_iic_wrap_c > > > > > > + - mediatek,mt8192-imp_iic_wrap_e > > > > > > + - mediatek,mt8192-imp_iic_wrap_s > > > > > > + - mediatek,mt8192-imp_iic_wrap_ws > > > > > > + - mediatek,mt8192-imp_iic_wrap_w > > > > > > + - mediatek,mt8192-imp_iic_wrap_n > > > > > > > > > > Looks to me like these are all the same h/w, but just have > > > > > differing > > > > > sets of clocks. That's not really a reason to have different > > > > > compatibles. > > > > > > > > > > If you need to know what clocks are present, you can walk the > > > > > DT for > > > > > all 'clocks' properties matching this clock controller > > > > > instance. Or > > > > > use > > > > > 'clock-indices' to define which ones are present. > > > > Is the idea to use clock-indices and then list all the clock ids in > > there and match them up at driver probe time to register the clocks > > provided by the IO region? Feels like we'll do a lot of parsing at > > each > > boot to match up structures and register clks with the clk > > framework. > > > > If it's like other SoCs then the clk id maps to a hard macro for a > > type > > of clk, and those hard macros have been glued together with other > > clks > > and then partitioned into different IO regions to make up a clock > > controller. Or maybe in this case, those clk hard macros have been > > scattered into each IP block like SPI, i2c, uart, etc. so that the > > clock > > controller doesn't really exist and merely the gates and rate > > control > > (mux/divider) for the clk that's clocking some particular IP block > > all > > live inside the IP wrapper. If it's this case then I hope there are > > a > > bunch of PLLs that are fixed rate so that the i2c clk doesn't have > > to go > > outside the wrapper to change frequency (of which there should be > > two > > "standard" frequencies anyway). > > > > > > > > > > > > Rob > > > > > > > > Some module is divided to sub-modules which are designed in > > > > different > > > > h/w blocks for different usage, and if we want to use the same > > > > compatible to present these h/w blocks, we need to move the > > > > clock data > > > > provided by these h/w blocks to dts, but we usually use > > > > different > > > > compatible to get the h/w blocks data in > > > > Mediatek's clock driver, so do you suggest to register clock > > > > provided > > > > by different h/w blocks using same compatible? > > > > > > > > > > The mapping of them is as following: > > > imp_iic_wrap_c: 11007000 > > > imp_iic_wrap_e: 11cb1000 > > > imp_iic_wrap_s: 11d03000 > > > imp_iic_wrap_ws: 11d23000 > > > imp_iic_wrap_w: 11e01000 > > > imp_iic_wrap_n: 11f02000 > > > > > > > Sure. What is their purpose though? Are they simply a bunch of > > different > > i2c clks? > > > > That would be need to be answered by MediaTek as I don't have access > to any > documentation. > > Regards, > Matthias We describe which clock controllers are exist in dts and get the clock data provided by clock controller in driver data by matching device compatible. The clock data contains several clocks which includes the clock index, parent clock source and the details of reg control inside the IP block of clock controller. In MT8192 platform, some IP block is divide to several sub-blocks and each sub-block provides clock control by itself. Best Regards, Chun-Jie _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel