From mboxrd@z Thu Jan 1 00:00:00 1970 From: shawnguo@kernel.org (Shawn Guo) Date: Fri, 4 May 2018 15:03:40 +0800 Subject: [PATCH v4 6/7] ARM: dts: Add support for emtrion emCON-MX6 series In-Reply-To: <95F51F4B902CAC40AF459205F6322F01B83109E5C3@BMK019S01.emtrion.local> References: <20180420125108.14197-1-jan.tuerk@emtrion.com> <20180427132445.3458-1-jan.tuerk@emtrion.com> <20180427132445.3458-7-jan.tuerk@emtrion.com> <20180428031231.GB3693@dragon> <95F51F4B902CAC40AF459205F6322F01B83109E5C3@BMK019S01.emtrion.local> Message-ID: <20180504070339.GS3443@dragon> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, May 03, 2018 at 12:00:06PM +0200, T?rk, Jan wrote: > > > +/ { > > > + aliases { > > > + mmc0 = &usdhc3; > > > + mmc2 = &usdhc1; > > > + mmc1 = &usdhc2; > > > + mmc3 = &usdhc4; > > > + boardID = &boardID; > > > > Why do you need this boardID alias? > I wanted to have a generic entry point to address the board-id on all CPU-modules with their different SoC's resulting in different devicetree paths. > Also as it now has the generic "gpio at 3a" name, there would be no other way in differencing the board Identifying GPIO-expander from an additionally > attached one (except platform code etc.) > With the alias every code could look up the information required over the alias path with the same piece of code. Okay. But no uppercase please. Otherwise, you introduce the following DTC warnings (with W=1 switch) we are trying to clean up. Warning (alias_paths): /aliases: aliases property name must include only lowercase and '-' > > > > > + }; > > > &pinctrl_nor_flash > > > + &pinctrl_usdhc2 > > > + &pinctrl_spdif_out &pinctrl_spdif_in > > > + &pinctrl_cpi1 &pinctrl_cpi2 > > > + >; > > > > Again, please do not put consumer device specific pins in hog group. > > Also, it's confusing to have the same pinctrl in both hog and consumer device > > node, like pinctrl_nor_flash and pinctrl_usdhc2 here. > > About pinctrl_nor_flash I fully agree, that's a mistake. > pinctrl_usdhc2 is not connected on the avari, and therefore not enabled. > As told before it is added to the Hog group to force the default pinmuxing without enabling the hardware itself. If you want to do such default pinmuxing, please do it in your firmware. We generally do not want to use hog group too much, because that makes it difficult to find out which client devices consume which pins. > > > > > > +}; > > > +&i2c1 { > > > + clock-frequency = <100000>; > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&pinctrl_i2c1>; > > > + status = "okay"; > > > + > > > + rtc: rtc at 68 { > > > > Is the label actually used? If yes, I would suggest a more specific name like > > ds1307. > Really? Why should it be a generic name for "gpio" and "pmic" but not a generic name for an "rtc" chip? I'm talking about label not node name. That said I was suggesting something like: ds1307: rtc at 68 > > > > > > + compatible = "dallas,ds1307"; > > > + reg = <0x68>; > > > + }; Shawn From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shawn Guo Subject: Re: [PATCH v4 6/7] ARM: dts: Add support for emtrion emCON-MX6 series Date: Fri, 4 May 2018 15:03:40 +0800 Message-ID: <20180504070339.GS3443@dragon> References: <20180420125108.14197-1-jan.tuerk@emtrion.com> <20180427132445.3458-1-jan.tuerk@emtrion.com> <20180427132445.3458-7-jan.tuerk@emtrion.com> <20180428031231.GB3693@dragon> <95F51F4B902CAC40AF459205F6322F01B83109E5C3@BMK019S01.emtrion.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <95F51F4B902CAC40AF459205F6322F01B83109E5C3@BMK019S01.emtrion.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?iso-8859-1?B?VPxyayw=?= Jan Cc: Mark Rutland , "devicetree@vger.kernel.org" , David Airlie , Russell King , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , Rob Herring , Thierry Reding , Pengutronix Kernel Team , Fabio Estevam , LinuxArmKernelMailingListe List-Id: devicetree@vger.kernel.org T24gVGh1LCBNYXkgMDMsIDIwMTggYXQgMTI6MDA6MDZQTSArMDIwMCwgVMO8cmssIEphbiB3cm90 ZToKPiA+ID4gKy8gewo+ID4gPiArICAgYWxpYXNlcyB7Cj4gPiA+ICsgICAgICAgICAgIG1tYzAg PSAmdXNkaGMzOwo+ID4gPiArICAgICAgICAgICBtbWMyID0gJnVzZGhjMTsKPiA+ID4gKyAgICAg ICAgICAgbW1jMSA9ICZ1c2RoYzI7Cj4gPiA+ICsgICAgICAgICAgIG1tYzMgPSAmdXNkaGM0Owo+ ID4gPiArICAgICAgICAgICBib2FyZElEID0gJmJvYXJkSUQ7Cj4gPgo+ID4gV2h5IGRvIHlvdSBu ZWVkIHRoaXMgYm9hcmRJRCBhbGlhcz8KPiBJIHdhbnRlZCB0byBoYXZlIGEgZ2VuZXJpYyBlbnRy eSBwb2ludCB0byBhZGRyZXNzIHRoZSBib2FyZC1pZCBvbiBhbGwgQ1BVLW1vZHVsZXMgd2l0aCB0 aGVpciBkaWZmZXJlbnQgU29DJ3MgcmVzdWx0aW5nIGluIGRpZmZlcmVudCBkZXZpY2V0cmVlIHBh dGhzLgo+IEFsc28gYXMgaXQgbm93IGhhcyB0aGUgZ2VuZXJpYyAiZ3Bpb0AzYSIgbmFtZSwgdGhl cmUgd291bGQgYmUgbm8gb3RoZXIgd2F5IGluIGRpZmZlcmVuY2luZyB0aGUgYm9hcmQgSWRlbnRp ZnlpbmcgR1BJTy1leHBhbmRlciBmcm9tIGFuIGFkZGl0aW9uYWxseQo+IGF0dGFjaGVkIG9uZSAo ZXhjZXB0IHBsYXRmb3JtIGNvZGUgZXRjLikKPiBXaXRoIHRoZSBhbGlhcyBldmVyeSBjb2RlIGNv dWxkIGxvb2sgdXAgdGhlIGluZm9ybWF0aW9uIHJlcXVpcmVkIG92ZXIgdGhlIGFsaWFzIHBhdGgg d2l0aCB0aGUgc2FtZSBwaWVjZSBvZiBjb2RlLgoKT2theS4gIEJ1dCBubyB1cHBlcmNhc2UgcGxl YXNlLiAgT3RoZXJ3aXNlLCB5b3UgaW50cm9kdWNlIHRoZSBmb2xsb3dpbmcKRFRDIHdhcm5pbmdz ICh3aXRoIFc9MSBzd2l0Y2gpIHdlIGFyZSB0cnlpbmcgdG8gY2xlYW4gdXAuCgogV2FybmluZyAo YWxpYXNfcGF0aHMpOiAvYWxpYXNlczogYWxpYXNlcyBwcm9wZXJ0eSBuYW1lIG11c3QgaW5jbHVk ZSBvbmx5IGxvd2VyY2FzZSBhbmQgJy0nCgo+ID4KPiA+ID4gKyAgIH07Cgo8c25pcD4KCj4gPiA+ ICZwaW5jdHJsX25vcl9mbGFzaAo+ID4gPiArICAgICAgICAgICAgJnBpbmN0cmxfdXNkaGMyCj4g PiA+ICsgICAgICAgICAgICAmcGluY3RybF9zcGRpZl9vdXQgICAgICZwaW5jdHJsX3NwZGlmX2lu Cj4gPiA+ICsgICAgICAgICAgICAmcGluY3RybF9jcGkxICAgICAgICAgICZwaW5jdHJsX2NwaTIK PiA+ID4gKyAgICAgICAgICAgPjsKPiA+Cj4gPiBBZ2FpbiwgcGxlYXNlIGRvIG5vdCBwdXQgY29u c3VtZXIgZGV2aWNlIHNwZWNpZmljIHBpbnMgaW4gaG9nIGdyb3VwLgo+ID4gQWxzbywgaXQncyBj b25mdXNpbmcgdG8gaGF2ZSB0aGUgc2FtZSBwaW5jdHJsIGluIGJvdGggaG9nIGFuZCBjb25zdW1l ciBkZXZpY2UKPiA+IG5vZGUsIGxpa2UgcGluY3RybF9ub3JfZmxhc2ggYW5kIHBpbmN0cmxfdXNk aGMyIGhlcmUuCj4gCj4gQWJvdXQgcGluY3RybF9ub3JfZmxhc2ggSSBmdWxseSBhZ3JlZSwgdGhh dCdzIGEgbWlzdGFrZS4KPiBwaW5jdHJsX3VzZGhjMiBpcyBub3QgY29ubmVjdGVkIG9uIHRoZSBh dmFyaSwgYW5kIHRoZXJlZm9yZSBub3QgZW5hYmxlZC4KPiBBcyB0b2xkIGJlZm9yZSBpdCBpcyBh ZGRlZCB0byB0aGUgSG9nIGdyb3VwIHRvIGZvcmNlIHRoZSBkZWZhdWx0IHBpbm11eGluZyB3aXRo b3V0IGVuYWJsaW5nIHRoZSBoYXJkd2FyZSBpdHNlbGYuCgpJZiB5b3Ugd2FudCB0byBkbyBzdWNo IGRlZmF1bHQgcGlubXV4aW5nLCBwbGVhc2UgZG8gaXQgaW4geW91ciBmaXJtd2FyZS4KV2UgZ2Vu ZXJhbGx5IGRvIG5vdCB3YW50IHRvIHVzZSBob2cgZ3JvdXAgdG9vIG11Y2gsIGJlY2F1c2UgdGhh dCBtYWtlcwppdCBkaWZmaWN1bHQgdG8gZmluZCBvdXQgd2hpY2ggY2xpZW50IGRldmljZXMgY29u c3VtZSB3aGljaCBwaW5zLgoKPiAKPiA+Cj4gPiA+ICt9OwoKPHNuaXA+Cgo+ID4gPiArJmkyYzEg ewo+ID4gPiArICAgY2xvY2stZnJlcXVlbmN5ID0gPDEwMDAwMD47Cj4gPiA+ICsgICBwaW5jdHJs LW5hbWVzID0gImRlZmF1bHQiOwo+ID4gPiArICAgcGluY3RybC0wID0gPCZwaW5jdHJsX2kyYzE+ Owo+ID4gPiArICAgc3RhdHVzID0gIm9rYXkiOwo+ID4gPiArCj4gPiA+ICsgICBydGM6IHJ0Y0A2 OCB7Cj4gPgo+ID4gSXMgdGhlIGxhYmVsIGFjdHVhbGx5IHVzZWQ/ICBJZiB5ZXMsIEkgd291bGQg c3VnZ2VzdCBhIG1vcmUgc3BlY2lmaWMgbmFtZSBsaWtlCj4gPiBkczEzMDcuCj4gUmVhbGx5PyBX aHkgc2hvdWxkIGl0IGJlIGEgZ2VuZXJpYyBuYW1lIGZvciAiZ3BpbyIgYW5kICJwbWljIiBidXQg bm90IGEgZ2VuZXJpYyBuYW1lIGZvciBhbiAicnRjIiBjaGlwPwoKSSdtIHRhbGtpbmcgYWJvdXQg bGFiZWwgbm90IG5vZGUgbmFtZS4gIFRoYXQgc2FpZCBJIHdhcyBzdWdnZXN0aW5nCnNvbWV0aGlu ZyBsaWtlOgoKCWRzMTMwNzogcnRjQDY4Cgo+IAo+ID4KPiA+ID4gKyAgICAgICAgICAgY29tcGF0 aWJsZSA9ICJkYWxsYXMsZHMxMzA3IjsKPiA+ID4gKyAgICAgICAgICAgcmVnID0gPDB4Njg+Owo+ ID4gPiArICAgfTsKClNoYXduCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNr dG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ry aS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751350AbeEDHEC (ORCPT ); Fri, 4 May 2018 03:04:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:55152 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbeEDHD6 (ORCPT ); Fri, 4 May 2018 03:03:58 -0400 Date: Fri, 4 May 2018 15:03:40 +0800 From: Shawn Guo To: =?iso-8859-1?B?VPxyayw=?= Jan Cc: Rob Herring , Mark Rutland , Thierry Reding , David Airlie , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Russell King , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , LinuxArmKernelMailingListe Subject: Re: [PATCH v4 6/7] ARM: dts: Add support for emtrion emCON-MX6 series Message-ID: <20180504070339.GS3443@dragon> References: <20180420125108.14197-1-jan.tuerk@emtrion.com> <20180427132445.3458-1-jan.tuerk@emtrion.com> <20180427132445.3458-7-jan.tuerk@emtrion.com> <20180428031231.GB3693@dragon> <95F51F4B902CAC40AF459205F6322F01B83109E5C3@BMK019S01.emtrion.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <95F51F4B902CAC40AF459205F6322F01B83109E5C3@BMK019S01.emtrion.local> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 03, 2018 at 12:00:06PM +0200, Türk, Jan wrote: > > > +/ { > > > + aliases { > > > + mmc0 = &usdhc3; > > > + mmc2 = &usdhc1; > > > + mmc1 = &usdhc2; > > > + mmc3 = &usdhc4; > > > + boardID = &boardID; > > > > Why do you need this boardID alias? > I wanted to have a generic entry point to address the board-id on all CPU-modules with their different SoC's resulting in different devicetree paths. > Also as it now has the generic "gpio@3a" name, there would be no other way in differencing the board Identifying GPIO-expander from an additionally > attached one (except platform code etc.) > With the alias every code could look up the information required over the alias path with the same piece of code. Okay. But no uppercase please. Otherwise, you introduce the following DTC warnings (with W=1 switch) we are trying to clean up. Warning (alias_paths): /aliases: aliases property name must include only lowercase and '-' > > > > > + }; > > > &pinctrl_nor_flash > > > + &pinctrl_usdhc2 > > > + &pinctrl_spdif_out &pinctrl_spdif_in > > > + &pinctrl_cpi1 &pinctrl_cpi2 > > > + >; > > > > Again, please do not put consumer device specific pins in hog group. > > Also, it's confusing to have the same pinctrl in both hog and consumer device > > node, like pinctrl_nor_flash and pinctrl_usdhc2 here. > > About pinctrl_nor_flash I fully agree, that's a mistake. > pinctrl_usdhc2 is not connected on the avari, and therefore not enabled. > As told before it is added to the Hog group to force the default pinmuxing without enabling the hardware itself. If you want to do such default pinmuxing, please do it in your firmware. We generally do not want to use hog group too much, because that makes it difficult to find out which client devices consume which pins. > > > > > > +}; > > > +&i2c1 { > > > + clock-frequency = <100000>; > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <&pinctrl_i2c1>; > > > + status = "okay"; > > > + > > > + rtc: rtc@68 { > > > > Is the label actually used? If yes, I would suggest a more specific name like > > ds1307. > Really? Why should it be a generic name for "gpio" and "pmic" but not a generic name for an "rtc" chip? I'm talking about label not node name. That said I was suggesting something like: ds1307: rtc@68 > > > > > > + compatible = "dallas,ds1307"; > > > + reg = <0x68>; > > > + }; Shawn