Hi,
I have faced a problem with communication via Ethernet switch Marvell
88E6320
connected to the Xilinx ZynqMP chip via RGMII interface.
The whole problem and its resolution is described here:
https://forums.xilinx.com/t5/Embedded-Linux/Problem-with-Marvell-88E6320-connected-to-GEM3-in-ZynqMP/m-p/904302/highlight/false#M29845
The solution simply applies to 88E6320 chip the method to control the RGMII
lines delays implemented for 88E6352/1 chips.
Please note, that as documentation for 88E6320 is not available,
the whole solution is based just on code analysis and experiments.
The solution was successfully tested on Petalinux 2017.4, that uses
the 4.9 Linux kernel.
After resolving that problem I have investigated the newest kernel, and
found
that it still lacks the delay control for 88E6320 (of course my patch
for 4.9
is useless here as the whole implementation is completely different).
The definition of mv88e6320_ops structure in
https://elixir.bootlin.com/linux/latest/source/drivers/net/dsa/mv88e6xxx/chip.c#L3420
does not set the .port_set_rgmii_delay field.
Basing on my experiments, and review of the code, it seems that adding the
.port_set_rgmii_delay = mv88e6320_port_set_rgmii_delay,
line in the definition of that structure should switch on the RGMII
delay control
for 88E6320.
The appropriate delay control function should be defined as follows:
int mv88e6320_port_set_rgmii_delay(struct mv88e6xxx_chip *chip, int port,
phy_interface_t mode)
{
if ((port < 5) && (port != 2))
return -EOPNOTSUPP;
return mv88e6xxx_port_set_rgmii_delay(chip, port, mode);
}
That ensures correct communication with the switch in boards where the
necessary
delays are not provided by the MAC or careful adjustment of PCB track
lengths.
Unfortunately, I can't run the newest kernel on my hardware to verify
that the
proposed solution really works.
With best regards,
Wojtek
--
Wojciech M Zabolotny, PhD
Institute of Electronic Systems
Faculty of Electronics and Information Technology
Warsaw University of Technology