All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	David Jander <david@protonic.nl>,
	"David S. Miller" <davem@davemloft.net>,
	Sascha Hauer <kernel@pengutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	Philippe Schenker <philippe.schenker@toradex.com>,
	Russell King <linux@armlinux.org.uk>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH net-next v3] net: phy: micrel: add phy-mode support for the KSZ9031 PHY
Date: Tue, 28 Apr 2020 17:28:30 +0200	[thread overview]
Message-ID: <CAMuHMdU1ZmSm_tjtWxoFNako2fzmranGVz5qqD2YRNEFRjX0Sw@mail.gmail.com> (raw)
In-Reply-To: <20200422072137.8517-1-o.rempel@pengutronix.de>

Hi Oleksij,

On Wed, Apr 22, 2020 at 9:24 AM Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> Add support for following phy-modes: rgmii, rgmii-id, rgmii-txid, rgmii-rxid.
>
> This PHY has an internal RX delay of 1.2ns and no delay for TX.
>
> The pad skew registers allow to set the total TX delay to max 1.38ns and
> the total RX delay to max of 2.58ns (configurable 1.38ns + build in
> 1.2ns) and a minimal delay of 0ns.
>
> According to the RGMII v1.3 specification the delay provided by PCB traces
> should be between 1.5ns and 2.0ns. The RGMII v2.0 allows to provide this
> delay by MAC or PHY. So, we configure this PHY to the best values we can
> get by this HW: TX delay to 1.38ns (max supported value) and RX delay to
> 1.80ns (best calculated delay)
>
> The phy-modes can still be fine tuned/overwritten by *-skew-ps
> device tree properties described in:
> Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>

This is now commit bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode
support for the KSZ9031 PHY") in net-next/master.

> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c

> @@ -597,21 +703,33 @@ static int ksz9031_config_init(struct phy_device *phydev)
>         } while (!of_node && dev_walker);
>
>         if (of_node) {
> +               bool update = false;
> +
> +               if (phy_interface_is_rgmii(phydev)) {
> +                       result = ksz9031_config_rgmii_delay(phydev);
> +                       if (result < 0)
> +                               return result;
> +               }
> +
>                 ksz9031_of_load_skew_values(phydev, of_node,
>                                 MII_KSZ9031RN_CLK_PAD_SKEW, 5,
> -                               clk_skews, 2);
> +                               clk_skews, 2, &update);
>
>                 ksz9031_of_load_skew_values(phydev, of_node,
>                                 MII_KSZ9031RN_CONTROL_PAD_SKEW, 4,
> -                               control_skews, 2);
> +                               control_skews, 2, &update);
>
>                 ksz9031_of_load_skew_values(phydev, of_node,
>                                 MII_KSZ9031RN_RX_DATA_PAD_SKEW, 4,
> -                               rx_data_skews, 4);
> +                               rx_data_skews, 4, &update);
>
>                 ksz9031_of_load_skew_values(phydev, of_node,
>                                 MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
> -                               tx_data_skews, 4);
> +                               tx_data_skews, 4, &update);
> +
> +               if (update && phydev->interface != PHY_INTERFACE_MODE_RGMII)
> +                       phydev_warn(phydev,
> +                                   "*-skew-ps values should be used only with phy-mode = \"rgmii\"\n");

This triggers on Renesas Salvator-X(S):

    Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00:
*-skew-ps values should be used only with phy-mode = "rgmii"

which uses:

        phy-mode = "rgmii-txid";

and:

        rxc-skew-ps = <1500>;

If I understand Documentation/devicetree/bindings/net/ethernet-controller.yaml
correctly:

      # RX and TX delays are added by the MAC when required
      - rgmii

i.e. any *-skew-ps can be specified.

      # RGMII with internal RX and TX delays provided by the PHY,
      # the MAC should not add the RX or TX delays in this case
      - rgmii-id

i.e. *-skew-ps must not be specified.

      # RGMII with internal RX delay provided by the PHY, the MAC
      # should not add an RX delay in this case
      - rgmii-rxid

i.e. it's still OK to specify tx*-skew-ps values here...

      # RGMII with internal TX delay provided by the PHY, the MAC
      # should not add an TX delay in this case
      - rgmii-txid

... and rx*-skew-ps values here?
Is my understanding correct, and should the check be updated to take into
account rxid and txid?

BTW, the example in Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
still specifies *-skew-ps values with phy-mode = "rgmii-id", so I think
that should be updated, too.

Thanks!

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

  parent reply	other threads:[~2020-04-28 15:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22  7:21 [PATCH net-next v3] net: phy: micrel: add phy-mode support for the KSZ9031 PHY Oleksij Rempel
2020-04-22  8:48 ` Philippe Schenker
2020-04-22 13:39 ` Andrew Lunn
2020-04-23  2:39 ` David Miller
2020-04-28 15:28 ` Geert Uytterhoeven [this message]
2020-04-28 15:47   ` Andrew Lunn
2020-04-28 16:16     ` Philippe Schenker
2020-04-29  8:45       ` Geert Uytterhoeven
2020-04-29  9:26         ` Oleksij Rempel
2020-05-27 19:11           ` Geert Uytterhoeven
2020-05-27 20:52             ` Andrew Lunn
2020-05-28 13:10               ` Geert Uytterhoeven
2020-05-28 16:08                 ` Andrew Lunn
2020-05-29  4:59                   ` Oleksij Rempel
2020-05-29 10:17                   ` Geert Uytterhoeven
2020-05-28  8:20             ` Philippe Schenker
2020-05-28 12:51               ` Geert Uytterhoeven
2020-05-28 23:31                 ` Florian Fainelli
2020-04-29 10:02         ` Philippe Schenker
2020-05-05 18:26 ` Grygorii Strashko
2020-05-06  4:51   ` Oleksij Rempel
2020-07-10 22:36 ` Alexandre Belloni
2020-07-10 22:54   ` Andrew Lunn
2020-07-10 23:25     ` Alexandre Belloni
  -- strict thread matches above, loose matches on Subject: below --
2020-04-07  9:36 Oleksij Rempel
2020-04-07 10:57 ` Philippe Schenker
2020-04-07 11:02   ` Marc Kleine-Budde
2020-04-07 12:34     ` Philippe Schenker
2020-04-07 11:05   ` Russell King - ARM Linux admin
2020-04-07 20:13 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMuHMdU1ZmSm_tjtWxoFNako2fzmranGVz5qqD2YRNEFRjX0Sw@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=david@protonic.nl \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=philippe.schenker@toradex.com \
    --cc=sergei.shtylyov@cogentembedded.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.