* [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-24 9:48 ` Geert Uytterhoeven
0 siblings, 0 replies; 39+ messages in thread
From: Geert Uytterhoeven @ 2017-08-24 9:48 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-24 9:48 ` Geert Uytterhoeven
0 siblings, 0 replies; 39+ messages in thread
From: Geert Uytterhoeven @ 2017-08-24 9:48 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Simon Horman, Magnus Damm, Rob Herring, Mark Rutland,
Russell King, Linux-Renesas, devicetree, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
2017-08-24 9:48 ` Geert Uytterhoeven
@ 2017-08-24 11:46 ` jmondi
-1 siblings, 0 replies; 39+ messages in thread
From: jmondi @ 2017-08-24 11:46 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Simon Horman, Magnus Damm, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas, devicetree,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-24 11:46 ` jmondi
0 siblings, 0 replies; 39+ messages in thread
From: jmondi @ 2017-08-24 11:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
2017-08-24 11:46 ` jmondi
@ 2017-08-24 11:56 ` Geert Uytterhoeven
-1 siblings, 0 replies; 39+ messages in thread
From: Geert Uytterhoeven @ 2017-08-24 11:56 UTC (permalink / raw)
To: jmondi
Cc: Jacopo Mondi, Simon Horman, Magnus Damm, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas, devicetree,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-24 11:56 ` Geert Uytterhoeven
0 siblings, 0 replies; 39+ messages in thread
From: Geert Uytterhoeven @ 2017-08-24 11:56 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
2017-08-24 11:56 ` Geert Uytterhoeven
@ 2017-08-24 12:53 ` jmondi
-1 siblings, 0 replies; 39+ messages in thread
From: jmondi @ 2017-08-24 12:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jacopo Mondi, Simon Horman, Magnus Damm, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas, devicetree,
linux-arm-kernel
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-24 12:53 ` jmondi
0 siblings, 0 replies; 39+ messages in thread
From: jmondi @ 2017-08-24 12:53 UTC (permalink / raw)
To: linux-arm-kernel
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 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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
2017-08-24 12:53 ` jmondi
(?)
@ 2017-08-30 7:25 ` Simon Horman
-1 siblings, 0 replies; 39+ messages in thread
From: Simon Horman @ 2017-08-30 7:25 UTC (permalink / raw)
To: jmondi
Cc: Geert Uytterhoeven, Jacopo Mondi, Magnus Damm, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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.
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-30 7:25 ` Simon Horman
0 siblings, 0 replies; 39+ messages in thread
From: Simon Horman @ 2017-08-30 7:25 UTC (permalink / raw)
To: linux-arm-kernel
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 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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-30 7:25 ` Simon Horman
0 siblings, 0 replies; 39+ messages in thread
From: Simon Horman @ 2017-08-30 7:25 UTC (permalink / raw)
To: jmondi
Cc: Geert Uytterhoeven, Jacopo Mondi, Magnus Damm, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas, devicetree,
linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
2017-08-30 7:25 ` Simon Horman
@ 2017-08-30 7:35 ` jmondi
-1 siblings, 0 replies; 39+ messages in thread
From: jmondi @ 2017-08-30 7:35 UTC (permalink / raw)
To: Simon Horman
Cc: Geert Uytterhoeven, Jacopo Mondi, Magnus Damm, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas, devicetree,
linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-30 7:35 ` jmondi
0 siblings, 0 replies; 39+ messages in thread
From: jmondi @ 2017-08-30 7:35 UTC (permalink / raw)
To: linux-arm-kernel
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 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?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
2017-08-30 7:35 ` jmondi
(?)
@ 2017-08-30 9:28 ` Simon Horman
-1 siblings, 0 replies; 39+ messages in thread
From: Simon Horman @ 2017-08-30 9:28 UTC (permalink / raw)
To: jmondi
Cc: Geert Uytterhoeven, Jacopo Mondi, Magnus Damm, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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 :)
--
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-30 9:28 ` Simon Horman
0 siblings, 0 replies; 39+ messages in thread
From: Simon Horman @ 2017-08-30 9:28 UTC (permalink / raw)
To: linux-arm-kernel
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 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 :)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
@ 2017-08-30 9:28 ` Simon Horman
0 siblings, 0 replies; 39+ messages in thread
From: Simon Horman @ 2017-08-30 9:28 UTC (permalink / raw)
To: jmondi
Cc: Geert Uytterhoeven, Jacopo Mondi, Magnus Damm, Rob Herring,
Mark Rutland, Russell King, Linux-Renesas, devicetree,
linux-arm-kernel
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 :)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
2017-08-24 12:53 ` jmondi
(?)
(?)
@ 2017-09-14 15:59 ` jacopo mondi
2017-09-14 16:09 ` Chris Brandt
-1 siblings, 1 reply; 39+ messages in thread
From: jacopo mondi @ 2017-09-14 15:59 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Jacopo Mondi, Simon Horman, Magnus Damm, Linux-Renesas
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: [PATCH 3/4] arm: dts: gr-peach: Add ETHER pin group
2017-09-14 15:59 ` jacopo mondi
@ 2017-09-14 16:09 ` Chris Brandt
0 siblings, 0 replies; 39+ messages in thread
From: Chris Brandt @ 2017-09-14 16:09 UTC (permalink / raw)
To: jacopo mondi, Geert Uytterhoeven
Cc: Jacopo Mondi, Simon Horman, Magnus Damm, Linux-Renesas
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
^ permalink raw reply [flat|nested] 39+ messages in thread