The reason for the problems with running more than one dm9000 was a missing ferrite bead. The shop that assembled the board neglected to install a ferrite bead that tied analog ground to digital ground. When both chips were enabled, there was a sufficient power drop to cause the 2.5V supplies for the magnetics to float a little high of ground and, therefore, jeopardize the output carrier. ---- The only problem we have with the driver is that with our ability to customize the IO functions. The driver allows us to write our own bulk read/write functions, but not those that perform single accesses. Our trouble stems from a need to meet to the dm9000 spec for back-to-back IO operations. The dm9000a datasheet states that we need 2 clocks between successive operations and 4 clocks between successive operations when the F0h register is selected: either 80ns or 160ns. The processor we're using doesn't provide a mechanism to set this kind of back-to-back IO throttle in hardware, so we need to impose a wait in software if we want to meet spec. We aren't really sure that it matters since the code seems to work before we introduced appropriate delays. I plan to roll this code back now that we have both interfaces working. Thus, all of this may come to nothing. Still, this driver, unlike the smc91x driver that I've spent much time with, has no platform method for hooking these functions. I recognize that the down side of permitting the platform to replace them will impose a bothersome delay on everyone else. Perhaps, though, we could have compile-time option that adds these hooks in the platform data. That way, those who don't need them will continue to have a fast path. Dopes like us with weak static memory controllers will still have a way to meet timing without hacking the driver. Would you accept a patch of this sort? Cheers. - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
