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

    From Wojciech M. Zabolotny@wzab@ise.pw.edu.pl to comp.arch.embedded on Wed Oct 31 09:04:45 2018
    From Newsgroup: comp.arch.embedded



    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


    --- Synchronet 3.20a-Linux NewsLink 1.114