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@xxxxxxxxxx> 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@xxxxxxxxxx>
> >
> > ---
> > 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@xxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
