-----Original Message----- From: Marc Jones [mailto:email@example.com] 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 firstname.lastname@example.org wrote:
-----Original Message----- From: Marc Jones [mailto:email@example.com] 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 firstname.lastname@example.org
-----Original Message----- From: Marc Jones [mailto:email@example.com] 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
The subordinate busses get assigned bus numbers in the order that
found by PCI scan, but they are found in the order of the chain. As
assign each a device number, another device is visible at device 0
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
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
time. Once they're assigned UnitIDs it doesn't matter where they are
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.