From mboxrd@z Thu Jan 1 00:00:00 1970 From: afaerber@suse.de (=?UTF-8?Q?Andreas_F=c3=a4rber?=) Date: Tue, 5 Jul 2016 15:55:23 +0200 Subject: [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support In-Reply-To: References: <1467691450-22975-1-git-send-email-afaerber@suse.de> <1467691450-22975-3-git-send-email-afaerber@suse.de> Message-ID: <577BBC4B.5040903@suse.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Fabio, Am 05.07.2016 um 14:04 schrieb Fabio Estevam: > On Tue, Jul 5, 2016 at 1:04 AM, Andreas F?rber wrote: > >> +/dts-v1/; >> + >> +#include "imx6sx-udoo-neo.dtsi" >> + >> +/ { >> + model = "UDOO Neo Basic"; > > This should be something like: > > model = "Udoo i.MX6 SoloX UDOO Neo Basic"; Why should anyone use such a weird concatenation of names? If you wanted "UDOO Neo Basic (based on i.MX 6SoloX)" that would be more understandable, but there is no UDOO Neo Basic board with another SoC: http://www.udoo.org/udoo-neo/ imx6dl-udoo.dts uses "Udoo i.MX6 Dual-lite Board" and imx6q-udoo.dts uses "Udoo i.MX6 Quad Board". So I'm open to discussing UDOO vs. Udoo spelling, but I don't see a requirement for mixing board vendor, SoC name and board name. /proc/cpuinfo displays "Freescale i.MX6 SoloX (Device Tree)" based on SoC compatible string and mach-imx/mach-imx6sx.c. Note that NXP calls it "i.MX6SX" or "i.MX 6SoloX" (spacing): http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx-6-processors/i.mx6qp/i.mx-6solox-processors-heterogeneous-processing-with-arm-cortex-a9-and-cortex-m4-cores:i.MX6SX >> + compatible = "fsl,imx6sx"; > > compatible = "udoo,imx6sx-udoo-neo", "fsl,imx6sx"; > > Then you can also send a separate patch to add udoo to > Documentation/devicetree/bindings/vendor-prefixes.txt. > > Same applies to other places in this patch. I know we could add compatibles. But you say it backwards: If I add a compatible string the vendor _must_ be defined in vendor-prefixes.txt and the board compatible _must_ be documented, too. Since I saw that there is no prefix for UDOO in vendor-prefixes.txt nor an arm/udoo.txt file to document its board compatibles _despite_ "udoo,imx6q-udoo" and "udoo,imx6dl-udoo" being in use, as an annoyed UDOO Neo owner I'd rather leave it to UDOO to add those on their own as follow-up if they care. Their downstream kernel does not have such a compatible string, they use "fsl,imx6sx-sdb", which looks like a bad case of copy&paste to me. However, "udoo,neo-basic", "udoo,neo", "fsl,imx6sx" should be sufficient since unlike the Quad/Dual situation there is no SoC variation here. Or "seco,udoo-neo"? "udoo,udoo-neo" looks duplicate. >> +&fec1 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&pinctrl_enet1>; >> + phy-mode = "rmii"; >> + phy-reset-gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>; > > Shouldn't this be GPIO_ACTIVE_LOW instead? Hm, network worked okay for me like this, how do we verify? Schematics are here: http://www.udoo.org/other-resources/ Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Graham Norton HRB 21284 (AG N?rnberg) From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Subject: Re: [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support Date: Tue, 5 Jul 2016 15:55:23 +0200 Message-ID: <577BBC4B.5040903@suse.de> References: <1467691450-22975-1-git-send-email-afaerber@suse.de> <1467691450-22975-3-git-send-email-afaerber@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Fabio Estevam Cc: Mark Rutland , devicetree , Russell King , LKML , Ettore Chimenti , Rob Herring , Sascha Hauer , Fabio Estevam , Shawn Guo , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org SGkgRmFiaW8sCgpBbSAwNS4wNy4yMDE2IHVtIDE0OjA0IHNjaHJpZWIgRmFiaW8gRXN0ZXZhbToK PiBPbiBUdWUsIEp1bCA1LCAyMDE2IGF0IDE6MDQgQU0sIEFuZHJlYXMgRsOkcmJlciA8YWZhZXJi ZXJAc3VzZS5kZT4gd3JvdGU6Cj4gCj4+ICsvZHRzLXYxLzsKPj4gKwo+PiArI2luY2x1ZGUgImlt eDZzeC11ZG9vLW5lby5kdHNpIgo+PiArCj4+ICsvIHsKPj4gKyAgICAgICBtb2RlbCA9ICJVRE9P IE5lbyBCYXNpYyI7Cj4gCj4gVGhpcyBzaG91bGQgYmUgc29tZXRoaW5nIGxpa2U6Cj4gCj4gbW9k ZWwgPSAiVWRvbyBpLk1YNiBTb2xvWCBVRE9PIE5lbyBCYXNpYyI7CgpXaHkgc2hvdWxkIGFueW9u ZSB1c2Ugc3VjaCBhIHdlaXJkIGNvbmNhdGVuYXRpb24gb2YgbmFtZXM/IElmIHlvdSB3YW50ZWQK IlVET08gTmVvIEJhc2ljIChiYXNlZCBvbiBpLk1YIDZTb2xvWCkiIHRoYXQgd291bGQgYmUgbW9y ZQp1bmRlcnN0YW5kYWJsZSwgYnV0IHRoZXJlIGlzIG5vIFVET08gTmVvIEJhc2ljIGJvYXJkIHdp dGggYW5vdGhlciBTb0M6CgpodHRwOi8vd3d3LnVkb28ub3JnL3Vkb28tbmVvLwoKaW14NmRsLXVk b28uZHRzIHVzZXMgIlVkb28gaS5NWDYgRHVhbC1saXRlIEJvYXJkIiBhbmQKaW14NnEtdWRvby5k dHMgIHVzZXMgIlVkb28gaS5NWDYgUXVhZCBCb2FyZCIuCgpTbyBJJ20gb3BlbiB0byBkaXNjdXNz aW5nIFVET08gdnMuIFVkb28gc3BlbGxpbmcsIGJ1dCBJIGRvbid0IHNlZSBhCnJlcXVpcmVtZW50 IGZvciBtaXhpbmcgYm9hcmQgdmVuZG9yLCBTb0MgbmFtZSBhbmQgYm9hcmQgbmFtZS4KCi9wcm9j L2NwdWluZm8gZGlzcGxheXMgIkZyZWVzY2FsZSBpLk1YNiBTb2xvWCAoRGV2aWNlIFRyZWUpIiBi YXNlZCBvbgpTb0MgY29tcGF0aWJsZSBzdHJpbmcgYW5kIG1hY2gtaW14L21hY2gtaW14NnN4LmMu CgpOb3RlIHRoYXQgTlhQIGNhbGxzIGl0ICJpLk1YNlNYIiBvciAiaS5NWCA2U29sb1giIChzcGFj aW5nKToKCmh0dHA6Ly93d3cubnhwLmNvbS9wcm9kdWN0cy9taWNyb2NvbnRyb2xsZXJzLWFuZC1w cm9jZXNzb3JzL2FybS1wcm9jZXNzb3JzL2kubXgtYXBwbGljYXRpb25zLXByb2Nlc3NvcnMvaS5t eC02LXByb2Nlc3NvcnMvaS5teDZxcC9pLm14LTZzb2xveC1wcm9jZXNzb3JzLWhldGVyb2dlbmVv dXMtcHJvY2Vzc2luZy13aXRoLWFybS1jb3J0ZXgtYTktYW5kLWNvcnRleC1tNC1jb3JlczppLk1Y NlNYCgo+PiArICAgICAgIGNvbXBhdGlibGUgPSAiZnNsLGlteDZzeCI7Cj4gCj4gY29tcGF0aWJs ZSA9ICJ1ZG9vLGlteDZzeC11ZG9vLW5lbyIsICJmc2wsaW14NnN4IjsKPiAKPiBUaGVuIHlvdSBj YW4gYWxzbyBzZW5kIGEgc2VwYXJhdGUgcGF0Y2ggdG8gYWRkIHVkb28gdG8KPiBEb2N1bWVudGF0 aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdmVuZG9yLXByZWZpeGVzLnR4dC4KPiAKPiBTYW1lIGFw cGxpZXMgdG8gb3RoZXIgcGxhY2VzIGluIHRoaXMgcGF0Y2guCgpJIGtub3cgd2UgY291bGQgYWRk IGNvbXBhdGlibGVzLiBCdXQgeW91IHNheSBpdCBiYWNrd2FyZHM6IElmIEkgYWRkIGEKY29tcGF0 aWJsZSBzdHJpbmcgdGhlIHZlbmRvciBfbXVzdF8gYmUgZGVmaW5lZCBpbiB2ZW5kb3ItcHJlZml4 ZXMudHh0CmFuZCB0aGUgYm9hcmQgY29tcGF0aWJsZSBfbXVzdF8gYmUgZG9jdW1lbnRlZCwgdG9v LiBTaW5jZSBJIHNhdyB0aGF0CnRoZXJlIGlzIG5vIHByZWZpeCBmb3IgVURPTyBpbiB2ZW5kb3It cHJlZml4ZXMudHh0IG5vciBhbiBhcm0vdWRvby50eHQKZmlsZSB0byBkb2N1bWVudCBpdHMgYm9h cmQgY29tcGF0aWJsZXMgX2Rlc3BpdGVfICJ1ZG9vLGlteDZxLXVkb28iIGFuZAoidWRvbyxpbXg2 ZGwtdWRvbyIgYmVpbmcgaW4gdXNlLCBhcyBhbiBhbm5veWVkIFVET08gTmVvIG93bmVyIEknZCBy YXRoZXIKbGVhdmUgaXQgdG8gVURPTyB0byBhZGQgdGhvc2Ugb24gdGhlaXIgb3duIGFzIGZvbGxv dy11cCBpZiB0aGV5IGNhcmUuClRoZWlyIGRvd25zdHJlYW0ga2VybmVsIGRvZXMgbm90IGhhdmUg c3VjaCBhIGNvbXBhdGlibGUgc3RyaW5nLCB0aGV5IHVzZQoiZnNsLGlteDZzeC1zZGIiLCB3aGlj aCBsb29rcyBsaWtlIGEgYmFkIGNhc2Ugb2YgY29weSZwYXN0ZSB0byBtZS4KCkhvd2V2ZXIsICJ1 ZG9vLG5lby1iYXNpYyIsICJ1ZG9vLG5lbyIsICJmc2wsaW14NnN4IiBzaG91bGQgYmUgc3VmZmlj aWVudApzaW5jZSB1bmxpa2UgdGhlIFF1YWQvRHVhbCBzaXR1YXRpb24gdGhlcmUgaXMgbm8gU29D IHZhcmlhdGlvbiBoZXJlLiBPcgoic2Vjbyx1ZG9vLW5lbyI/ICJ1ZG9vLHVkb28tbmVvIiBsb29r cyBkdXBsaWNhdGUuCgo+PiArJmZlYzEgewo+PiArICAgICAgIHBpbmN0cmwtbmFtZXMgPSAiZGVm YXVsdCI7Cj4+ICsgICAgICAgcGluY3RybC0wID0gPCZwaW5jdHJsX2VuZXQxPjsKPj4gKyAgICAg ICBwaHktbW9kZSA9ICJybWlpIjsKPj4gKyAgICAgICBwaHktcmVzZXQtZ3Bpb3MgPSA8JmdwaW81 IDQgR1BJT19BQ1RJVkVfSElHSD47Cj4gCj4gU2hvdWxkbid0IHRoaXMgYmUgR1BJT19BQ1RJVkVf TE9XIGluc3RlYWQ/CgpIbSwgbmV0d29yayB3b3JrZWQgb2theSBmb3IgbWUgbGlrZSB0aGlzLCBo b3cgZG8gd2UgdmVyaWZ5PwoKU2NoZW1hdGljcyBhcmUgaGVyZTogaHR0cDovL3d3dy51ZG9vLm9y Zy9vdGhlci1yZXNvdXJjZXMvCgpUaGFua3MsCkFuZHJlYXMKCi0tIApTVVNFIExpbnV4IEdtYkgs IE1heGZlbGRzdHIuIDUsIDkwNDA5IE7DvHJuYmVyZywgR2VybWFueQpHRjogRmVsaXggSW1lbmTD tnJmZmVyLCBKYW5lIFNtaXRoYXJkLCBHcmFoYW0gTm9ydG9uCkhSQiAyMTI4NCAoQUcgTsO8cm5i ZXJnKQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlu dXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRl YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgt YXJtLWtlcm5lbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755009AbcGENzv (ORCPT ); Tue, 5 Jul 2016 09:55:51 -0400 Received: from mx2.suse.de ([195.135.220.15]:35653 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754431AbcGENz2 (ORCPT ); Tue, 5 Jul 2016 09:55:28 -0400 Subject: Re: [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support To: Fabio Estevam References: <1467691450-22975-1-git-send-email-afaerber@suse.de> <1467691450-22975-3-git-send-email-afaerber@suse.de> Cc: "linux-arm-kernel@lists.infradead.org" , Shawn Guo , Sascha Hauer , Fabio Estevam , Ettore Chimenti , Rob Herring , Mark Rutland , Russell King , devicetree , LKML From: =?UTF-8?Q?Andreas_F=c3=a4rber?= X-Enigmail-Draft-Status: N1110 Organization: SUSE Linux GmbH Message-ID: <577BBC4B.5040903@suse.de> Date: Tue, 5 Jul 2016 15:55:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Fabio, Am 05.07.2016 um 14:04 schrieb Fabio Estevam: > On Tue, Jul 5, 2016 at 1:04 AM, Andreas Färber wrote: > >> +/dts-v1/; >> + >> +#include "imx6sx-udoo-neo.dtsi" >> + >> +/ { >> + model = "UDOO Neo Basic"; > > This should be something like: > > model = "Udoo i.MX6 SoloX UDOO Neo Basic"; Why should anyone use such a weird concatenation of names? If you wanted "UDOO Neo Basic (based on i.MX 6SoloX)" that would be more understandable, but there is no UDOO Neo Basic board with another SoC: http://www.udoo.org/udoo-neo/ imx6dl-udoo.dts uses "Udoo i.MX6 Dual-lite Board" and imx6q-udoo.dts uses "Udoo i.MX6 Quad Board". So I'm open to discussing UDOO vs. Udoo spelling, but I don't see a requirement for mixing board vendor, SoC name and board name. /proc/cpuinfo displays "Freescale i.MX6 SoloX (Device Tree)" based on SoC compatible string and mach-imx/mach-imx6sx.c. Note that NXP calls it "i.MX6SX" or "i.MX 6SoloX" (spacing): http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-processors/i.mx-6-processors/i.mx6qp/i.mx-6solox-processors-heterogeneous-processing-with-arm-cortex-a9-and-cortex-m4-cores:i.MX6SX >> + compatible = "fsl,imx6sx"; > > compatible = "udoo,imx6sx-udoo-neo", "fsl,imx6sx"; > > Then you can also send a separate patch to add udoo to > Documentation/devicetree/bindings/vendor-prefixes.txt. > > Same applies to other places in this patch. I know we could add compatibles. But you say it backwards: If I add a compatible string the vendor _must_ be defined in vendor-prefixes.txt and the board compatible _must_ be documented, too. Since I saw that there is no prefix for UDOO in vendor-prefixes.txt nor an arm/udoo.txt file to document its board compatibles _despite_ "udoo,imx6q-udoo" and "udoo,imx6dl-udoo" being in use, as an annoyed UDOO Neo owner I'd rather leave it to UDOO to add those on their own as follow-up if they care. Their downstream kernel does not have such a compatible string, they use "fsl,imx6sx-sdb", which looks like a bad case of copy&paste to me. However, "udoo,neo-basic", "udoo,neo", "fsl,imx6sx" should be sufficient since unlike the Quad/Dual situation there is no SoC variation here. Or "seco,udoo-neo"? "udoo,udoo-neo" looks duplicate. >> +&fec1 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&pinctrl_enet1>; >> + phy-mode = "rmii"; >> + phy-reset-gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>; > > Shouldn't this be GPIO_ACTIVE_LOW instead? Hm, network worked okay for me like this, how do we verify? Schematics are here: http://www.udoo.org/other-resources/ Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)