EmbeddedRelated.com
Forums

Embedded Linux - Delay control implemented for Marvell 88E6352/1 also works for 88E6320

Started by Wojciech M. Zabolotny October 31, 2018

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,
and the whole solution is based just on code analysis
and experiments. It worked for me, but I can not give
any warranty.

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 RGMII 
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