From: afaerber@suse.de (Andreas Färber)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support
Date: Tue, 5 Jul 2016 15:55:23 +0200 [thread overview]
Message-ID: <577BBC4B.5040903@suse.de> (raw)
In-Reply-To: <CAOMZO5CQWz++TVKBKEMSQuyks3C+7Tx5=Frh6R+Qubcab=EbjA@mail.gmail.com>
Hi Fabio,
Am 05.07.2016 um 14:04 schrieb Fabio Estevam:
> On Tue, Jul 5, 2016 at 1:04 AM, Andreas F?rber <afaerber@suse.de> 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)
WARNING: multiple messages have this Message-ID (diff)
From: "Andreas Färber" <afaerber@suse.de>
To: Fabio Estevam <festevam@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree <devicetree@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
LKML <linux-kernel@vger.kernel.org>,
Ettore Chimenti <ettore.chimenti@udoo.org>,
Rob Herring <robh+dt@kernel.org>,
Sascha Hauer <kernel@pengutronix.de>,
Fabio Estevam <fabio.estevam@nxp.com>,
Shawn Guo <shawnguo@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support
Date: Tue, 5 Jul 2016 15:55:23 +0200 [thread overview]
Message-ID: <577BBC4B.5040903@suse.de> (raw)
In-Reply-To: <CAOMZO5CQWz++TVKBKEMSQuyks3C+7Tx5=Frh6R+Qubcab=EbjA@mail.gmail.com>
Hi Fabio,
Am 05.07.2016 um 14:04 schrieb Fabio Estevam:
> On Tue, Jul 5, 2016 at 1:04 AM, Andreas Färber <afaerber@suse.de> 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)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: "Andreas Färber" <afaerber@suse.de>
To: Fabio Estevam <festevam@gmail.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <kernel@pengutronix.de>,
Fabio Estevam <fabio.estevam@nxp.com>,
Ettore Chimenti <ettore.chimenti@udoo.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Russell King <linux@armlinux.org.uk>,
devicetree <devicetree@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support
Date: Tue, 5 Jul 2016 15:55:23 +0200 [thread overview]
Message-ID: <577BBC4B.5040903@suse.de> (raw)
In-Reply-To: <CAOMZO5CQWz++TVKBKEMSQuyks3C+7Tx5=Frh6R+Qubcab=EbjA@mail.gmail.com>
Hi Fabio,
Am 05.07.2016 um 14:04 schrieb Fabio Estevam:
> On Tue, Jul 5, 2016 at 1:04 AM, Andreas Färber <afaerber@suse.de> 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)
next prev parent reply other threads:[~2016-07-05 13:55 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-05 4:04 [PATCH 0/3] ARM: dts: imx6sx: Initial UDOO Neo enablement Andreas Färber
2016-07-05 4:04 ` Andreas Färber
2016-07-05 4:04 ` [PATCH 1/3] ARM: dts: imx6sx-sabreauto: Fix misspelled property Andreas Färber
2016-07-05 4:04 ` Andreas Färber
2016-07-05 4:04 ` Andreas Färber
2016-07-05 8:54 ` Sudeep Holla
2016-07-05 8:54 ` Sudeep Holla
2016-07-05 8:54 ` Sudeep Holla
2016-08-08 13:58 ` Shawn Guo
2016-08-08 13:58 ` Shawn Guo
2016-08-08 13:58 ` Shawn Guo
2016-07-05 4:04 ` [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support Andreas Färber
2016-07-05 4:04 ` Andreas Färber
2016-07-05 4:04 ` Andreas Färber
2016-07-05 6:27 ` Uwe Kleine-König
2016-07-05 6:27 ` Uwe Kleine-König
2016-07-05 6:27 ` Uwe Kleine-König
2016-07-05 14:46 ` Andreas Färber
2016-07-05 14:46 ` Andreas Färber
2016-07-05 14:46 ` Andreas Färber
2016-07-05 12:04 ` Fabio Estevam
2016-07-05 12:04 ` Fabio Estevam
2016-07-05 12:04 ` Fabio Estevam
2016-07-05 13:55 ` Andreas Färber [this message]
2016-07-05 13:55 ` Andreas Färber
2016-07-05 13:55 ` Andreas Färber
2016-07-05 18:33 ` Uwe Kleine-König
2016-07-05 18:33 ` Uwe Kleine-König
2016-08-08 14:04 ` Shawn Guo
2016-08-08 14:04 ` Shawn Guo
2016-08-08 14:04 ` Shawn Guo
2016-07-05 4:04 ` [PATCH 3/3] ARM: dts: imx6sx-udoo-neo: Add SD Andreas Färber
2016-07-05 4:04 ` Andreas Färber
2016-07-05 4:04 ` Andreas Färber
2016-08-08 14:12 ` Shawn Guo
2016-08-08 14:12 ` Shawn Guo
2016-08-08 15:00 ` Andreas Färber
2016-08-08 15:00 ` Andreas Färber
2016-08-15 12:38 ` Shawn Guo
2016-08-15 12:38 ` Shawn Guo
2016-08-15 12:38 ` Shawn Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=577BBC4B.5040903@suse.de \
--to=afaerber@suse.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.