Hello,
I met a issue with the gmii_sel register on the AM335x when using
RGMII. The patch,
commit 74685b08fbb26ff5b8448fabe0941a53269dd33e
Author: Alex [off-list ref]
Date: Tue Dec 6 10:56:51 2016 -0800
drivers: net: cpsw-phy-sel: Clear RGMII_IDMODE on "rgmii" links
Support for setting the RGMII_IDMODE bit was added in the commit
referenced below. However, that commit did not add the symmetrical
clearing of the bit by way of setting it in "mask". Add it here.
Note that the documentation marks clearing this bit as "reserved",
however, according to TI, support for delaying the clock does exist in
the MAC, although it is not officially supported.
We tested this on a board with an RGMII to RGMII link that will not
work unless this bit is cleared.
Fixes: 0fb26c3063ea ("drivers: net: cpsw-phy-sel: add support to configure rgmii int
Signed-off-by: Alexandru Gagniuc [off-list ref]
Signed-off-by: David S. Miller [off-list ref]
is suppose to fix the RGMII mode with setting the RGMII0/1_ID_MODE
bit to 0: "Reserved". I use RMII1 and RGMII2 on our custom
AM335x board. The RMII1 is still working with the patch but
I do not get any data transfered on the RGMII2. When I revert
the patch, everything works again.
I tested this on 4.10-rc3.
The AM335x TRM Rev. O notes on Chapter 14.3.6.4:
"The RGMII0/1_ID_MODE bit value in the GMII_SEL register should
only be set to 1 for 'no internal delay'.
The device does not support internal delay mode for RGMII."
So I wonder what is correct now? As for me the patch makes RGMII unusable.
Has anyone an explanation?
Regards,
Teresa
Hello Andrew,
Am Mittwoch, den 11.01.2017, 16:14 +0100 schrieb Andrew Lunn:
quoted
So I wonder what is correct now? As for me the patch makes RGMII
unusable.
Has anyone an explanation?
Hi Teresa
In your device tree, what phy-mode do you have?
And does your hardware require an RGMII delay in order that it works?
my device tree node for the RGMII looks like this:
&cpsw_emac1 {
phy-handle = <&phy1>;
phy-mode = "rgmii";
dual_emac_res_vlan = <2>;
status = "okay";
};
&davinci_mdio {
phy1: ethernet-phy@1 {
reg = <2>;
/* Register 260 (104h) – RGMII Clock and Control Pad Skew */ rxc-skew-ps = <1400>;
rxdv-skew-ps = <0>;
txc-skew-ps = <1400>;
txen-skew-ps = <0>;
/* Register 261 (105h) – RGMII RX Data Pad Skew */
rxd3-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd0-skew-ps = <0>;
/* Register 262 (106h) – RGMII TX Data Pad Skew */
txd3-skew-ps = <0>;
txd2-skew-ps = <0>;
txd1-skew-ps = <0>;
txd0-skew-ps = <0>;
};
};
The phy we use is a KSZ9021. And yes we add delays to the
phy, as you can see. When looking to the dts documentation I probably
need to set the phy-mode to "rgmii-id" instead, as the phy is providing
the delays.
I make a quick test with that change and it is working. So this seems
to solve my problem. Thank you for the hint.
Regards,
Teresa
Hi Teresa
On 01/11/2017 07:57 AM, Teresa Remmet wrote:
The phy we use is a KSZ9021. And yes we add delays to the
phy, as you can see. When looking to the dts documentation I probably
need to set the phy-mode to "rgmii-id" instead, as the phy is providing
the delays.
Before the change I submitted, every "rgmii*" link was being set up as
"rgmii-id", regardless of phy-mode. I suspected there might have been
the odd board here or there that used "rgmii" when the actual mode is
"rgmii-id".
What confused me the first time around was that I didn't realize the
delay applies to the phy, not the mac. So "-id" means "the PHY provides
the delays, so don't add delays on the MAC", just like you realized.
I make a quick test with that change and it is working. So this seems
to solve my problem. Thank you for the hint.
I'm glad it was an easy fix. Last time I had issues with RGMII, I had to
pull out the oscilloscope.
Alex