• Resolved

DP83867IR: Problem with RESERVED bits in PHY Control Register (PHYCR) - Linux driver

Part Number: DP83867IR

Dear All,


I'm working on Linux driver for DP83867 PHY IC. I'm using 4.9 vanilla kernel.

My board requires one adjustment:

- By initial bootstrap setup the "port mirroring" feature is enabled:

Reg: 0x31 (CFG4) - PORT_MIRROR_EN bit (0) is set to 1

To disable it I change this register value from 0x10b1 to 0x10b0.

Problem starts with Linux driver:

There is  dp83867_phy_reset() function at ./drivers/net/phy/dp83867.c

which performs the SW_RESET (bit 15) at Control Register (CTRL - 0x001F). Such reset does full reset including registers.

And here the problem starts:

The default init code at dp83867_config_init() function leaves the PHYCR register (0x10) with value: 0x5848 (default after reset).

With such setting I see that link is up but, PHY is not working (no data transmission - checked with Wireshark).

To make it working I do write 0x4040 value to PHYCR (0x10) register.

Why do I need to do that?

What is the meaning of:

- BIT 3 - which I must clear

- BIT 11,12 - which I must clear

According to the IC datascheet (SNLS484D –FEBRUARY 2015–REVISED JULY 2016) those fields are RESERVED, RO and write to it is ignored.

DP83867 register dump:

phy_print_status
REG 0x0: 0x1140
REG 0x1: 0x796d
REG 0x2: 0x2000
REG 0x3: 0xa231
REG 0x4: 0x1e1
REG 0x5: 0xc1e1
REG 0x6: 0x6f
REG 0x7: 0x2001
REG 0x8: 0x6801
REG 0x9: 0x300
REG 0xa: 0x3800
REG 0xb: 0x0
REG 0xc: 0x0
REG 0xd: 0x401f
REG 0xe: 0x10b0
REG 0xf: 0x3000
REG 0x10: 0x4040
REG 0x11: 0xbc02
REG 0x12: 0x0
REG 0x13: 0x1c40
REG 0x14: 0x29c7
REG 0x15: 0x0
REG 0x16: 0x0
REG 0x17: 0x40
REG 0x18: 0x6150
REG 0x19: 0x4040
REG 0x1a: 0x2
REG 0x1b: 0x0
REG 0x1c: 0x0
REG 0x1d: 0x0
REG 0x1e: 0x2
REG 0x1f: 0x0
phy_regs_dump: Extended registers
EXT REG 0x31: 0x10b0
EXT REG 0x32: 0xd3
EXT REG 0x33: 0x0
EXT REG 0x6e: 0x8800
EXT REG 0x6f: 0x30
EXT REG 0x86: 0x37

The difference between before reset and after is only with 

0x10 being 0x4040 before reset (setup from u-boot)

and 0x5848 after (when register's reset is performed)

Could somebody explain why clearing of RESERVED bits is needed?

Best regards and thanks in advance,

Łukasz

  • Hi Łukasz,

    The default setting of register 0x10 for the DP83867IR should be 0x5048 for the DP83867IR device.

    Your problem is caused by setting bit[11] of register 0x10. This is a reserved field that should not be set by the driver or the user and should be cleared. Are you implementing the driver properly?

    Make sure you declare that the PHY you are using is in RGMII mode.

    Best Regards,

    Rob Rodrigues

    EFL (Ethernet & FPD Link) Applications Engineer

  • In reply to Rob Rodrigues:

    Hi Rob,

    I'm using already available driver from v4.9 linux kernel. I do set the interface as RGMII-ID.

    I will double check this, but it seems like 0x5848 is set after the reset is performed (set DP83867_SW_RESET - bit 15 in DP83867_CTRL - 0x001F).

    BR,
    Łukasz
  • In reply to user4759774:

    Hi Rob,

    I've double checked the code:


    BEFORE SW_RESET

    REG 0x10: 0x4040
    EXT REG 0x31: 0x10b0
    AFTER SW_RESET

    REG 0x10: 0x5848
    EXT REG 0x31: 0x10b1

    And the above check was done with following code (v.4.9 Linux SHA1: 69973b830859bc6529a7a0468ba0d80ee5117826 - ./drivers/net/phy/dp83867.c):


    static int dp83867_phy_reset(struct phy_device *phydev)
    {
    int err;

    phy_regs_dump(phydev, "BEFORE SW_RESET\n");
    #if 1
    err = phy_write(phydev, DP83867_CTRL, DP83867_SW_RESET);
    if (err < 0)
    return err;
    #endif
    phy_regs_dump(phydev, "AFTER SW_RESET\n");
    return dp83867_config_init(phydev);
    }

    The SW_RESET here is to set bit 15 in 0x1F register (CTRL) - "Perform a full reset, including registers."

    So after the reset value of 0x10 is 0x5848, not 0x5048 as you would expect. Also "port mirroring" feature is enabled after the reset.

    Can I provide some more dump/info?
    Do you have any idea why the IC works like that?

    Best regards,
    Łukasz
  • In reply to user4759774:

    Hi Łukasz,

    Performing a SW_RESET will reload the strap options you have selected by strap resistor. You said you have strapped Mirror Enable. Did you use a pull-up to strap to mode 4 on LED_0 pin?

    In the DP83867IR datasheet, mode 4 of the Mirror Enable strap is N/A meaning you should not use that mode. If you strap to mode 4, you are enabling bit[11] in register 0x10 which is causing the error.

    Please verify this by reading register 0x6e. Register 0x6e maintains the options selected by strap resistor. If bit[11] is set in register 0x6e, any time you do a reset, bit[11] will be set in register 0x10 and you will lose your RGMII communication.

    Best Regards,

    Rob Rodrigues

    EFL (Ethernet & FPD Link) Applications Engineer

  • In reply to Rob Rodrigues:

    Hi Rob,

    1. Please correct me if I'm wrong , but after SW_RESET the strap options will not be reevaluated (from HW), but values read at power up will be put to registers ?

    2. With our design we have +3V3 power supply connected to resistor. Then the resistor is connected to LED and LED connects to LED_0 pin (47). Yes, according to Figure 23 in SNLS484D we do have MODE 4..........

    3. And now the question - according to Table 6. - 4-level Strap Pins - the default state for Mirror Enable is 0. And we need to force Mode 3 to enable it (according to Figure 23 we can only setup Mode 1 or Mode 4) . How does it work? I do have connection for MODE 4 (N/A), which apparently causes enabling of this feature. Can you clarify ?

    4. Can you reveal what is the "real" purpose of bit[11] in register 0x10 ?

    5. The register output including 0x006E (STRAP_STS1):

    REG 0x10: 0x4040
    EXT REG 0x31: 0x10b0
    EXT REG 0x6e: 0x8800
    RET: 0
    AFTER SW_RESET

    REG 0x10: 0x5848
    EXT REG 0x31: 0x10b1
    EXT REG 0x6e: 0x8800

    So, yes the bit 11 is set at 0x006E.

    6. Could you explain why bit[11] set at 0x0010 register (PHYCR) causes RGMII communication to be lost? Why do I have to set it back to 0 to regain RGMII connectivity? I'm asking since I will have to rationale this "quirk" patch to Linux kernel community.

    Best regards,
    Łukasz
  • In reply to user4759774:

    Hi Łukasz,

    1. Please correct me if I'm wrong , but after SW_RESET the strap options will not be reevaluated (from HW), but values read at power up will be put to registers ?

    [Rob] This is correct.  During power up or RESET pulse, straps are sampled at the HW level and then stored into register 0x6e.  The straps then populate the control bits they correspond to.  During SW_RESET, the strap values are NOT reevaluated at the HW level, but all registers are reset and the strap values in 0x6e are used to populate the control bits again.

    2. With our design we have +3V3 power supply connected to resistor. Then the resistor is connected to LED and LED connects to LED_0 pin (47). Yes, according to Figure 23 in SNLS484D we do have MODE 4..........

    [Rob]  By using mode 4 you are enabling Mirror mode and you are enabling a reserved function in the device.

    3. And now the question - according to Table 6. - 4-level Strap Pins - the default state for Mirror Enable is 0. And we need to force Mode 3 to enable it (according to Figure 23 we can only setup Mode 1 or Mode 4) . How does it work? I do have connection for MODE 4 (N/A), which apparently causes enabling of this feature. Can you clarify ?

    [Rob] The example in figure 23 shows the use of straps to set mode 1 and mode 4 on an LED.  To set mode 2 or mode 3, you will need a circuit similar to the one in DP83867E customer EVM.

    4. Can you reveal what is the "real" purpose of bit[11] in register 0x10 ?

    [Rob] Bit[11] controls a hidden test mode inside of the device.

    5.  This behavior is as expected.

    6. Could you explain why bit[11] set at 0x0010 register (PHYCR) causes RGMII communication to be lost? Why do I have to set it back to 0 to regain RGMII connectivity? I'm asking since I will have to rationale this "quirk" patch to Linux kernel community.

    [Rob]  The mode 4 strap is activating the test mode which takes the interface out of RGMII.  The system must clear bit[11] to put the device back into RGMII.  Because this is stated in the DS that strap mode 4 should not be used, this isn't really a "quirk". 

    Best Regards,

    Rob Rodrigues

    EFL (Ethernet & FPD Link) Applications Engineer

  • In reply to Rob Rodrigues:

    Hi Rob,

    we have connected the PHY to AM57xx.

    So the RX_CTRL is connected to the CPU and the CPU has an internal PD activated while reset release. This could be also effect the AutoNeg Disable register with MODE1, which is also N/A and not allowed.

    Is there also a hidden function enabled if the MODE1 is detected by the PHY?

    How should this handled?

    regards

    Daniel

  • In reply to Dr. D:

    Hi Daniel,

    Yes, this is correct. Mode 1 and mode 2 on the RX_CTRL pin is not applicable and would require a register work around if it is used.

    Best Regards,

    Rob Rodrigues

    EFL (Ethernet & FPD Link) Applications Engineer

  • In reply to Rob Rodrigues:

    Hi Rob,

    Apparently the DP83867 configures itself in mode 3 without those strap pins, since the 0x006E register (STRAP_STS1) value is 0x8800.

    If "autoneg" would be affected, then we would have bit 7 set in this register.

    Best regards,

    Łukasz