All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Philippe Schenker <philippe.schenker@toradex.com>
Cc: "o.rempel@pengutronix.de" <o.rempel@pengutronix.de>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"grygorii.strashko@ti.com" <grygorii.strashko@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"sergei.shtylyov@cogentembedded.com" 
	<sergei.shtylyov@cogentembedded.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"david@protonic.nl" <david@protonic.nl>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>,
	"kazuya.mizuguchi.ks@renesas.com"
	<kazuya.mizuguchi.ks@renesas.com>
Subject: Re: [PATCH net-next v3] net: phy: micrel: add phy-mode support for the KSZ9031 PHY
Date: Thu, 28 May 2020 14:51:00 +0200	[thread overview]
Message-ID: <CAMuHMdWnSPrAX1=Q3PQNr3QaE3nrtfr4jbE_r1_BmKke-rC92w@mail.gmail.com> (raw)
In-Reply-To: <3a6f6ecc5ea4de7600716a23739c13dc5b02771e.camel@toradex.com>

Hi Philippe,

On Thu, May 28, 2020 at 10:20 AM Philippe Schenker
<philippe.schenker@toradex.com> wrote:
> On Wed, 2020-05-27 at 21:11 +0200, Geert Uytterhoeven wrote:
> > On Wed, Apr 29, 2020 at 11:26 AM Oleksij Rempel <
> > o.rempel@pengutronix.de> wrote:
> > > On Wed, Apr 29, 2020 at 10:45:35AM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, Apr 28, 2020 at 6:16 PM Philippe Schenker
> > > > <philippe.schenker@toradex.com> wrote:
> > > > > On Tue, 2020-04-28 at 17:47 +0200, Andrew Lunn wrote:
> > > > > > On Tue, Apr 28, 2020 at 05:28:30PM +0200, Geert Uytterhoeven
> > > > > > wrote:
> > > > > > > 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:
> > > > > >
> > > > > > Checking for skews which might contradict the PHY-mode is new.
> > > > > > I think
> > > > > > this is the first PHY driver to do it. So i'm not too
> > > > > > surprised it has
> > > > > > triggered a warning, or there is contradictory documentation.
> > > > > >
> > > > > > Your use cases is reasonable. Have the normal transmit delay,
> > > > > > and a
> > > > > > bit shorted receive delay. So we should allow it. It just
> > > > > > makes the
> > > > > > validation code more complex :-(
> > > > >
> > > > > I reviewed Oleksij's patch that introduced this warning. I just
> > > > > want to
> > > > > explain our thinking why this is a good thing, but yes maybe we
> > > > > change
> > > > > that warning a little bit until it lands in mainline.
> > > > >
> > > > > The KSZ9031 driver didn't support for proper phy-modes until now
> > > > > as it
> > > > > don't have dedicated registers to control tx and rx delays. With
> > > > > Oleksij's patch this delay is now done accordingly in skew
> > > > > registers as
> > > > > best as possible. If you now also set the rxc-skew-ps registers
> > > > > those
> > > > > values you previously set with rgmii-txid or rxid get
> > > > > overwritten.
> >
> > While I don't claim that the new implementation is incorrect, my
> > biggest
> > gripe is that this change breaks existing setups (cfr. Grygorii's
> > report,
> > plus see below).  People fine-tuned the parameters in their DTS files
> > according to the old driver behavior, and now have to update their
> > DTBs,
> > which violates DTB backwards-compatibility rules.
> > I know it's ugly, but I'm afraid the only backwards-compatible
> > solution
> > is to add a new DT property to indicate if the new rules apply.
> >
> > > > > We chose the warning to occur on phy-modes 'rgmii-id', 'rgmii-
> > > > > rxid' and
> > > > > 'rgmii-txid' as on those, with the 'rxc-skew-ps' value present,
> > > > > overwriting skew values could occur and you end up with values
> > > > > you do
> > > > > not wanted. We thought, that most of the boards have just
> > > > > 'rgmii' set in
> > > > > phy-mode with specific skew-values present.
> > > > >
> > > > > @Geert if you actually want the PHY to apply RXC and TXC delays
> > > > > just
> > > > > insert 'rgmii-id' in your DT and remove those *-skew-ps values.
> > > > > If you
> > > >
> > > > That seems to work for me, but of course doesn't take into account
> > > > PCB
> > > > routing.
> >
> > Of course I talked too soon.  Both with the existing DTS that triggers
> > the warning, and after changing the mode to "rgmii-id", and dropping
> > the
> > *-skew-ps values, Ethernet became flaky on R-Car M3-W ES1.0.  While
> > the
> > system still boots, it boots very slow.
> > Using nuttcp, I discovered TX performance dropped from ca. 400 Mbps to
> > 0.1-0.3 Mbps, while RX performance looks unaffected.
> >
> > So I did some more testing:
> >   1. Plain "rgmii-txid" and "rgmii" break the network completely, on
> > all
> >      R-Car Gen3 platforms,
> >   2. "rgmii-id" and "rgmii-rxid" work, but cause slowness on R-Car M3-
> > W,
> >   3. "rgmii" with *-skew-ps values that match the old values (default
> >      420 for everything, but default 900 for txc-skew-ps, and the 1500
> >      override for rxc-skew-ps), behaves exactly the same as "rgmii-
> > id",
> >   4. "rgmii-txid" with *-skew-ps values that match the old values does
> > work, i.e.
> >      adding to arch/arm64/boot/dts/renesas/salvator-common.dtsi:
> >      +               rxd0-skew-ps = <420>;
> >      +               rxd1-skew-ps = <420>;
> >      +               rxd2-skew-ps = <420>;
> >      +               rxd3-skew-ps = <420>;
> >      +               rxdv-skew-ps = <420>;
> >      +               txc-skew-ps = <900>;
> >      +               txd0-skew-ps = <420>;
> >      +               txd1-skew-ps = <420>;
> >      +               txd2-skew-ps = <420>;
> >      +               txd3-skew-ps = <420>;
> >      +               txen-skew-ps = <420>;
> >
> > You may wonder what's the difference between 3 and 4? It's not just
> > the
> > PHY driver that looks at phy-mode!
> > drivers/net/ethernet/renesas/ravb_main.c:ravb_set_delay_mode() also
> > does, and configures an additional TX clock delay of 1.8 ns if TXID is
> > enabled.  Doing so fixes R-Car M3-W, but doesn't seem to be needed,
> > or harm, on R-Car H3 ES2.0 and R-Car M3-N.
>
> Sorry for chiming in on this topic but I also did make my thoughts about
> this implementation.
>
> The documentation in Documentation/devicetree/bindings/net/ethernet-
> controller.yaml clearly states, that rgmii-id is meaning the delay is
> provided by the PHY and MAC should not add anything in this case.

Thank you for your very valuable comment!
That means the semantics are clear, and is the reason behind the existence
of properties like "amlogic,tx-delay-ns", which do apply to the MAC.

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

  reply	other threads:[~2020-05-28 12:51 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
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 [this message]
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='CAMuHMdWnSPrAX1=Q3PQNr3QaE3nrtfr4jbE_r1_BmKke-rC92w@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=grygorii.strashko@ti.com \
    --cc=hkallweit1@gmail.com \
    --cc=kazuya.mizuguchi.ks@renesas.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.