Dear Neil Greatorex, On Thu, 10 Apr 2014 22:56:00 +0100 (BST), Neil Greatorex wrote: > > In any event, turning on the clock should almost certainly be > > accompanied by a phy reset sequence to get both link ends on the same > > page. > > > > Attached is a rough, untested patch along those lines. > > > > I took your attached patch and extended it a bit to print out how long it > took. The delays also need to be much longer for me. I also fixed a small > typo you made where the bit wasn't being set again to bring the link back > up. I've attached the diff to your patch, as well as the combined patch > (hope that makes sense). I managed to reproduce the problem of the PCIe device not being detected on Mirabox when earlyprintk is disabled. However, the proposed patch doesn't seem to work: mvebu-pcie pcie-controller.3: PCIe0.0: performing link reset mvebu-pcie pcie-controller.3: PCIe0.0: link went down after 100 tries mvebu-pcie pcie-controller.3: PCIe0.0: link came back up after 0 tries It waits hundred times for the link to go down, but it never goes down, and then it doesn't wait at all to go up... because it never went down. Moreover, I am not entirely convinced that a PHY reset is needed here. In my tests, doing just a wait after setting the local dev number was sufficient. The fact is works with earlyprintk also indicates that we don't need to do any specific action with the PHY, just to wait a bit of time. I am worried that resetting the PHY might actually take more time than what is needed, and may have other consequences that we don't necessarily understand at this point. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
