From: <Arun.Ramadoss@microchip.com>
To: <olteanv@gmail.com>
Cc: <andrew@lunn.ch>, <linux-kernel@vger.kernel.org>,
<UNGLinuxDriver@microchip.com>, <vivien.didelot@gmail.com>,
<linux@armlinux.org.uk>, <f.fainelli@gmail.com>,
<kuba@kernel.org>, <edumazet@google.com>, <pabeni@redhat.com>,
<netdev@vger.kernel.org>, <Woojung.Huh@microchip.com>,
<davem@davemloft.net>
Subject: Re: [RFC Patch net-next 07/10] net: dsa: microchip: apply rgmii tx and rx delay in phylink mac config
Date: Wed, 20 Jul 2022 14:51:42 +0000 [thread overview]
Message-ID: <d4696bc19472e9efd3a5581ea5c3bca201c90580.camel@microchip.com> (raw)
In-Reply-To: <20220719102532.ndny6lrcxwwte7gw@skbuf>
On Tue, 2022-07-19 at 13:25 +0300, Vladimir Oltean wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
>
> On Tue, Jul 12, 2022 at 09:33:05PM +0530, Arun Ramadoss wrote:
> > This patch apply the rgmii delay to the xmii tune adjust register
> > based
> > on the interface selected in phylink mac config. There are two
> > rgmii
> > port in LAN937x and value to be loaded in the register vary depends
> > on
> > the port selected.
> >
> > Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
> > ---
> > drivers/net/dsa/microchip/lan937x_main.c | 61
> > ++++++++++++++++++++++++
> > drivers/net/dsa/microchip/lan937x_reg.h | 18 +++++++
> > 2 files changed, 79 insertions(+)
> >
> > diff --git a/drivers/net/dsa/microchip/lan937x_main.c
> > b/drivers/net/dsa/microchip/lan937x_main.c
> > index d86ffdf976b0..db88ea567ba6 100644
> > --- a/drivers/net/dsa/microchip/lan937x_main.c
> > +++ b/drivers/net/dsa/microchip/lan937x_main.c
> > @@ -315,6 +315,45 @@ int lan937x_change_mtu(struct ksz_device *dev,
> > int port, int new_mtu)
> > return 0;
> > }
> >
> > +
> > +static void lan937x_set_rgmii_tx_delay(struct ksz_device *dev, int
> > port)
> > +{
> > + u8 val;
> > +
> > + /* Apply different codes based on the ports as per
> > characterization
> > + * results
> > + */
>
> What characterization result are you referring to? Individual board
> designers should do their own characterization, that's why they
> provide
> a p->rgmii_tx_val in the device tree. The value provided there seems
> to
> be ignored and unconditionally replaced with 2 ns here.
This is the value we got from the post silicon validation team which
has to be programmed to dll register to get the proper delay. The value
is different for rgmii 1 and rgmii2.
>
> > + val = (port == LAN937X_RGMII_1_PORT) ? RGMII_1_TX_DELAY_2NS :
> > + RGMII_2_TX_DELAY_2NS;
> > +
> > + lan937x_set_tune_adj(dev, port, REG_PORT_XMII_CTRL_5, val);
> > +}
> > +
> > +
> > @@ -341,6 +383,25 @@ void lan937x_phylink_mac_config(struct
> > ksz_device *dev, int port,
> > }
> >
> > ksz_set_xmii(dev, port, state->interface);
> > +
> > + /* if the delay is 0, do not enable DLL */
> > + if (interface == PHY_INTERFACE_MODE_RGMII_ID ||
> > + interface == PHY_INTERFACE_MODE_RGMII_RXID) {
>
> Why not all RGMII modes and only these 2? There was a discussion a
> long
> time ago that the "_*ID" values refer to delays applied by an
> attached PHY.
> Here you are refusing to apply RGMII TX delays in the "rgmii" and
> "rgmii-txid"
> modes.
I have reused the code of ksz9477 cpu config function and added the dll
configuration for lan937x family alone. And understood that if device
tree specificies as rgmii_txid then apply the egress delay, for
rgmii_rxid apply ingress delay, for rgmii_id apply both.
From your comment, I am inferring that apply the mac delay for all the
rgmii interface "rgmii*".
Can you correct me if am I wrong and bit elaborate on it.
>
> > + if (p->rgmii_tx_val) {
> > + lan937x_set_rgmii_tx_delay(dev, port);
> > + dev_info(dev->dev, "Applied rgmii tx delay
> > for the port %d\n",
> > + port);
> > + }
> > + }
> > +
> > + if (interface == PHY_INTERFACE_MODE_RGMII_ID ||
> > + interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> > + if (p->rgmii_rx_val) {
> > + lan937x_set_rgmii_rx_delay(dev, port);
> > + dev_info(dev->dev, "Applied rgmii rx delay
> > for the port %d\n",
> > + port);
> > + }
> > + }
> > }
> >
next prev parent reply other threads:[~2022-07-20 14:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-12 16:02 [RFC Patch net-next 00/10] net: dsa: microchip: add support for phylink mac config and link up Arun Ramadoss
2022-07-12 16:02 ` [RFC Patch net-next 01/10] net: dsa: microchip: lan937x: read rgmii delay from device tree Arun Ramadoss
2022-07-19 10:28 ` Vladimir Oltean
2022-07-19 15:58 ` Arun.Ramadoss
2022-07-12 16:03 ` [RFC Patch net-next 02/10] net: dsa: microchip: add common gigabit set and get function Arun Ramadoss
2022-07-19 10:37 ` Vladimir Oltean
2022-07-12 16:03 ` [RFC Patch net-next 03/10] net: dsa: microchip: add common 100/10Mbps selection function Arun Ramadoss
2022-07-19 10:48 ` Vladimir Oltean
2022-07-19 15:56 ` Arun.Ramadoss
2022-07-12 16:03 ` [RFC Patch net-next 04/10] net: dsa: microchip: add common duplex and flow control function Arun Ramadoss
2022-07-19 10:52 ` Vladimir Oltean
2022-07-19 15:54 ` Arun.Ramadoss
2022-07-12 16:03 ` [RFC Patch net-next 05/10] net: dsa: microchip: add support for common phylink mac link up Arun Ramadoss
2022-07-12 16:03 ` [RFC Patch net-next 06/10] net: dsa: microchip: lan937x: add support for configuing xMII register Arun Ramadoss
2022-07-19 11:04 ` Vladimir Oltean
2022-07-19 15:55 ` Arun.Ramadoss
2022-07-12 16:03 ` [RFC Patch net-next 07/10] net: dsa: microchip: apply rgmii tx and rx delay in phylink mac config Arun Ramadoss
2022-07-19 10:25 ` Vladimir Oltean
2022-07-20 14:51 ` Arun.Ramadoss [this message]
2022-07-20 21:04 ` Vladimir Oltean
2022-07-12 16:03 ` [RFC Patch net-next 08/10] net: dsa: microchip: ksz9477: use common xmii function Arun Ramadoss
2022-07-12 16:03 ` [RFC Patch net-next 09/10] net: dsa: microchip: ksz8795: " Arun Ramadoss
2022-07-12 16:03 ` [RFC Patch net-next 10/10] net: dsa: microchip: add support for phylink mac config Arun Ramadoss
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=d4696bc19472e9efd3a5581ea5c3bca201c90580.camel@microchip.com \
--to=arun.ramadoss@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=Woojung.Huh@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=vivien.didelot@gmail.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.