On 04.09.2008 17:22, ron minnich wrote:
On Wed, Sep 3, 2008 at 8:20 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I am not sure this it totally right yet, however: struct device dev_domain_0 = { .path = {.type=DEVICE_PATH_PCI_DOMAIN,{.pci_domain={ .domain = 0x0 }}}, .device_configuration = &domain_0, .ops = &geodelx_north_domain, .link = { [0] = { .dev = &dev_domain_0, .link = 0, .children = &dev_pci_0_0_1_0 },
[1] = { .dev = &dev_domain_0, .link = 0, .children = &dev_pci_0_0_f_0 }, [2] = { .dev = &dev_domain_0, .link = 0, .children = &dev_pci_0_0_f_2 },The list of links "feels" wrong. I can't yet express that feeling in technical terms, but I'll revisit this issue tomorrow.
it is wrong. :-)
Let's review links.
Links came in IIRC because of the k8. We needed a way to express the HT links. It gets weird because on the k8, the HT address space is in PCI space (this is actually a very nice thing AMD did). There are three HT links, and they are all addressed as 0:18.0.
I never felt they way we expressed links in v2 was as clear as we might have made them. How do you know a link is there? It's not really explicitly named. You see this kind of comment in v2 Config.lb:
device pci 18.0 on # northbridge # devices on link 0, link 0 == LDT 0What would trigger that? How do we get to link 1? Turns out it happens if we see this again: device pci 18.0 on # northbridge
config tool "knows" that it is now link 1. See tyan/s2892. It's not just for HT either. And two children of a device in v2 having the same path become links.
Yes, and that implicit magic is something I want to avoid in v3. Sure, it's clever, but how many people will ever understand it?
struct device _dev8 = { .ops = 0, .bus = &_dev6.link[0], .path = {.type=DEVICE_PATH_PCI,.u={.pci={ .devfn = PCI_DEVFN(0x18,0)}}}, .enabled = 1, .on_mainboard = 1, .link = { [0] = { .link = 0, .dev = &_dev8, .children = &_dev10, }, [1] = { .link = 1, .dev = &_dev8, }, [2] = { .link = 2, .dev = &_dev8, .children = &_dev72, }, }, .links = 3, .sibling = &_dev79, .next=&_dev10 };
dev10 is one pci bus, dev72 is the ck804.
Again, links come into play when multiple devices have the same path, e.g. HT links on 18:0.0 (three of them) or I2C mux (2 of them). Again, see tyan s2892.
So in the dts, what would this look like? Well, if we had:
pci@18,0 {}; pci@18,0 {}; pci@18,0 {};
this might become three links. This is the v2 way of doing it. What I wanted to do was something like this: bus@0 {pci@18,0 {};}; bus@1 {pci@18,1 {};};
and so on. Really, if a bus is only ever going to be a link, maybe we should rename "bus" to "link" and leave it at that.
You correctly identified the biggest question from a conceptual POV. Is a bus only a link? Or is a bus a device that hangs off its parent and has its own children?
My current idea is: Treat every dts node except "ht" normally. Nodes below a "ht" node don't get added as multiple siblings below a single link/bus, but they each end up as single sibling, each on its own link. The dts bus number is treated as link number in generated code I'll have to revisit that idea, though. It feels not quite right.
So much for links.
Also, I see your point but: struct device dev_pci_domain_0_bus_0_dev_1_fn_0
is just far more wordy than I like. Bear in mind that the primary goal of this patch is to make the names unique.
Yes.
Human readability is a secondary goal (no one ever looks at these names anyway) and I think the long name you propose is more than I would like to read all the time :-)
True. If we don't have a solution by Tuesday, I'll change my patch to fit your naming taste. The dtsname printed during coreboot bootup needs vast improvements, though. It is barely readable both for current svn and any of our proposals. I propose to offer specifying it in the dts. Having print coreboot "First RTL8139 Network Card on bottom of board (PCI: 00:01.1)" instead of "pci_0_0_1_1(PCI: 00:01.1)" is the difference between easy and cryptic.
Regards, Carl-Daniel