[coreboot] HT chains fixup

[Myles Watson]

> -----Original Message-----
> From: Marc Jones [mailto:marcj303 at gmail.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 <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?

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