On Thu, Nov 20, 2008 at 11:55 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > >> -----Original Message----- >> From: Marc Jones [mailto:[EMAIL PROTECTED] >> Sent: Thursday, November 20, 2008 11:13 AM >> To: Myles Watson >> Cc: Coreboot >> Subject: Re: [coreboot] HT chains fixup >> >> On Wed, Nov 19, 2008 at 9:16 PM, Myles Watson <[EMAIL PROTECTED]> wrote: >> > >> > >> >> -----Original Message----- >> >> From: Marc Jones [mailto:[EMAIL PROTECTED] >> >> Sent: Wednesday, November 19, 2008 4:11 PM >> >> To: Myles Watson >> >> Subject: Re: [coreboot] HT chains fixup >> >> >> >> Myles, >> >> Hi, sorry to take so long to look at this. I have some possibly dumb >> >> questions. >> > >> > No problem. I appreciate the review. >> > >> >> What is gained by knowing the ht path? >> > When a HT chain is powered on, all the devices have the same UnitID (0) >> > The subordinate busses get assigned bus numbers in the order that they >> are >> > found by PCI scan, but they are found in the order of the chain. As you >> > assign each a device number, another device is visible at device 0 until >> the >> > end of the chain is found. >> > >> >> But I think that the unitid scan happens before and device/dts is used >> or called. This has to be done to set the HT link speed. See >> northbridge\amd\k8\incoherent_ht.c. By the time the device code starts >> they are setup and the bus can be scanned as normal pci. > > The problem is HTX slots and modules that can't be initialized without some > code. > >> >> Every HT bridge/tunnel under a >> >> CPU acts like a PCI device. Linux doesn't know about HT and I am not >> >> sure that the dts needs to. >> > >> > That's why I made ht devices morph into pci devices at chain enumeration >> > time. Once they're assigned UnitIDs it doesn't matter where they are in >> the >> > chain. >> > >> >> Because it is a unitid bus number it is already numbered. I think that >> the device code should use any bus number already set. That would be >> equivalent to setting the bus number with pci_x@ in the dts. > > That could happen. The problem is how you pick the "correct" early > enumeration. It's easy to pick an enumeration that lets you see all the > busses and optimize the HT links. It's not easy to make the busses get > numbered correctly, which is why you need the dts information. >
So you are moving the HT_CHAIN_UNITID_BASE and HT_CHAIN_END_UNITID_BASE to be done by the device and dts setting? It seems to me that the device code hypertransport init is duplicate of setup that has already run in incoherent code. The setup needs to happen early to set the speed etc. I don't expect that you will see a "HyperT reset needed" from the device code because that already happened in stage1. You may also want to review the v3 fam10 code since it works a little bit differently but gets to the same result. Marc -- http://marcjstuff.blogspot.com/ -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
