Re: [coreboot] HT chains fixup

[Myles Watson]

> -----Original Message-----
> From: Marc Jones [mailto:[e-mail]]
> 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  wrote:
> > > -----Original Message-----
> > > From: Marc Jones [mailto:[e-mail]]
> > > 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
>
> wrote:
> > > > > -----Original Message-----
> > > > > From: Marc Jones [mailto:[e-mail]]
> > > > > 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