]> Hi all, ]> ]> Scott, thanks on working on that! The resource overlap is bit pitty - ]> it belongs to style - "Oh I haven't thought of that". ]I think this was heavily discussed a while back, and lead to some ]naughty work arounds in the i945 code. because having such big a "hole" ]lead to no resources being placed after the MMCONF area. Ther should be ]a better way to do it. Have to admit I have not particularly checked out ]the k8t890 code yet. My experiments with allocating a resource for it in ]the i945 northbridge code didn't keep the resource allocator from ]putting other stuff on top of it, mainly because of the hierarchical way ]the resource allocator works. Any insights are highly welcome. ] ]Stefan
Thanks for the suggestions everyone. I like the k8t890 method, however there is a concern. I think the dynamically obtained mmconf base address would not be known or programmed until fairly late. But using mmconf very early to access config space was the key change that solved the unreliable AP startup on my project. The unreliable AP startup problem was caused by simultaneous core access to cf8/cfc. I think there is a real value in knowing the mmconf base very early, and that requires a fixed resource assignment.
I found a reasonable scheme for handling fixed resources is already in place. This is why the local apic space at fec00000 is never allocated to a PCI device. Yes, the code allocates from a single range only. But it knows to avoid fixed resources. As long as some care is used when choosing a fixed resource location, the existing scheme seems fine.
Why does the current code for handling fixed resources allow the mmconf space to get allocated to a PCI device? Function avoid_fixed_resources calls function constrain_resources, which recursively searches the device tree for fixed io and memory resources. The ioapic fixed memory address is found and avoided during the recursive search because this southbridge device is below the level where the search starts. On the other hand, the mmconf fixed resource is added from the northbridge code, and falls under 'APIC_CLUSTER: 0'. This device is not part of the search for two reasons. One is that it is not at or below 'pci_domain 0' in the device tree. Another reason is that its type is APIC_CLUSTER and not PCI_DOMAIN.
Right now, each 'pci domain n' is treated as if it has a completely private resource address space. The real problem is that the resource assignments of 'lapic cluster n' are completely ignored when assigning resources to a pci domain. One solution might be to add an argument to function avoid_fixed_resources that allows passing in apic cluster in addition to the pci domain that is already passed in. Then avoid_fixed_resources could consider the apic cluster resources when adjusting its allocation limits to avoid fixed resources. I could prototype something like this if it sounds reasonable.
Thanks, Scott