From: Andrew Lunn <andrew@lunn.ch>
To: Tim Harvey <tharvey@gateworks.com>
Cc: Sunil Goutham <sgoutham@cavium.com>, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] net: thunderx: add support for rgmii internal delay
Date: Thu, 14 Dec 2017 09:45:25 +0100 [thread overview]
Message-ID: <20171214084525.GA19186@lunn.ch> (raw)
In-Reply-To: <CAJ+vNU3C2KWUBMU_-kMABwb8wfox_xV_3+9bivi=Adpd_vXCDg@mail.gmail.com>
On Wed, Dec 13, 2017 at 03:28:33PM -0800, Tim Harvey wrote:
> On Wed, Dec 13, 2017 at 3:10 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> +void xcv_init_hw(int phy_mode)
> >> {
> >> u64 cfg;
> >>
> >> @@ -81,12 +81,31 @@ void xcv_init_hw(void)
> >> /* Wait for DLL to lock */
> >> msleep(1);
> >>
> >> - /* Configure DLL - enable or bypass
> >> - * TX no bypass, RX bypass
> >> - */
> >> + /* enable/bypass DLL providing MAC based internal TX/RX delays */
> >> cfg = readq_relaxed(xcv->reg_base + XCV_DLL_CTL);
> >> - cfg &= ~0xFF03;
> >> - cfg |= CLKRX_BYP;
> >> + cfg &= ~0xffff00;
> >> + switch (phy_mode) {
> >> + /* RX and TX delays are added by the MAC */
> >> + case PHY_INTERFACE_MODE_RGMII:
> >> + break;
> >> + /* internal RX and TX delays provided by the PHY */
> >> + case PHY_INTERFACE_MODE_RGMII_ID:
> >> + cfg |= CLKRX_BYP;
> >> + cfg |= CLKTX_BYP;
> >> + break;
> >> + /* internal RX delay provided by the PHY, the MAC
> >> + * should not add an RX delay in this case
> >> + */
> >> + case PHY_INTERFACE_MODE_RGMII_RXID:
> >> + cfg |= CLKRX_BYP;
> >> + break;
> >> + /* internal TX delay provided by the PHY, the MAC
> >> + * should not add an TX delay in this case
> >> + */
> >> + case PHY_INTERFACE_MODE_RGMII_TXID:
> >> + cfg |= CLKRX_BYP;
> >> + break;
> >> + }
> >
> > Hi Tim
> >
> > This i don't get. Normally, you leave the PHY to handle delays, if
> > needed. The MAC should not add any. Here you seem to assume a delay is
> > always needed, and if the PHY is not providing it, the MAC should.
> >
> > Andrew
>
> Andrew,
>
> The thunder RGX inserts a delay via an on-board DLL. The 'bypass'
> register will bypass this DLL and not insert a delay from the MAC
> side. By default out of reset CLKTX_BYP=1 causing the RGX transmit
> interface to not introduce a delay and CLKRX_BYP=0 causing the RGX
> receive interface to introduce a delay.
Hi Tim
So the MAC by default is doing PHY_INTERFACE_MODE_RGMII_RXID. And it
calls phy_connect_direct() passing PHY_INTERFACE_MODE_RGMII. It does
not get anything from device tree. So it looks like we have a chance
to clean this up.
So the correct thing to do is set the MAC to PHY_INTERFACE_MODE_RGMII,
i.e. no delays. By default call phy_connect_direct()
PHY_INTERFACE_MODE_RGMII_RXID. That should give you the same behaviour
as today.
Then add code to look in device tree, to find a per board setting. In
your case, you want PHY_INTERFACE_MODE_RGMII_ID. And make sure the PHY
driver respects the value passed.
Andrew
next prev parent reply other threads:[~2017-12-14 8:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-12 22:51 [PATCH] net: thunderx: add support for rgmii internal delay Tim Harvey
2017-12-13 11:10 ` Andrew Lunn
2017-12-13 23:28 ` Tim Harvey
2017-12-14 8:45 ` Andrew Lunn [this message]
2017-12-18 22:10 ` Tim Harvey
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=20171214084525.GA19186@lunn.ch \
--to=andrew@lunn.ch \
--cc=netdev@vger.kernel.org \
--cc=sgoutham@cavium.com \
--cc=tharvey@gateworks.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).