[coreboot] HT chains fixup

[Marc Jones]

On Thu, Nov 20, 2008 at 11:55 AM, Myles Watson <mylesgw at gmail.com> wrote:
>
>
>> -----Original Message-----
>> From: Marc Jones [mailto:marcj303 at gmail.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 <mylesgw at gmail.com> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Marc Jones [mailto:marcj303 at gmail.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 (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/