| Message ID | 1503564523-31899-4-git-send-email-jacopo+renesas@jmondi.org (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Simon Horman |
| Headers | show |
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
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
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
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 ðer { pinctrl-names = "default"; pinctrl-0 = <ðer_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
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 > > ðer { > pinctrl-names = "default"; > pinctrl-0 = <ðer_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.
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 > > > > ðer { > > pinctrl-names = "default"; > > pinctrl-0 = <ðer_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?
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 > > > > > > ðer { > > > pinctrl-names = "default"; > > > pinctrl-0 = <ðer_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 :)
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 > > ðer { > pinctrl-names = "default"; > pinctrl-0 = <ðer_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
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
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"; }; + +ðer { + pinctrl-names = "default"; + pinctrl-0 = <ðer_pins>; + + status = "okay"; + + renesas,no-ether-link; + phy-handle = <&phy0>; + phy0: ethernet-phy@0 { + reg = <0>; + }; +};
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(+)