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@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@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@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@6,0 { /config/("southbridge/amd/amd8111/pci.dts"); bus{ pci@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@18,0{ pci@1,0{}; }; pci1@18,0{ //some stuff behind the second link }; pci2@18,0{ //some stuff behind the third link }; pci@18,1{}; pci@18,2{};
we'd have pci@18,0{ bus@0{ pci@1,0{}; }; bus@1{ //some stuff behind the second link }; bus@2{ //some stuff behind the third link }; }; pci@18,1{}; pci@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@6,0 { /config/("southbridge/amd/amd8111/pci.dts"); pci@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!
From that lspci it becomes clear that the resource tree is mostly
congruent with the logical PCI tree, but they differ significantly in a few places. It is desirable to have both trees available: One for resource allocation, one for device discovery. Killing either is calling for problems down the road. Besides that, in reality we're neither dealing with a real tree nor a completely acyclic graph. There are easy ways out which either make the dts completely unreadable or beget some unholy device tree code. Neither is acceptable if we consider maintainability to be important.
The good thing is that my diploma thesis provides solutions for exactly that class of problems. It's not about coreboot, but the problems we face right now are so strikingly similar that I regret not writing the whole thing in English. Anyway, I'll try to create a short writeup which captures the essential results, and how to apply them without losing mental sanity (or maintainability, for that matter).
The trick is to declare a preferred and readable form for storing device relations (the existing dts structure works quite well in that regard) and to handle different requirements for that representation like database views. With a nice set of node properties and the right amount of abstraction, we can keep both the code and the dts human readable and have them provide easily understood views of their respective purposes (resource allocation vs. device discovery). If we do it right, even such horrors as wandering PATA/SATA PCI devices (after disabling PATA, SATA will change its PCI devfn) are easily expressed and handled.
Regards, Carl-Daniel