[coreboot] Fwd: HT chains fixup

[Marc Jones]

Sorry all, I didn't mean to take this offlist.

Marc

---------- Forwarded message ----------
From: Marc Jones 
Date: Wed, Nov 19, 2008 at 4:10 PM
Subject: Re: [coreboot] HT chains fixup
To: Myles Watson

Myles,
Hi, sorry to take so long to look at this. I have some possibly dumb questions.

What is gained by knowing the ht path? 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. The exception being that coreboot needs to
know the CPU that the bus comes off of.  I feel like I am missing
something obvious that you, Ron, and others understand.

What are you describing with and ht@? For example:
+                       ht@0,a {
+                               /config/("southbridge/amd/amd8132/pcix.dts");
+                       };
+                       pci_a@0,1{
+                               /config/("southbridge/amd/amd8132/apic.dts");

I would think that the dts and device code would work with this for
the 8132 device:
+                       pci_a@0,0 {
+                               /config/("southbridge/amd/amd8132/pcix.dts");
+                       };
+                       pci_a@0,1{
+                               /config/("southbridge/amd/amd8132/apic.dts");

The HT is just a bus link.There is no HT bridge or device. The
bridge/device acts as a PCI bridge/device and should be treated as
such.

I also don't understand when something is under the ht@0,6 vs when it
should just be pci_6@x,y. All the onboard devices are directly on HT
and the bridges to PCI/e/X are also on HT. (There is a question about
this in the output also)

Another nit I have is that pci_18_0 is the top device. Physically it
is but logically it isn't. The dts doesn't make sense when you compare
it with the lspci. I don't know if this is really better but maybe
something like this:

pci@0,0(18,0){
 pci@x,y {
     config....
 };
 ...
 pci@18,0 {};
};

That way the top level bus resources are pointed at the CPU device but
the logical PCI connections are easy to follow.

There are some more question in your output below.

On Mon, Nov 17, 2008 at 11:21 AM, Myles Watson  wrote:
...
> Show all devs in tree form...After phase 3.
> root(Root Device): enabled 1 have_resources 0
>  cpus(CPU: 00): enabled 1 have_resources 0
>  apic_0(APIC: 00): enabled 1 have_resources 0
>  domain_0(PCI_DOMAIN: 0000): enabled 1 have_resources 0
>   domain_0_pci_18_0(PCI: 00:18.0): enabled 1 have_resources 0

This might be easier to read if you use the lspci colon and period on
the device numbers.
For example domain_0_pci_18.0_ht_0:6
> domain_0_pci_18_0_ht_0_6(PCI: 00:06.0): enabled 1 have_resources 0

What if this were a real PCI to PCI bridge? Would it be
domain_0_pci_18_0_pci_0_6?
> domain_0_pci_18_0_ht_0_6_pci_0_0(PCI: 01:00.0): enabled 1 have_resources
>
> 0

Why isn't this domain_0_pci_18_0_ht_0_6_pci_1_0_0?
> domain_0_pci_18_0_ht_0_6_pci_0_1(PCI: 01:00.1): enabled 1 have_resources
>
> 0

...
> domain_0_pci_18_0_pci_6_1_0(PCI: 00:07.0): enabled 1 have_resources 0

I really don't understand this one. It is a device on bus 0 so what
does 6_1_0 mean?
> domain_0_pci_18_0_pci_6_1_0_ioport_2e(IOPORT: 2e): enabled 1
>
> have_resources 0
>      domain_0_pci_18_0_pci_6_1_0_ioport_2e_pnp_child_0(PNP: 002e.0): enabled
> 0 have_resources 0
>      domain_0_pci_18_0_pci_6_1_0_ioport_2e_pnp_child_1(PNP: 002e.1): enabled
> 0 have_resources 0

Putting the io on the subtractive device is good.
...
> Here are some of the next steps:
> Get video working.

Do you know where the breakage is?

Marc