> -----Original Message----- > From: Marc Jones [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 20, 2008 1:58 PM > To: Myles Watson > Cc: Coreboot > Subject: Re: [coreboot] HT chains fixup > > 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?
Yes. I'm hoping that there will be no #ifs in the code. It's too fragile, especially when there are multiple chains. The way I envision it is that the HT chains get optimized (assign valid but unimportant UnitIDs), then collapsed and set by dts when it matters. > 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. That's what I'm hoping. > You may also want to review the v3 fam10 code since it works a little > bit differently but gets to the same result. I'll look through it. Thanks, Myles -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
