On Tue, May 24, 2011 at 01:40:12PM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2011-05-12 at 11:16 -0700, Tirumala Marri wrote: > > 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.
That would probably solve the existing problem. I might be remembering it wrong (or reading it wrong) or both. But I thought that the config space was mapped in the setup_hose that happens after (and if) the link check finished successfully. > The interesting question of course is whether that 460SX stuff is the > same as what we're using internally :-) Not sure how I would know -- But with my eiger kit, I got a cd from amcc that had a patched 2.6.30 or something kernel in it to support the 460SX. The pci code was basically subverted by adding a "port->link=1" at the very end of the link check to always force it to succeed. However this code never appeared in the public git repositories, so I am not sure how the 460SX functioned (if it ever did) since the link check that is in there now can't work on that SOC. > > 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 ? > I took care of that in my patch. Basically it let the system go to gen-2 speeds and negotiate down. Ayman _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
