Re: [coreboot] HT chains fixup

[Myles Watson]

On Thu, Nov 20, 2008 at 2:45 PM, Myles Watson  wrote:
> > -----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.

I'm hoping we can make it so that Stefan can have his automatic depth-first
assignment too.  If you don't assign UnitIDs in the dts, they just get
assigned as they're reached.

Thanks again for the good questions.  I'm hoping to come out of this with
much simpler code.

Thanks,
Myles