GR-Peach DTS update

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

Signed-off-by Jacopo Mondi <[email protected]>

Add pin configuration subnode for SCIF2 serial debug interface.

Signed-off-by Jacopo Mondi <[email protected]>

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 <[email protected]>

---
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(+)

arch/arm/boot/dts/r7s72100-gr-peach.dts +11 -0

index bcfa644..5ce558f 100644
@@ -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  */

Hi Jacopo,

Quoted 45 lines · 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 <[email protected]>

---
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(+)

arch/arm/boot/dts/r7s72100-gr-peach.dts +15 -0

index bcfa644..5ce558f 100644
@@ -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  */

arch/arm/boot/dts/r7s72100-gr-peach.dts line 81

Quoted 6 lines

arch/arm/boot/dts/r7s72100-gr-peach.dts +6 -0

+                        <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

Quoted 18 lines · Geert Uytterhoeven

Quoted 6 lines · 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 <[email protected]>

Quoted 9 lines

---
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.

Quoted 1 line

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...

Hi Jacopo,

Quoted 5 lines

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.

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

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

Thanks Geert,

Quoted 2 lines · Geert Uytterhoeven

Hi Jacopo,

[snip]

Quoted 10 lines

Quoted 5 lines

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.

Quoted 3 lines

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?

Quoted 56 lines · jmondi

Thanks Geert,

Quoted 2 lines · Geert Uytterhoeven

Hi Jacopo,

[snip]

Quoted 10 lines

Quoted 5 lines

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.

Quoted 3 lines

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

Quoted 1 line

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.

Hi Simon,

Quoted 57 lines · Simon Horman

Quoted 56 lines · jmondi

Thanks Geert,

Quoted 2 lines · Geert Uytterhoeven

Hi Jacopo,

[snip]

Quoted 10 lines

Quoted 5 lines

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.

Quoted 3 lines

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

Quoted 6 lines

Quoted 1 line

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?

Thanks Geert,

Quoted 2 lines · Geert Uytterhoeven

Hi Jacopo,

[snip]

Quoted 10 lines

Quoted 5 lines

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

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?

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

Signed-off-by Jacopo Mondi <[email protected]>

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

Quoted 14 lines · 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.

Quoted 8 lines

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.