Hi Merak: > Hi Richard, > > > Hi Merak: > > Thanks for your great help on the imx6 pcie switch support on the > > latest kernel fristly. > > Let's get this PCIe thing working well :) > > [...] > > > > Regarding to your comments why FORCE GEN1 mode in RC " Force Gen1 > > operation. In case the IP block is in Gen2 operation mode, it does not > > detect the PCIe switch at all.", does the gen2 link can be set-up > > without force gen1 mode? > > What I did in the end for testing purpose was I followed the thread at FSL > community in the link above, forced the link into Gen1 mode , then waited for > link up, then started directed gen2 switch and waited for linkup again. This > worked and the PCIe indicated the link is in Gen2 mode. > > Interestingly enough, I also implemented PCIe driver for MX6 for U-Boot (will > submit it shortly to U-Boot ML) and use it with the Intel i210 ethernet NIC > now. > When I use the PCIe in U-Boot, I don't need the Force-Gen1 thing above. I > suspect though, that the Gen1 setting is preserved from U-Boot, where I have > this as well. > [Richard] It's great, thanks. > > About the errata mentioned in > > https://community.freescale.com/thread/304284, the > > errata-SW-workaround of initialization is contained in previous Sean Cross' > codes, like this. /* > > * From L0, initiate MAC entry to gen2 if EP/RC supports gen2. > > * Wait 2ms (LTSSM timeout is 24ms, PHY lock is ~5us in gen2). > > * If (MAC/LTSSM.state == Recovery.RcvrLock) > > * && (PHY/rx_valid==0) then pulse PHY/rx_reset. Transition > > * to gen2 is stuck > > */ > > Is this not handling only the PHY part ? Honestly, I'm quite lost in the > flurry of different opinions on the MX6 PCIe. Maybe you as a FSL guy could > scrounge some internal knowledge ? > [Richard] Take it easy, maybe there is a misunderstand between you and me. It is handling only the PHY part. The errata "PCIe: Clock pointers can lose sync during clock rate changes", I mentioned previously is discussed in (https://community.freescale.com/message/316162#316162) too. Charies Powe think that the SW workaround contained in FSL BSP is not complete for the errata. Because I couldn't reproduce this issue at my side, the complete version of the SW workaround of this errata is not included in the BSP yet. That's all. Thanks. > > > > > > So better solution should be to initialize RC by default at > > > > > > GEN2 or highest speed. Further, a parameter say gen_only can > > > > > > be passed from DT to force GEN1 only mode. > > > > > > > > > > > > What do you say? > > > > > > > > > > I say I'd like to know the root cause of this problem. This Gen2 > > > > > fix was pulled from one of the myriad variants of the FSL PCIe > > > > > driver, so apparently this issue happens to other people as > > > > > well. But why and how to properly fix this so the whole PCIe bus > > > > > does operate in > > > > > Gen2 mode, I cannot tell :-( > > > > > > > > [Richard] GEN2 mode had been verified in FSL 3.0.35 kernel > > > > releases before. I don't know why it can't work in GEN2 mode in > > > > the latest kernel. BTW, Based on for-next branch of shawn's git > > > > reops and applied Merak's patch-set, my PI7C9X2G303EL with intel > > > > e1000e network card plugged can't be detected at all. :(. > > > > > > I think we're still fighting some issue with resource mappings here. > > > We also agreed with Tim that my patches are incomplete. I will send > > > out a new version ASAP. > > > > [Richard] What's I said above is just curious that I encounter > > different phenomena at my side With the almost same codes. > > I talked to Tim about the mappings some more. It seems if the IOspace is > disabled, everything works without hangs. If the IOspace is not disabled on > the ethernet NICs, we get a hang. [Richard] Ok, I see. Thanks. Best Regards Richard. -- 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
