On Thu, 2011-05-12 at 11:16 -0700, Tirumala Marri wrote: > So what is the best way to handle this? It appears (based > on the comments of others and my own experience) that there > is no DCR that exists and behaves the way that previous SOCs > behaved to give us the link status?
The register above > PECFGn_DLLSTA is actually in the PCIe configuration space so > we would have to map that in to be able to read that > register during the link check. Is that correct or ok? > [marri] yes, you need to program DCR register access these local PCIE_CFG > registers. We do I think, tho we might have to re-order some stuff. I'm facing a similar issue with some internal design here, I'm thinking off adding a new hook to the ppc4xx_pciex_hwops for link checking to replace the SDR business. The interesting question of course is whether that 460SX stuff is the same as what we're using internally :-) > I've communicated with some people over email and they had > tried the (PESDRn_HSSLySTS) register. Recognizing that > there exists one of these for each port/lane, is there a way > to use this one? It is in the indirect DCR space. I'd > tried this myself and never did get it to do anything but I > could have been looking at the wrong lane or something. > [marri]This is at SERDES level. If this link up doesn't necessarily > Overall stack is up. This is mostly used for BIST and diagnostics. > > Lastly, what was the reason for forcing the original code to > be GEN-1 speeds? > [marri] Gen-2 need some extra checks compared to Gen-1. > There were not many Gen-2 devices at the time of submission > To test them. Can we fix that ? Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
