Re: fast ethernet driver MII phy serial clock rates

From: David Burns (david.burns_at_dugeem.net)
Date: 04/25/04

  • Next message: Luigi Rizzo: "new arp code snapshot for review..." 
    Date: Sun, 25 Apr 2004 23:23:31 +1000
To: Mike Silbersack <silby@silby.com>

    Mike Silbersack wrote:

    >
    > On Sat, 24 Apr 2004, David Burns wrote:
    >
    >
    >>Hello all,
    >>
    >>It appears that quite a few of the "el cheapo" hardware Fast Ethernet
    >>drivers (at least rl, sis, ste, vr, wb - these are just the ones I found
    >>in /usr/src/sys/pci) have added DELAY(1) statements around MII serial
    >>clock ops which will result in a max Management Data Clock (MDC)
    >>frequency of 500kHz for the serial management interface. Which means
    >>that a mii_readreg (or writereg) operation will take a minimum of 128?s
    >>(64?s for mii_sync + 64?s for data read/write). During which time the
    >>driver is locked.
    >
    >
    > This is an old problem, most of us leave it alone because hardware can
    > break in strange ways. :)
    >

    I was afraid someone would say that... :-)

    We should still implement this where testing succeeds on at least a few
    hardware platforms.

    Alternatively implement a driver.mii_phy_fast tunable which allows the
    DELAY to be disabled.

    >
    >>NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't
    >>think it is ... :-(
    >
    >
    > Correct, DELAY takes far longer than it should.
    >
    > If you're really interested in fixing the problem and not inadvertantly
    > breaking older cards, what you should do is implement a nanodelay function
    > that actually delays for the time it's supposed to and then delay the
    > rated amount. Removing all delays will probably break something
    > somewhere.
    >

    We could probably build a driver specific nanodelay function based on
    dummy PCI operations. Some will say this sucks but then I'd argue it's
    better than the current DELAY implementation.

    Of course just sending one bit of data on the MDIO will take us about
    600 nanoseconds - resulting in a 1.6MHz clock.

    Probably need input from the guys who originally cut these drivers years
    ago (eg wpaul) to help identify the pathological PHYs out there...

    David
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Luigi Rizzo: "new arp code snapshot for review..."

    Relevant Pages

    • Re: C128 --> VGA Scandoubler circuit
      ... or synthesize a new 16 MHz clock and use it as a ... which should eliminate any unpredictable phase error. ... A delay line might be needed to make sure the input side of the SRAM always ... fall near the middle of a pixel. ...
      (comp.sys.cbm)
    • Re: Need to implement a calendar clock with millisecond resolution, please help.
      ... true, as I am a newbie, not even a real programmer), but I need to ... implement a calendar time clock with a millisecond resolution. ... system include clock, delay(), gettimeofday, msleep, ...
      (comp.lang.c)
    • Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree
      ... > spin delay during fiber phy init with interrupts off. ... > That is certainly a much newer driver than tulip. ... >>what happens when a patch is useful, but the patch author isn't (for ...
      (Linux-Kernel)
    • Re: Trying figure it out - time dilation
      ... ELI WROTE ... It is NOT a propagation delay. ... > synchronize our clocks and I start my spaceship and fly 1 lightyear in the ... always say whos clock and whos ruler is doing the measuring). ...
      (sci.physics.relativity)
    • Re: Monitoring NTP - nptq -p
      ... My local clock always shows zero delay - is this an assumption that the refclock always has zero delay or is it measured and just too small to display? ... Docs say 'offset of the peer' again in milliseconds. ... A high jitter value would indicate a lot of random noise in the signal, but what can I do if jitter is high? ...
      (comp.protocols.time.ntp)
    • Quantcast