[coreboot] v3 HT

[Carl-Daniel Hailfinger]

On 28.10.2008 01:39, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> On 28.10.2008 00:40, ron minnich wrote:
>>> On Mon, Oct 27, 2008 at 4:25 PM, Carl-Daniel Hailfinger
>>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>>  
>>>> The explanations by Tom and Marc made a few things clear for me:
>>>> - The physical HT structure is not what we want to model.
>>>> - The appearance of HT and topology in PCI config space is what
>>>> matters.
>>>> - 18.0 is not a PCI bridge, don't pretend it is one
>>>>
>>>> With that in mind, I'd like to propose another dts.
>>>> I know that it has its own quirks, but it can serve as a discussion
>>>> point.
>>>>     
>>> I'm beginning to feel like we're thinking too much.
>>>   
>>
>> We were trying to coax physical connections into the dts, but then we
>> had to ignore them in the code because the logical connections and their
>> placements were different.
>>
>
> This is the right track. Addressing is what is important for resource
> allocation. Later we can add a physical connection for ht that can be
> auto-generated runtime if we decide we want to know that as well.

My biggest problem with all this stuff was that I thought we'd model the
device tree after the logical PCI topology. That would make scanning
easier and resource allocation more difficult.
However, your suggestion to model the device tree after resource
allocation topology is probably more promising. It does complicate
scanning, though.


>>> The fact is that whether or not the three HT links are a bridge, there
>>> is routing in there that makes each link logically the parent of a
>>> different set of devices. do we call that a bridge?
>>>   
>>
>> Do we ever walk the HT links explicitly in the code?
>
> Not in device code. All that is done in Stage1 early init.

Hm. Since stage1 doesn't care about the device tree (yet), this allows
us to use either approach.


>>> I don't know what to do with bus at 1.  
>>
>> I fully agree. That's the weakest point of my dts. We can place all
>> those devices at bus 1, but for legacy reasons we may want to have them
>> at bus 0. Our choice.
>
> With the assumption that bus at X should be any number found that matches
> the device. Maybe remove the @X. I don't think it does anything. I
> think that this is more correct:

My original idea was that we'd be able to specify bus numbers if we
wanted and some sort of placeholder if we didn't care.


> bus{
>     pci at 6,0 {
>         /config/("southbridge/amd/amd8111/pci.dts");
>         bus{
>             pci at 0,0{
>                 /config/("southbridge/amd/amd8111/usb.dts");
>
> Does the bus indicate anything? Would this work?

The bus element itself is needed IMO. It allows us to group devices
together which can be discovered/scanned in one go.
Instead of

pci0 at 18,0{
	pci at 1,0{};
};
pci1 at 18,0{
	//some stuff behind the second link
};
pci2 at 18,0{
	//some stuff behind the third link
};
pci at 18,1{};
pci at 18,2{};

we'd have
pci at 18,0{
	bus at 0{
		pci at 1,0{};
	};
	bus at 1{
		//some stuff behind the second link
	};
	bus at 2{
		//some stuff behind the third link
	};
};
pci at 18,1{};
pci at 18,2{};

and that would remove the need for special magic notation in the dts.

However, it is also an interesting question on which "layer" we want to
keep the bus devices.


> pci at 6,0 {
>     /config/("southbridge/amd/amd8111/pci.dts");
>     pci at 0,0{
>         /config/("southbridge/amd/amd8111/usb.dts");
>
>
>>> ah well it's been a long day, will look at this later. For now let's
>>> get myles patch in and try to see where that goes. I think I'm not
>>> ready for this dts. But if myles wants to try it that's fine too.
>>>   
>>
>> Sure, as long as the dts is not set in stone, I retract my NACK and
>> encourage Myles to commit.
>
> This isn't even set in jello, never mind stone! :)
>
> Attached lspci from Serengeti (FAM10 CPU but buses should be the same).

Thanks!