• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 34 subscribers
  • Views 174 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83867IS: Link quality issue between two PHYs on the same board

Matthias Schiffer
Prodigy 140 points
Part Number: DP83867IS


Tool/software:

For a test setup, one of our customers attempted directly connecting two Ethernet ports on the same board (both using a DP83867IS PHY), and found that while the link does come up, it does exhibit high packet loss in one (random) direction, caused by CRC errors.

We determined that the register configuration described in the section "Improving Link-up Margins for Short Cables" of the DP83867 Troubleshooting Guide app note (SNLA246C) fixes the issue (which occurs regardless of cable length) or at least vastly reduces the observed packet loss, however we would like to understand the tradeoffs of this configuration.

Many of the registers set in the app note are not documented in the DP83867 datasheet. Is such documentation available?

Are there any significant downsides to the described settings, or could we adjust the PHY driver of the Linux kernel to perform this configuration unconditionally? Would such a configuration make sense for a standard mainline kernel?

Best,
Matthias

  • 0
    TI__Mastermind 40275 points

    Hi Matthias,

    These registers are used to adjust the link training for optimal operation. The general register description is located in SNLA246 in the comments (see //). This configuration was suggested in prior debugs and TI wanted to reveal this out to help other customers who might face similar issues. There should be no risk in implementing this configuration, and can be implemented in your application unconditionally.

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 140 points

    Hi Gerome,

    thanks for your quick reply. We will consider adding this configuration to our kernel, and possibly also submit a patch for mainline.

    For the register descriptions, I was hoping for a bit more detail than is given in the comments, like names of the individual registers (and maybe even information on the meaning of the programmed values, like the datasheet gives for many other registers), so I can add defines for the register offsets when implementing this (for comparison: this is how the existing driver code looks: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/dp83867.c#n34).

    Best,
    Matthias

  • +1 in reply to Matthias Schiffer
    TI__Mastermind 40275 points

    Hi Matthias,

    I understand where you are coming from. The defaults for these registers listed are consistent across all DP83867's, and this configuration is provided as a discrete change; only recommended configuration is either default register value, or the adjusted value per SNLA246 script. I see you are trying to bit-mask for this configuration change, but instead, I would suggest wholesale creating header with raw value which can be loaded in.

    We are looking to include this registers in datasheet upon next revision.

    Sincerely,

    Gerome