[PATCH 0/4] GR-Peach DTS update

[PATCH 0/4] GR-Peach DTS update

[Jacopo Mondi]

Hello Simon,
   now that RZ/A1 pin controller is merged, it's time to enable some peripheral
devices on GR-Peach has it has been done for Genmai and RSK boards.

The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
be defined in r7s72100.dtsi.

Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
traffic on that. I can set the ip address and probe the device and double
checked the pin configuration process against u-boot sources (where the
interface is working instead). Sending the patch anyway and let you decide what
to do with that.

Thanks
   j

Jacopo Mondi (4):
  arm: dts: gr-peach: Remove empty line
  arm: dts: gr-peach: Add SCIF2 pin group
  arm: dts: gr-peach: Add ETHER pin group
  arm: dts: gr-peach: Add user led device nodes

 arch/arm/boot/dts/r7s72100-gr-peach.dts | 57 ++++++++++++++++++++++++++++++++-
 1 file changed, 56 insertions(+), 1 deletion(-)

--
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] GR-Peach DTS update

[Jacopo Mondi]

Hello Simon,
   now that RZ/A1 pin controller is merged, it's time to enable some peripheral
devices on GR-Peach has it has been done for Genmai and RSK boards.

The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
be defined in r7s72100.dtsi.

Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
traffic on that. I can set the ip address and probe the device and double
checked the pin configuration process against u-boot sources (where the
interface is working instead). Sending the patch anyway and let you decide what
to do with that.

Thanks
   j

Jacopo Mondi (4):
  arm: dts: gr-peach: Remove empty line
  arm: dts: gr-peach: Add SCIF2 pin group
  arm: dts: gr-peach: Add ETHER pin group
  arm: dts: gr-peach: Add user led device nodes

 arch/arm/boot/dts/r7s72100-gr-peach.dts | 57 ++++++++++++++++++++++++++++++++-
 1 file changed, 56 insertions(+), 1 deletion(-)

--
2.7.4

[PATCH 1/4] arm: dts: gr-peach: Remove empty line

[Jacopo Mondi]

Remove an empty line in gr-peach device tree source file.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 arch/arm/boot/dts/r7s72100-gr-peach.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index a1b2aef9..1c40a1a 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -28,7 +28,6 @@
 	memory@20000000 {
 		device_type = "memory";
 		reg = <0x20000000 0x00a00000>;
-
 	};
 
 	lbsc {
-- 
2.7.4

[PATCH 2/4] arm: dts: gr-peach: Add SCIF2 pin group

[Jacopo Mondi]

Add pin configuration subnode for SCIF2 serial debug interface.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 arch/arm/boot/dts/r7s72100-gr-peach.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index 1c40a1a..bcfa644 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "r7s72100.dtsi"
+#include <dt-bindings/pinctrl/r7s72100-pinctrl.h>
 
 / {
 	model = "GR-Peach";
@@ -52,6 +53,13 @@
 	};
 };
 
+&pinctrl {
+	scif2_pins: serial2 {
+		/* P6_2 as RxD2; P6_3 as TxD2 */
+		pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
+	};
+};
+
 &extal_clk {
 	clock-frequency = <13333000>;
 };
@@ -61,5 +69,8 @@
 };
 
 &scif2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&scif2_pins>;
+
 	status = "okay";
 };
-- 
2.7.4

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Jacopo Mondi]

Add pin configuration subnode for ETHER pin group.
The interface can be configured and probed, but no traffic can be
transmitted or received.

Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>

---
When in u-boot console I can ping a connected host, after the
system has booted I can configure an ip address on the interface but
cannot exchange any traffic.
I have compared the pin configuration procedure with the u-boot
implemented one and some sketches from mbed operating system libraries,
the configured pins are correct and registers values seems to match.
Not sure if this patch should be sent for inclusion but sending it out
anyway for you to judge this.

Thanks
   j
---
 arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index bcfa644..5ce558f 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -58,6 +58,28 @@
 		/* P6_2 as RxD2; P6_3 as TxD2 */
 		pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
 	};
+
+	ether_pins: ether {
+		/* Ethernet on Ports 1,3,5,10 */
+		pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL   */
+			 <RZA1_PINMUX(3, 0, 2)>,  /* P3_0 = ET_TXCLK  */
+			 <RZA1_PINMUX(3, 3, 2)>,  /* P3_3 = ET_MDIO   */
+			 <RZA1_PINMUX(3, 4, 2)>,  /* P3_4 = ET_RXCLK  */
+			 <RZA1_PINMUX(3, 5, 2)>,  /* P3_5 = ET_RXER   */
+			 <RZA1_PINMUX(3, 6, 2)>,  /* P3_6 = ET_RXDV   */
+			 <RZA1_PINMUX(5, 9, 2)>,  /* P5_9 = ET_MDC    */
+			 <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER  */
+			 <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN  */
+			 <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS   */
+			 <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0  */
+			 <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1  */
+			 <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2  */
+			 <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3  */
+			 <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0  */
+			 <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1  */
+			 <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
+			 <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */
+	};
 };
 
 &extal_clk {
@@ -74,3 +96,16 @@
 
 	status = "okay";
 };
+
+&ether {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ether_pins>;
+
+	status = "okay";
+
+	renesas,no-ether-link;
+	phy-handle = <&phy0>;
+	phy0: ethernet-phy@0 {
+		reg = <0>;
+	};
+};
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Jacopo Mondi]

Add pin configuration subnode for ETHER pin group.
The interface can be configured and probed, but no traffic can be
transmitted or received.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

---
When in u-boot console I can ping a connected host, after the
system has booted I can configure an ip address on the interface but
cannot exchange any traffic.
I have compared the pin configuration procedure with the u-boot
implemented one and some sketches from mbed operating system libraries,
the configured pins are correct and registers values seems to match.
Not sure if this patch should be sent for inclusion but sending it out
anyway for you to judge this.

Thanks
   j
---
 arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index bcfa644..5ce558f 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -58,6 +58,28 @@
 		/* P6_2 as RxD2; P6_3 as TxD2 */
 		pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
 	};
+
+	ether_pins: ether {
+		/* Ethernet on Ports 1,3,5,10 */
+		pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL   */
+			 <RZA1_PINMUX(3, 0, 2)>,  /* P3_0 = ET_TXCLK  */
+			 <RZA1_PINMUX(3, 3, 2)>,  /* P3_3 = ET_MDIO   */
+			 <RZA1_PINMUX(3, 4, 2)>,  /* P3_4 = ET_RXCLK  */
+			 <RZA1_PINMUX(3, 5, 2)>,  /* P3_5 = ET_RXER   */
+			 <RZA1_PINMUX(3, 6, 2)>,  /* P3_6 = ET_RXDV   */
+			 <RZA1_PINMUX(5, 9, 2)>,  /* P5_9 = ET_MDC    */
+			 <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER  */
+			 <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN  */
+			 <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS   */
+			 <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0  */
+			 <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1  */
+			 <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2  */
+			 <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3  */
+			 <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0  */
+			 <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1  */
+			 <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
+			 <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */
+	};
 };
 
 &extal_clk {
@@ -74,3 +96,16 @@
 
 	status = "okay";
 };
+
+&ether {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ether_pins>;
+
+	status = "okay";
+
+	renesas,no-ether-link;
+	phy-handle = <&phy0>;
+	phy0: ethernet-phy@0 {
+		reg = <0>;
+	};
+};
-- 
2.7.4

[PATCH 4/4] arm: dts: gr-peach: Add user led device nodes

[Jacopo Mondi]

Add device nodes for user leds on gr-peach board.

Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
---
 arch/arm/boot/dts/r7s72100-gr-peach.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index 5ce558f..29ad54e 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "r7s72100.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/pinctrl/r7s72100-pinctrl.h>
 
 / {
@@ -51,6 +52,15 @@
 			reg = <0x00600000 0x00200000>;
 		};
 	};
+
+leds {
+		status = "okay";
+		compatible = "gpio-leds";
+
+		led1 {
+			gpios = <&port6 12 GPIO_ACTIVE_HIGH>;
+		};
+	};
 };
 
 &pinctrl {
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] arm: dts: gr-peach: Add user led device nodes

[Jacopo Mondi]

Add device nodes for user leds on gr-peach board.

Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
---
 arch/arm/boot/dts/r7s72100-gr-peach.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
index 5ce558f..29ad54e 100644
--- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
+++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
@@ -11,6 +11,7 @@
 
 /dts-v1/;
 #include "r7s72100.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/pinctrl/r7s72100-pinctrl.h>
 
 / {
@@ -51,6 +52,15 @@
 			reg = <0x00600000 0x00200000>;
 		};
 	};
+
+leds {
+		status = "okay";
+		compatible = "gpio-leds";
+
+		led1 {
+			gpios = <&port6 12 GPIO_ACTIVE_HIGH>;
+		};
+	};
 };
 
 &pinctrl {
-- 
2.7.4

Re: [PATCH 1/4] arm: dts: gr-peach: Remove empty line

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Remove an empty line in gr-peach device tree source file.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 1/4] arm: dts: gr-peach: Remove empty line

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Remove an empty line in gr-peach device tree source file.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/4] arm: dts: gr-peach: Add SCIF2 pin group

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add pin configuration subnode for SCIF2 serial debug interface.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 2/4] arm: dts: gr-peach: Add SCIF2 pin group

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add pin configuration subnode for SCIF2 serial debug interface.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 4/4] arm: dts: gr-peach: Add user led device nodes

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> Add device nodes for user leds on gr-peach board.

Singular? (also in the one-line summary)

> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] arm: dts: gr-peach: Add user led device nodes

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add device nodes for user leds on gr-peach board.

Singular? (also in the one-line summary)

> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 4/4] arm: dts: gr-peach: Add user led device nodes

[Geert Uytterhoeven]

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add device nodes for user leds on gr-peach board.

Singular? (also in the one-line summary)

> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org> wrote:
> Add pin configuration subnode for ETHER pin group.
> The interface can be configured and probed, but no traffic can be
> transmitted or received.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
>
> ---
> When in u-boot console I can ping a connected host, after the
> system has booted I can configure an ip address on the interface but
> cannot exchange any traffic.
> I have compared the pin configuration procedure with the u-boot
> implemented one and some sketches from mbed operating system libraries,
> the configured pins are correct and registers values seems to match.
> Not sure if this patch should be sent for inclusion but sending it out
> anyway for you to judge this.
>
> Thanks
>    j
> ---
>  arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> index bcfa644..5ce558f 100644
> --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> @@ -58,6 +58,28 @@
>                 /* P6_2 as RxD2; P6_3 as TxD2 */
>                 pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
>         };
> +
> +       ether_pins: ether {
> +               /* Ethernet on Ports 1,3,5,10 */
> +               pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL   */
> +                        <RZA1_PINMUX(3, 0, 2)>,  /* P3_0 = ET_TXCLK  */
> +                        <RZA1_PINMUX(3, 3, 2)>,  /* P3_3 = ET_MDIO   */
> +                        <RZA1_PINMUX(3, 4, 2)>,  /* P3_4 = ET_RXCLK  */
> +                        <RZA1_PINMUX(3, 5, 2)>,  /* P3_5 = ET_RXER   */
> +                        <RZA1_PINMUX(3, 6, 2)>,  /* P3_6 = ET_RXDV   */
> +                        <RZA1_PINMUX(5, 9, 2)>,  /* P5_9 = ET_MDC    */
> +                        <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER  */
> +                        <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN  */
> +                        <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS   */
> +                        <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0  */
> +                        <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1  */
> +                        <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2  */
> +                        <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3  */
> +                        <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0  */
> +                        <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1  */
> +                        <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
> +                        <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */

All OK, but do you need P4_2, which is used for ET_nRST?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add pin configuration subnode for ETHER pin group.
> The interface can be configured and probed, but no traffic can be
> transmitted or received.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> ---
> When in u-boot console I can ping a connected host, after the
> system has booted I can configure an ip address on the interface but
> cannot exchange any traffic.
> I have compared the pin configuration procedure with the u-boot
> implemented one and some sketches from mbed operating system libraries,
> the configured pins are correct and registers values seems to match.
> Not sure if this patch should be sent for inclusion but sending it out
> anyway for you to judge this.
>
> Thanks
>    j
> ---
>  arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> index bcfa644..5ce558f 100644
> --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> @@ -58,6 +58,28 @@
>                 /* P6_2 as RxD2; P6_3 as TxD2 */
>                 pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
>         };
> +
> +       ether_pins: ether {
> +               /* Ethernet on Ports 1,3,5,10 */
> +               pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL   */
> +                        <RZA1_PINMUX(3, 0, 2)>,  /* P3_0 = ET_TXCLK  */
> +                        <RZA1_PINMUX(3, 3, 2)>,  /* P3_3 = ET_MDIO   */
> +                        <RZA1_PINMUX(3, 4, 2)>,  /* P3_4 = ET_RXCLK  */
> +                        <RZA1_PINMUX(3, 5, 2)>,  /* P3_5 = ET_RXER   */
> +                        <RZA1_PINMUX(3, 6, 2)>,  /* P3_6 = ET_RXDV   */
> +                        <RZA1_PINMUX(5, 9, 2)>,  /* P5_9 = ET_MDC    */
> +                        <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER  */
> +                        <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN  */
> +                        <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS   */
> +                        <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0  */
> +                        <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1  */
> +                        <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2  */
> +                        <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3  */
> +                        <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0  */
> +                        <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1  */
> +                        <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
> +                        <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */

All OK, but do you need P4_2, which is used for ET_nRST?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
<jacopo+renesas@jmondi.org> wrote:
> Add pin configuration subnode for ETHER pin group.
> The interface can be configured and probed, but no traffic can be
> transmitted or received.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> ---
> When in u-boot console I can ping a connected host, after the
> system has booted I can configure an ip address on the interface but
> cannot exchange any traffic.
> I have compared the pin configuration procedure with the u-boot
> implemented one and some sketches from mbed operating system libraries,
> the configured pins are correct and registers values seems to match.
> Not sure if this patch should be sent for inclusion but sending it out
> anyway for you to judge this.
>
> Thanks
>    j
> ---
>  arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> index bcfa644..5ce558f 100644
> --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> @@ -58,6 +58,28 @@
>                 /* P6_2 as RxD2; P6_3 as TxD2 */
>                 pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
>         };
> +
> +       ether_pins: ether {
> +               /* Ethernet on Ports 1,3,5,10 */
> +               pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL   */
> +                        <RZA1_PINMUX(3, 0, 2)>,  /* P3_0 = ET_TXCLK  */
> +                        <RZA1_PINMUX(3, 3, 2)>,  /* P3_3 = ET_MDIO   */
> +                        <RZA1_PINMUX(3, 4, 2)>,  /* P3_4 = ET_RXCLK  */
> +                        <RZA1_PINMUX(3, 5, 2)>,  /* P3_5 = ET_RXER   */
> +                        <RZA1_PINMUX(3, 6, 2)>,  /* P3_6 = ET_RXDV   */
> +                        <RZA1_PINMUX(5, 9, 2)>,  /* P5_9 = ET_MDC    */
> +                        <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER  */
> +                        <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN  */
> +                        <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS   */
> +                        <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0  */
> +                        <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1  */
> +                        <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2  */
> +                        <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3  */
> +                        <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0  */
> +                        <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1  */
> +                        <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
> +                        <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */

All OK, but do you need P4_2, which is used for ET_nRST?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/4] GR-Peach DTS update

[Simon Horman]

On Thu, Aug 24, 2017 at 10:48:39AM +0200, Jacopo Mondi wrote:
> Hello Simon,
>    now that RZ/A1 pin controller is merged, it's time to enable some peripheral
> devices on GR-Peach has it has been done for Genmai and RSK boards.
> 
> The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
> be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
> be defined in r7s72100.dtsi.
> 
> Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
> traffic on that. I can set the ip address and probe the device and double
> checked the pin configuration process against u-boot sources (where the
> interface is working instead). Sending the patch anyway and let you decide what
> to do with that.
> 
> Thanks
>    j
> 
> Jacopo Mondi (4):
>   arm: dts: gr-peach: Remove empty line
>   arm: dts: gr-peach: Add SCIF2 pin group
>   arm: dts: gr-peach: Add ETHER pin group
>   arm: dts: gr-peach: Add user led device nodes

Thanks I have applied the 1st, 2nd and 4th (non-ETHER) patches above for v4.15.
I am leaving the 3rd (ETHER) patch pending resolution of the review
provided by Geert.

[PATCH 0/4] GR-Peach DTS update

[Simon Horman]

On Thu, Aug 24, 2017 at 10:48:39AM +0200, Jacopo Mondi wrote:
> Hello Simon,
>    now that RZ/A1 pin controller is merged, it's time to enable some peripheral
> devices on GR-Peach has it has been done for Genmai and RSK boards.
> 
> The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
> be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
> be defined in r7s72100.dtsi.
> 
> Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
> traffic on that. I can set the ip address and probe the device and double
> checked the pin configuration process against u-boot sources (where the
> interface is working instead). Sending the patch anyway and let you decide what
> to do with that.
> 
> Thanks
>    j
> 
> Jacopo Mondi (4):
>   arm: dts: gr-peach: Remove empty line
>   arm: dts: gr-peach: Add SCIF2 pin group
>   arm: dts: gr-peach: Add ETHER pin group
>   arm: dts: gr-peach: Add user led device nodes

Thanks I have applied the 1st, 2nd and 4th (non-ETHER) patches above for v4.15.
I am leaving the 3rd (ETHER) patch pending resolution of the review
provided by Geert.

Re: [PATCH 0/4] GR-Peach DTS update

[Simon Horman]

On Thu, Aug 24, 2017 at 06:53:50AM -0400, Simon Horman wrote:
> On Thu, Aug 24, 2017 at 10:48:39AM +0200, Jacopo Mondi wrote:
> > Hello Simon,
> >    now that RZ/A1 pin controller is merged, it's time to enable some peripheral
> > devices on GR-Peach has it has been done for Genmai and RSK boards.
> > 
> > The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
> > be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
> > be defined in r7s72100.dtsi.
> > 
> > Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
> > traffic on that. I can set the ip address and probe the device and double
> > checked the pin configuration process against u-boot sources (where the
> > interface is working instead). Sending the patch anyway and let you decide what
> > to do with that.
> > 
> > Thanks
> >    j
> > 
> > Jacopo Mondi (4):
> >   arm: dts: gr-peach: Remove empty line
> >   arm: dts: gr-peach: Add SCIF2 pin group
> >   arm: dts: gr-peach: Add ETHER pin group
> >   arm: dts: gr-peach: Add user led device nodes
> 
> Thanks I have applied the 1st, 2nd and 4th (non-ETHER) patches above for v4.15.
> I am leaving the 3rd (ETHER) patch pending resolution of the review
> provided by Geert.

BTW, the prefix these patches should start with "ARM:".
I fixed this when applying the patches described above.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] GR-Peach DTS update

[Simon Horman]

On Thu, Aug 24, 2017 at 06:53:50AM -0400, Simon Horman wrote:
> On Thu, Aug 24, 2017 at 10:48:39AM +0200, Jacopo Mondi wrote:
> > Hello Simon,
> >    now that RZ/A1 pin controller is merged, it's time to enable some peripheral
> > devices on GR-Peach has it has been done for Genmai and RSK boards.
> > 
> > The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
> > be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
> > be defined in r7s72100.dtsi.
> > 
> > Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
> > traffic on that. I can set the ip address and probe the device and double
> > checked the pin configuration process against u-boot sources (where the
> > interface is working instead). Sending the patch anyway and let you decide what
> > to do with that.
> > 
> > Thanks
> >    j
> > 
> > Jacopo Mondi (4):
> >   arm: dts: gr-peach: Remove empty line
> >   arm: dts: gr-peach: Add SCIF2 pin group
> >   arm: dts: gr-peach: Add ETHER pin group
> >   arm: dts: gr-peach: Add user led device nodes
> 
> Thanks I have applied the 1st, 2nd and 4th (non-ETHER) patches above for v4.15.
> I am leaving the 3rd (ETHER) patch pending resolution of the review
> provided by Geert.

BTW, the prefix these patches should start with "ARM:".
I fixed this when applying the patches described above.

[PATCH 0/4] GR-Peach DTS update

[Simon Horman]

On Thu, Aug 24, 2017 at 06:53:50AM -0400, Simon Horman wrote:
> On Thu, Aug 24, 2017 at 10:48:39AM +0200, Jacopo Mondi wrote:
> > Hello Simon,
> >    now that RZ/A1 pin controller is merged, it's time to enable some peripheral
> > devices on GR-Peach has it has been done for Genmai and RSK boards.
> > 
> > The series is based on Simon's "renesas-dt2-for-v4.14" tag release, so it should
> > be ideally applied after v4.14-rc1 is out, as it needs pin controller nodes to
> > be defined in r7s72100.dtsi.
> > 
> > Patch 2/4 enables EHTER interface, even if I've not been able to exchange any
> > traffic on that. I can set the ip address and probe the device and double
> > checked the pin configuration process against u-boot sources (where the
> > interface is working instead). Sending the patch anyway and let you decide what
> > to do with that.
> > 
> > Thanks
> >    j
> > 
> > Jacopo Mondi (4):
> >   arm: dts: gr-peach: Remove empty line
> >   arm: dts: gr-peach: Add SCIF2 pin group
> >   arm: dts: gr-peach: Add ETHER pin group
> >   arm: dts: gr-peach: Add user led device nodes
> 
> Thanks I have applied the 1st, 2nd and 4th (non-ETHER) patches above for v4.15.
> I am leaving the 3rd (ETHER) patch pending resolution of the review
> provided by Geert.

BTW, the prefix these patches should start with "ARM:".
I fixed this when applying the patches described above.

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Hi Geert,

On Thu, Aug 24, 2017 at 11:48:14AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> > Add pin configuration subnode for ETHER pin group.
> > The interface can be configured and probed, but no traffic can be
> > transmitted or received.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > ---
> > When in u-boot console I can ping a connected host, after the
> > system has booted I can configure an ip address on the interface but
> > cannot exchange any traffic.
> > I have compared the pin configuration procedure with the u-boot
> > implemented one and some sketches from mbed operating system libraries,
> > the configured pins are correct and registers values seems to match.
> > Not sure if this patch should be sent for inclusion but sending it out
> > anyway for you to judge this.
> >
> > Thanks
> >    j
> > ---
> >  arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +++++++++++++++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > index bcfa644..5ce558f 100644
> > --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > @@ -58,6 +58,28 @@
> >                 /* P6_2 as RxD2; P6_3 as TxD2 */
> >                 pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
> >         };
> > +
> > +       ether_pins: ether {
> > +               /* Ethernet on Ports 1,3,5,10 */
> > +               pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL   */
> > +                        <RZA1_PINMUX(3, 0, 2)>,  /* P3_0 = ET_TXCLK  */
> > +                        <RZA1_PINMUX(3, 3, 2)>,  /* P3_3 = ET_MDIO   */
> > +                        <RZA1_PINMUX(3, 4, 2)>,  /* P3_4 = ET_RXCLK  */
> > +                        <RZA1_PINMUX(3, 5, 2)>,  /* P3_5 = ET_RXER   */
> > +                        <RZA1_PINMUX(3, 6, 2)>,  /* P3_6 = ET_RXDV   */
> > +                        <RZA1_PINMUX(5, 9, 2)>,  /* P5_9 = ET_MDC    */
> > +                        <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER  */
> > +                        <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN  */
> > +                        <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS   */
> > +                        <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0  */
> > +                        <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1  */
> > +                        <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2  */
> > +                        <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3  */
> > +                        <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0  */
> > +                        <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1  */
> > +                        <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
> > +                        <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */
>
> All OK, but do you need P4_2, which is used for ET_nRST?

I tried requesting the GPIO in the "ether" subnode and define it as
"active low", so that it is kept high during regular operations.
I have verified through register writes dump it is cycled just after
the gpio is requested, and this should reset the interface before the
actual sh_eth driver kicks in.

I haven't find any mention in device tree bindings documentation of a
"reset-gpio" property for sh_eth, in the code examples I've seen in
u-boot and mbed, the interface is reset before any actual
configuration is performed. I feel like that should be the place where
that gpio is requested and cycled...

Thanks
   j
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Hi Geert,

On Thu, Aug 24, 2017 at 11:48:14AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
> <jacopo+renesas@jmondi.org> wrote:
> > Add pin configuration subnode for ETHER pin group.
> > The interface can be configured and probed, but no traffic can be
> > transmitted or received.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> >
> > ---
> > When in u-boot console I can ping a connected host, after the
> > system has booted I can configure an ip address on the interface but
> > cannot exchange any traffic.
> > I have compared the pin configuration procedure with the u-boot
> > implemented one and some sketches from mbed operating system libraries,
> > the configured pins are correct and registers values seems to match.
> > Not sure if this patch should be sent for inclusion but sending it out
> > anyway for you to judge this.
> >
> > Thanks
> >    j
> > ---
> >  arch/arm/boot/dts/r7s72100-gr-peach.dts | 35 +++++++++++++++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/r7s72100-gr-peach.dts b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > index bcfa644..5ce558f 100644
> > --- a/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > +++ b/arch/arm/boot/dts/r7s72100-gr-peach.dts
> > @@ -58,6 +58,28 @@
> >                 /* P6_2 as RxD2; P6_3 as TxD2 */
> >                 pinmux = <RZA1_PINMUX(6, 2, 7)>, <RZA1_PINMUX(6, 3, 7)>;
> >         };
> > +
> > +       ether_pins: ether {
> > +               /* Ethernet on Ports 1,3,5,10 */
> > +               pinmux = <RZA1_PINMUX(1, 14, 4)>, /* P1_14 = ET_COL   */
> > +                        <RZA1_PINMUX(3, 0, 2)>,  /* P3_0 = ET_TXCLK  */
> > +                        <RZA1_PINMUX(3, 3, 2)>,  /* P3_3 = ET_MDIO   */
> > +                        <RZA1_PINMUX(3, 4, 2)>,  /* P3_4 = ET_RXCLK  */
> > +                        <RZA1_PINMUX(3, 5, 2)>,  /* P3_5 = ET_RXER   */
> > +                        <RZA1_PINMUX(3, 6, 2)>,  /* P3_6 = ET_RXDV   */
> > +                        <RZA1_PINMUX(5, 9, 2)>,  /* P5_9 = ET_MDC    */
> > +                        <RZA1_PINMUX(10, 1, 4)>, /* P10_1 = ET_TXER  */
> > +                        <RZA1_PINMUX(10, 2, 4)>, /* P10_2 = ET_TXEN  */
> > +                        <RZA1_PINMUX(10, 3, 4)>, /* P10_3 = ET_CRS   */
> > +                        <RZA1_PINMUX(10, 4, 4)>, /* P10_4 = ET_TXD0  */
> > +                        <RZA1_PINMUX(10, 5, 4)>, /* P10_5 = ET_TXD1  */
> > +                        <RZA1_PINMUX(10, 6, 4)>, /* P10_6 = ET_TXD2  */
> > +                        <RZA1_PINMUX(10, 7, 4)>, /* P10_7 = ET_TXD3  */
> > +                        <RZA1_PINMUX(10, 8, 4)>, /* P10_8 = ET_RXD0  */
> > +                        <RZA1_PINMUX(10, 9, 4)>, /* P10_9 = ET_RXD1  */
> > +                        <RZA1_PINMUX(10, 10, 4)>,/* P10_10 = ET_RXD2 */
> > +                        <RZA1_PINMUX(10, 11, 4)>;/* P10_11 = ET_RXD3 */
>
> All OK, but do you need P4_2, which is used for ET_nRST?

I tried requesting the GPIO in the "ether" subnode and define it as
"active low", so that it is kept high during regular operations.
I have verified through register writes dump it is cycled just after
the gpio is requested, and this should reset the interface before the
actual sh_eth driver kicks in.

I haven't find any mention in device tree bindings documentation of a
"reset-gpio" property for sh_eth, in the code examples I've seen in
u-boot and mbed, the interface is reset before any actual
configuration is performed. I feel like that should be the place where
that gpio is requested and cycled...

Thanks
   j
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Aug 24, 2017 at 1:46 PM, jmondi <jacopo@jmondi.org> wrote:
> On Thu, Aug 24, 2017 at 11:48:14AM +0200, Geert Uytterhoeven wrote:
>> On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
>> <jacopo+renesas@jmondi.org> wrote:
>> > Add pin configuration subnode for ETHER pin group.
>> > The interface can be configured and probed, but no traffic can be
>> > transmitted or received.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>> >
>> > ---
>> > When in u-boot console I can ping a connected host, after the
>> > system has booted I can configure an ip address on the interface but
>> > cannot exchange any traffic.
>> > I have compared the pin configuration procedure with the u-boot
>> > implemented one and some sketches from mbed operating system libraries,
>> > the configured pins are correct and registers values seems to match.
>> > Not sure if this patch should be sent for inclusion but sending it out
>> > anyway for you to judge this.

>> All OK, but do you need P4_2, which is used for ET_nRST?
>
> I tried requesting the GPIO in the "ether" subnode and define it as
> "active low", so that it is kept high during regular operations.
> I have verified through register writes dump it is cycled just after
> the gpio is requested, and this should reset the interface before the
> actual sh_eth driver kicks in.
>
> I haven't find any mention in device tree bindings documentation of a
> "reset-gpio" property for sh_eth, in the code examples I've seen in
> u-boot and mbed, the interface is reset before any actual
> configuration is performed. I feel like that should be the place where
> that gpio is requested and cycled...

Documentation/devicetree/bindings/net/mdio.txt says

These are generic properties that can apply to any MDIO bus.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Geert Uytterhoeven]

Hi Jacopo,

On Thu, Aug 24, 2017 at 1:46 PM, jmondi <jacopo@jmondi.org> wrote:
> On Thu, Aug 24, 2017 at 11:48:14AM +0200, Geert Uytterhoeven wrote:
>> On Thu, Aug 24, 2017 at 10:48 AM, Jacopo Mondi
>> <jacopo+renesas@jmondi.org> wrote:
>> > Add pin configuration subnode for ETHER pin group.
>> > The interface can be configured and probed, but no traffic can be
>> > transmitted or received.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>> >
>> > ---
>> > When in u-boot console I can ping a connected host, after the
>> > system has booted I can configure an ip address on the interface but
>> > cannot exchange any traffic.
>> > I have compared the pin configuration procedure with the u-boot
>> > implemented one and some sketches from mbed operating system libraries,
>> > the configured pins are correct and registers values seems to match.
>> > Not sure if this patch should be sent for inclusion but sending it out
>> > anyway for you to judge this.

>> All OK, but do you need P4_2, which is used for ET_nRST?
>
> I tried requesting the GPIO in the "ether" subnode and define it as
> "active low", so that it is kept high during regular operations.
> I have verified through register writes dump it is cycled just after
> the gpio is requested, and this should reset the interface before the
> actual sh_eth driver kicks in.
>
> I haven't find any mention in device tree bindings documentation of a
> "reset-gpio" property for sh_eth, in the code examples I've seen in
> u-boot and mbed, the interface is reset before any actual
> configuration is performed. I feel like that should be the place where
> that gpio is requested and cycled...

Documentation/devicetree/bindings/net/mdio.txt says

These are generic properties that can apply to any MDIO bus.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Thanks Geert,

On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>

[snip]

> > I haven't find any mention in device tree bindings documentation of a
> > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > u-boot and mbed, the interface is reset before any actual
> > configuration is performed. I feel like that should be the place where
> > that gpio is requested and cycled...
>
> Documentation/devicetree/bindings/net/mdio.txt says
>
> These are generic properties that can apply to any MDIO bus.
>

I have now used mdio defined generic properties

&ether {
	pinctrl-names = "default";
	pinctrl-0 = <&ether_pins>;

	status = "okay";

	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
	reset-delay-us = <5>;

	renesas,no-ether-link;
	phy-handle = <&phy0>;
	phy0: ethernet-phy@0 {
               reg = <0>;
	};
};

I see the gpio being cycled, but same results as before: device gets
probed, address set, but I cannot ping, device gets probed, address
gets set, but I cannot ping

--- target ---
[    0.000000] libphy: sh_mii: probed
[    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.

# ifconfig eth0 192.168.100.50
[    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)

--- host ---
$ping 192.168.100.50
PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable


Let's leave this out of the DTS series I've just sent for now, ok?

Thanks
   j

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Thanks Geert,

On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>

[snip]

> > I haven't find any mention in device tree bindings documentation of a
> > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > u-boot and mbed, the interface is reset before any actual
> > configuration is performed. I feel like that should be the place where
> > that gpio is requested and cycled...
>
> Documentation/devicetree/bindings/net/mdio.txt says
>
> These are generic properties that can apply to any MDIO bus.
>

I have now used mdio defined generic properties

&ether {
	pinctrl-names = "default";
	pinctrl-0 = <&ether_pins>;

	status = "okay";

	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
	reset-delay-us = <5>;

	renesas,no-ether-link;
	phy-handle = <&phy0>;
	phy0: ethernet-phy at 0 {
               reg = <0>;
	};
};

I see the gpio being cycled, but same results as before: device gets
probed, address set, but I cannot ping, device gets probed, address
gets set, but I cannot ping

--- target ---
[    0.000000] libphy: sh_mii: probed
[    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.

# ifconfig eth0 192.168.100.50
[    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)

--- host ---
$ping 192.168.100.50
PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
>From 192.168.100.18 icmp_seq=1 Destination Host Unreachable


Let's leave this out of the DTS series I've just sent for now, ok?

Thanks
   j

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Simon Horman]

On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> Thanks Geert,
> 
> On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
> 
> [snip]
> 
> > > I haven't find any mention in device tree bindings documentation of a
> > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > u-boot and mbed, the interface is reset before any actual
> > > configuration is performed. I feel like that should be the place where
> > > that gpio is requested and cycled...
> >
> > Documentation/devicetree/bindings/net/mdio.txt says
> >
> > These are generic properties that can apply to any MDIO bus.
> >
> 
> I have now used mdio defined generic properties
> 
> &ether {
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&ether_pins>;
> 
> 	status = "okay";
> 
> 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> 	reset-delay-us = <5>;
> 
> 	renesas,no-ether-link;
> 	phy-handle = <&phy0>;
> 	phy0: ethernet-phy@0 {
>                reg = <0>;
> 	};
> };
> 
> I see the gpio being cycled, but same results as before: device gets
> probed, address set, but I cannot ping, device gets probed, address
> gets set, but I cannot ping
> 
> --- target ---
> [    0.000000] libphy: sh_mii: probed
> [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> 
> # ifconfig eth0 192.168.100.50
> [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> 
> --- host ---
> $ping 192.168.100.50
> PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> 
> 
> Let's leave this out of the DTS series I've just sent for now, ok?

I'm a little confused by this. Am I right in thinking that you don't want
this patch applied at this time and may resubmit it or an updated version
later? With that understanding I have marked it as "Rejected" for now. Feel
free to resubmit when you are ready.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Simon Horman]

On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> Thanks Geert,
> 
> On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
> 
> [snip]
> 
> > > I haven't find any mention in device tree bindings documentation of a
> > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > u-boot and mbed, the interface is reset before any actual
> > > configuration is performed. I feel like that should be the place where
> > > that gpio is requested and cycled...
> >
> > Documentation/devicetree/bindings/net/mdio.txt says
> >
> > These are generic properties that can apply to any MDIO bus.
> >
> 
> I have now used mdio defined generic properties
> 
> &ether {
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&ether_pins>;
> 
> 	status = "okay";
> 
> 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> 	reset-delay-us = <5>;
> 
> 	renesas,no-ether-link;
> 	phy-handle = <&phy0>;
> 	phy0: ethernet-phy@0 {
>                reg = <0>;
> 	};
> };
> 
> I see the gpio being cycled, but same results as before: device gets
> probed, address set, but I cannot ping, device gets probed, address
> gets set, but I cannot ping
> 
> --- target ---
> [    0.000000] libphy: sh_mii: probed
> [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> 
> # ifconfig eth0 192.168.100.50
> [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> 
> --- host ---
> $ping 192.168.100.50
> PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> 
> 
> Let's leave this out of the DTS series I've just sent for now, ok?

I'm a little confused by this. Am I right in thinking that you don't want
this patch applied at this time and may resubmit it or an updated version
later? With that understanding I have marked it as "Rejected" for now. Feel
free to resubmit when you are ready.

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Simon Horman]

On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> Thanks Geert,
> 
> On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
> 
> [snip]
> 
> > > I haven't find any mention in device tree bindings documentation of a
> > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > u-boot and mbed, the interface is reset before any actual
> > > configuration is performed. I feel like that should be the place where
> > > that gpio is requested and cycled...
> >
> > Documentation/devicetree/bindings/net/mdio.txt says
> >
> > These are generic properties that can apply to any MDIO bus.
> >
> 
> I have now used mdio defined generic properties
> 
> &ether {
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&ether_pins>;
> 
> 	status = "okay";
> 
> 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> 	reset-delay-us = <5>;
> 
> 	renesas,no-ether-link;
> 	phy-handle = <&phy0>;
> 	phy0: ethernet-phy at 0 {
>                reg = <0>;
> 	};
> };
> 
> I see the gpio being cycled, but same results as before: device gets
> probed, address set, but I cannot ping, device gets probed, address
> gets set, but I cannot ping
> 
> --- target ---
> [    0.000000] libphy: sh_mii: probed
> [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> 
> # ifconfig eth0 192.168.100.50
> [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> 
> --- host ---
> $ping 192.168.100.50
> PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> 
> 
> Let's leave this out of the DTS series I've just sent for now, ok?

I'm a little confused by this. Am I right in thinking that you don't want
this patch applied at this time and may resubmit it or an updated version
later? With that understanding I have marked it as "Rejected" for now. Feel
free to resubmit when you are ready.

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Hi Simon,

On Wed, Aug 30, 2017 at 09:25:42AM +0200, Simon Horman wrote:
> On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> > Thanks Geert,
> >
> > On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > > Hi Jacopo,
> > >
> >
> > [snip]
> >
> > > > I haven't find any mention in device tree bindings documentation of a
> > > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > > u-boot and mbed, the interface is reset before any actual
> > > > configuration is performed. I feel like that should be the place where
> > > > that gpio is requested and cycled...
> > >
> > > Documentation/devicetree/bindings/net/mdio.txt says
> > >
> > > These are generic properties that can apply to any MDIO bus.
> > >
> >
> > I have now used mdio defined generic properties
> >
> > &ether {
> > 	pinctrl-names = "default";
> > 	pinctrl-0 = <&ether_pins>;
> >
> > 	status = "okay";
> >
> > 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > 	reset-delay-us = <5>;
> >
> > 	renesas,no-ether-link;
> > 	phy-handle = <&phy0>;
> > 	phy0: ethernet-phy@0 {
> >                reg = <0>;
> > 	};
> > };
> >
> > I see the gpio being cycled, but same results as before: device gets
> > probed, address set, but I cannot ping, device gets probed, address
> > gets set, but I cannot ping
> >
> > --- target ---
> > [    0.000000] libphy: sh_mii: probed
> > [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> >
> > # ifconfig eth0 192.168.100.50
> > [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> >
> > --- host ---
> > $ping 192.168.100.50
> > PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >
> >
> > Let's leave this out of the DTS series I've just sent for now, ok?
>
> I'm a little confused by this. Am I right in thinking that you don't want
> this patch applied at this time and may resubmit it or an updated version
> later? With that understanding I have marked it as "Rejected" for now. Feel
> free to resubmit when you are ready.

Yes please, you got me right here.

Even if pix muxing is performed "correctly", and I can set ip address
and probe the interface, not traffic can be exchanged on it.

For this reason, let's not enable it at this time

Is this fine?

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jmondi]

Hi Simon,

On Wed, Aug 30, 2017 at 09:25:42AM +0200, Simon Horman wrote:
> On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> > Thanks Geert,
> >
> > On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > > Hi Jacopo,
> > >
> >
> > [snip]
> >
> > > > I haven't find any mention in device tree bindings documentation of a
> > > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > > u-boot and mbed, the interface is reset before any actual
> > > > configuration is performed. I feel like that should be the place where
> > > > that gpio is requested and cycled...
> > >
> > > Documentation/devicetree/bindings/net/mdio.txt says
> > >
> > > These are generic properties that can apply to any MDIO bus.
> > >
> >
> > I have now used mdio defined generic properties
> >
> > &ether {
> > 	pinctrl-names = "default";
> > 	pinctrl-0 = <&ether_pins>;
> >
> > 	status = "okay";
> >
> > 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > 	reset-delay-us = <5>;
> >
> > 	renesas,no-ether-link;
> > 	phy-handle = <&phy0>;
> > 	phy0: ethernet-phy at 0 {
> >                reg = <0>;
> > 	};
> > };
> >
> > I see the gpio being cycled, but same results as before: device gets
> > probed, address set, but I cannot ping, device gets probed, address
> > gets set, but I cannot ping
> >
> > --- target ---
> > [    0.000000] libphy: sh_mii: probed
> > [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> >
> > # ifconfig eth0 192.168.100.50
> > [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> >
> > --- host ---
> > $ping 192.168.100.50
> > PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> >
> >
> > Let's leave this out of the DTS series I've just sent for now, ok?
>
> I'm a little confused by this. Am I right in thinking that you don't want
> this patch applied at this time and may resubmit it or an updated version
> later? With that understanding I have marked it as "Rejected" for now. Feel
> free to resubmit when you are ready.

Yes please, you got me right here.

Even if pix muxing is performed "correctly", and I can set ip address
and probe the interface, not traffic can be exchanged on it.

For this reason, let's not enable it at this time

Is this fine?

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Simon Horman]

On Wed, Aug 30, 2017 at 09:35:28AM +0200, jmondi wrote:
> Hi Simon,
> 
> On Wed, Aug 30, 2017 at 09:25:42AM +0200, Simon Horman wrote:
> > On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> > > Thanks Geert,
> > >
> > > On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > > > Hi Jacopo,
> > > >
> > >
> > > [snip]
> > >
> > > > > I haven't find any mention in device tree bindings documentation of a
> > > > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > > > u-boot and mbed, the interface is reset before any actual
> > > > > configuration is performed. I feel like that should be the place where
> > > > > that gpio is requested and cycled...
> > > >
> > > > Documentation/devicetree/bindings/net/mdio.txt says
> > > >
> > > > These are generic properties that can apply to any MDIO bus.
> > > >
> > >
> > > I have now used mdio defined generic properties
> > >
> > > &ether {
> > > 	pinctrl-names = "default";
> > > 	pinctrl-0 = <&ether_pins>;
> > >
> > > 	status = "okay";
> > >
> > > 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > > 	reset-delay-us = <5>;
> > >
> > > 	renesas,no-ether-link;
> > > 	phy-handle = <&phy0>;
> > > 	phy0: ethernet-phy@0 {
> > >                reg = <0>;
> > > 	};
> > > };
> > >
> > > I see the gpio being cycled, but same results as before: device gets
> > > probed, address set, but I cannot ping, device gets probed, address
> > > gets set, but I cannot ping
> > >
> > > --- target ---
> > > [    0.000000] libphy: sh_mii: probed
> > > [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> > >
> > > # ifconfig eth0 192.168.100.50
> > > [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> > >
> > > --- host ---
> > > $ping 192.168.100.50
> > > PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >
> > >
> > > Let's leave this out of the DTS series I've just sent for now, ok?
> >
> > I'm a little confused by this. Am I right in thinking that you don't want
> > this patch applied at this time and may resubmit it or an updated version
> > later? With that understanding I have marked it as "Rejected" for now. Feel
> > free to resubmit when you are ready.
> 
> Yes please, you got me right here.
> 
> Even if pix muxing is performed "correctly", and I can set ip address
> and probe the interface, not traffic can be exchanged on it.
> 
> For this reason, let's not enable it at this time
> 
> Is this fine?

Yes, that is fine. Lets not enable things that don't work :)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Simon Horman]

On Wed, Aug 30, 2017 at 09:35:28AM +0200, jmondi wrote:
> Hi Simon,
> 
> On Wed, Aug 30, 2017 at 09:25:42AM +0200, Simon Horman wrote:
> > On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> > > Thanks Geert,
> > >
> > > On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > > > Hi Jacopo,
> > > >
> > >
> > > [snip]
> > >
> > > > > I haven't find any mention in device tree bindings documentation of a
> > > > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > > > u-boot and mbed, the interface is reset before any actual
> > > > > configuration is performed. I feel like that should be the place where
> > > > > that gpio is requested and cycled...
> > > >
> > > > Documentation/devicetree/bindings/net/mdio.txt says
> > > >
> > > > These are generic properties that can apply to any MDIO bus.
> > > >
> > >
> > > I have now used mdio defined generic properties
> > >
> > > &ether {
> > > 	pinctrl-names = "default";
> > > 	pinctrl-0 = <&ether_pins>;
> > >
> > > 	status = "okay";
> > >
> > > 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > > 	reset-delay-us = <5>;
> > >
> > > 	renesas,no-ether-link;
> > > 	phy-handle = <&phy0>;
> > > 	phy0: ethernet-phy@0 {
> > >                reg = <0>;
> > > 	};
> > > };
> > >
> > > I see the gpio being cycled, but same results as before: device gets
> > > probed, address set, but I cannot ping, device gets probed, address
> > > gets set, but I cannot ping
> > >
> > > --- target ---
> > > [    0.000000] libphy: sh_mii: probed
> > > [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> > >
> > > # ifconfig eth0 192.168.100.50
> > > [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> > >
> > > --- host ---
> > > $ping 192.168.100.50
> > > PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >
> > >
> > > Let's leave this out of the DTS series I've just sent for now, ok?
> >
> > I'm a little confused by this. Am I right in thinking that you don't want
> > this patch applied at this time and may resubmit it or an updated version
> > later? With that understanding I have marked it as "Rejected" for now. Feel
> > free to resubmit when you are ready.
> 
> Yes please, you got me right here.
> 
> Even if pix muxing is performed "correctly", and I can set ip address
> and probe the interface, not traffic can be exchanged on it.
> 
> For this reason, let's not enable it at this time
> 
> Is this fine?

Yes, that is fine. Lets not enable things that don't work :)

[PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Simon Horman]

On Wed, Aug 30, 2017 at 09:35:28AM +0200, jmondi wrote:
> Hi Simon,
> 
> On Wed, Aug 30, 2017 at 09:25:42AM +0200, Simon Horman wrote:
> > On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> > > Thanks Geert,
> > >
> > > On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > > > Hi Jacopo,
> > > >
> > >
> > > [snip]
> > >
> > > > > I haven't find any mention in device tree bindings documentation of a
> > > > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > > > u-boot and mbed, the interface is reset before any actual
> > > > > configuration is performed. I feel like that should be the place where
> > > > > that gpio is requested and cycled...
> > > >
> > > > Documentation/devicetree/bindings/net/mdio.txt says
> > > >
> > > > These are generic properties that can apply to any MDIO bus.
> > > >
> > >
> > > I have now used mdio defined generic properties
> > >
> > > &ether {
> > > 	pinctrl-names = "default";
> > > 	pinctrl-0 = <&ether_pins>;
> > >
> > > 	status = "okay";
> > >
> > > 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> > > 	reset-delay-us = <5>;
> > >
> > > 	renesas,no-ether-link;
> > > 	phy-handle = <&phy0>;
> > > 	phy0: ethernet-phy at 0 {
> > >                reg = <0>;
> > > 	};
> > > };
> > >
> > > I see the gpio being cycled, but same results as before: device gets
> > > probed, address set, but I cannot ping, device gets probed, address
> > > gets set, but I cannot ping
> > >
> > > --- target ---
> > > [    0.000000] libphy: sh_mii: probed
> > > [    0.000000] sh-eth e8203000.ethernet eth0: Base address at 0xe8203000, 68:14:97:20:97:00, IRQ 22.
> > >
> > > # ifconfig eth0 192.168.100.50
> > > [    0.000000] Generic PHY e8203000.ethernet-ffffffff:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e8203000.ethernet-f)
> > >
> > > --- host ---
> > > $ping 192.168.100.50
> > > PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > > >From 192.168.100.18 icmp_seq=1 Destination Host Unreachable
> > >
> > >
> > > Let's leave this out of the DTS series I've just sent for now, ok?
> >
> > I'm a little confused by this. Am I right in thinking that you don't want
> > this patch applied at this time and may resubmit it or an updated version
> > later? With that understanding I have marked it as "Rejected" for now. Feel
> > free to resubmit when you are ready.
> 
> Yes please, you got me right here.
> 
> Even if pix muxing is performed "correctly", and I can set ip address
> and probe the interface, not traffic can be exchanged on it.
> 
> For this reason, let's not enable it at this time
> 
> Is this fine?

Yes, that is fine. Lets not enable things that don't work :)

Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[jacopo mondi]

Hello Geert and Renesas-SoC list
 - devicetree
 - arm-linux

On Thu, Aug 24, 2017 at 02:53:59PM +0200, jmondi wrote:
> Thanks Geert,
>
> On Thu, Aug 24, 2017 at 01:56:16PM +0200, Geert Uytterhoeven wrote:
> > Hi Jacopo,
> >
>
> [snip]
>
> > > I haven't find any mention in device tree bindings documentation of a
> > > "reset-gpio" property for sh_eth, in the code examples I've seen in
> > > u-boot and mbed, the interface is reset before any actual
> > > configuration is performed. I feel like that should be the place where
> > > that gpio is requested and cycled...
> >
> > Documentation/devicetree/bindings/net/mdio.txt says
> >
> > These are generic properties that can apply to any MDIO bus.
> >
>
> I have now used mdio defined generic properties
>
> &ether {
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&ether_pins>;
>
> 	status = "okay";
>
> 	reset-gpios = <&port4 2 GPIO_ACTIVE_LOW>;
> 	reset-delay-us = <5>;
>
> 	renesas,no-ether-link;
> 	phy-handle = <&phy0>;
> 	phy0: ethernet-phy@0 {
>                reg = <0>;
> 	};
> };
>
> I see the gpio being cycled, but same results as before: device gets
> probed, address set, but I cannot ping, device gets probed, address
> gets set, but I cannot ping
>

I'm back on this with a few days of more hacking, and I'm here to ask
you a suggestion on how to proceed on this.

I'm still in a situation where I'm not able to send any frame on the
interface (I can receive them though), and several traces show me that
the sh_eth_start_xmit() function never gets called, probably because
of the interface being put in QDISC_STATE_DEACTIVATE by some upper
layers state machine.

Compared to my initial submission, I have now made sure the
correct PHY is identified, as the gr-peach uses a LAN8710a
transceiver.

I have the PHY correctly identified during phy initialization

SMSC LAN8710/LAN8720 e8203000.ethernet-ffffffff:00: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=e8203000.ethernet-ffffffff:00, irq=-1)

And I'm not worried by the "irq=-1" as Genmai has the same but Ethernet
works there...

This particular PHY has a nINTSEL pin that determinates if pin #18
has to be used as TxD4/TxERR of as interrupt signal nINT [1].
Compared to Genmai (and maybe other RZ devices) there is no interrupt
pin that goes from the PHY to the LSI, so I do now assume the only
option is to use TxD4 for this purpose (see P1_15 in Genmai schematics
[2])

gr-peach has a pull-up wired to nINTSEL pin [3] which makes me think
again that TxD4 pin is intended to be used as interrupt to the ETHER
interface (nINTSEL == Vdd -> use pin #18 as nINT signal).

Before going any further with this, I would like to better understand
if:

1) is an interrupt signal from PHY to ETHER mandatory? There is no
mention of in the ETHER pin description list of an interrupt pin, and
my understanding was the E-DMAC does not need any.
2) where is that interrupt pin described in dts for genmai and other
RZ devices?

Links to gr-peach schematics and LAN8710a datasheet (both publicly
available but uploaded here as I cannot retrieve links easily)
gr-peach: http://jmondi.org/owncloud/index.php/s/RbCvWCv9EWhtO9H
lan8710a: http://jmondi.org/owncloud/index.php/s/Its3RxdhfJtxc2n

Thanks
   j

[1] http://jmondi.org/owncloud/index.php/s/IH2vuCsGmoaqUL7
[2] http://jmondi.org/owncloud/index.php/s/qz6UZXUHPhQyMVm
[3] http://jmondi.org/owncloud/index.php/s/GAphEgxBXzbM2NI

RE: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group

[Chris Brandt]

Hi Jacopo,

On Thursday, September 14, 2017 1, linux-renesas-soc-owner@vger.kernel.org wrote:
> Before going any further with this, I would like to better understand
> if:
> 
> 1) is an interrupt signal from PHY to ETHER mandatory? There is no
> mention of in the ETHER pin description list of an interrupt pin, and
> my understanding was the E-DMAC does not need any.
> 2) where is that interrupt pin described in dts for genmai and other
> RZ devices?

I've never used that PHY interrupt pin on the RZ/A board. In fact, on 
some board, it's tied to a GPIO pin (not even an interrupt pin).

I guess in theory it could tell you when the cable has been 
connected/disconnected, but it does that now anyway (meaning the PHY
must be polled somehow).


Chris