Searched hist:241436 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-10.0-release/sys/dev/bge/ | ||
| H A D | if_bgereg.h | diff 241436 Thu Oct 11 03:58:33 MDT 2012 yongari Rework controller reset procedure. Previously driver saved BGE_PCI_PCISTATE register before issuing global reset. After issuing reset, it reads BGE_PCI_PCISTATE register again and compares the saved register value and current value. It was used to know whether the global reset operation was completed or not. Unfortunately, this logic caused several issues on recent BCM5717/ 5718/5719 and BCM5720 controllers. It seems APE firmware accesses some registers while global reset is in progress such that reading BGE_PCI_PCISTATE register after reset does not yield old pre-reset state value. This resulted in consuming too much time in global reset and sometimes it couldn't successfully complete reset. The BGE_MISCCFG_RESET_CORE_CLOCKS of BGE_MISC_CFG register is self-clearing bit so driver is able to know the reset completion. But the core-lock reset will disable indirect/flat/standard access modes such that driver cannot poll BGE_MISCCFG_RESET_CORE_CLOCKS bit of BGE_MISC_CFG register. So just wait enough time for core-clock reset to complete. Data sheet says driver should wait 100us for PCI/PCI-X devices and 100ms for PCIe devices. I chose 1ms for PCI/PCI-X since this value was used for many years in bge(4). For PCIe devices, use 100ms as recommended by data sheet. bge_chipinit() also cleared BGE_MAC_MODE register which shall clear firmware configured mode information. I think this will result in losing ASF/IPMI link in device attachment. Let bge_reset() honor firmware configured BGE_MAC_MODE register and don't announce driver is UP in bge_reset(). Firmware should have control over driver until it's fully initialized by driver. While I'm here, enable workaround for PCI-X BCM5704 A0 in bge_reset(). This will prevent internal arbitration logic from switching to the other DMA engine after a retry cycle. |
| H A D | if_bge.c | diff 241436 Thu Oct 11 03:58:33 MDT 2012 yongari Rework controller reset procedure. Previously driver saved BGE_PCI_PCISTATE register before issuing global reset. After issuing reset, it reads BGE_PCI_PCISTATE register again and compares the saved register value and current value. It was used to know whether the global reset operation was completed or not. Unfortunately, this logic caused several issues on recent BCM5717/ 5718/5719 and BCM5720 controllers. It seems APE firmware accesses some registers while global reset is in progress such that reading BGE_PCI_PCISTATE register after reset does not yield old pre-reset state value. This resulted in consuming too much time in global reset and sometimes it couldn't successfully complete reset. The BGE_MISCCFG_RESET_CORE_CLOCKS of BGE_MISC_CFG register is self-clearing bit so driver is able to know the reset completion. But the core-lock reset will disable indirect/flat/standard access modes such that driver cannot poll BGE_MISCCFG_RESET_CORE_CLOCKS bit of BGE_MISC_CFG register. So just wait enough time for core-clock reset to complete. Data sheet says driver should wait 100us for PCI/PCI-X devices and 100ms for PCIe devices. I chose 1ms for PCI/PCI-X since this value was used for many years in bge(4). For PCIe devices, use 100ms as recommended by data sheet. bge_chipinit() also cleared BGE_MAC_MODE register which shall clear firmware configured mode information. I think this will result in losing ASF/IPMI link in device attachment. Let bge_reset() honor firmware configured BGE_MAC_MODE register and don't announce driver is UP in bge_reset(). Firmware should have control over driver until it's fully initialized by driver. While I'm here, enable workaround for PCI-X BCM5704 A0 in bge_reset(). This will prevent internal arbitration logic from switching to the other DMA engine after a retry cycle. |
Completed in 209 milliseconds