On Thu, Dec 29, 2011 at 06:00:04PM +1300, Alexey Korolev wrote:
On 29/12/11 15:56, Kevin O'Connor wrote:
On Wed, Dec 28, 2011 at 06:26:05PM +1300, Alexey Korolev wrote:
--- a/src/pciinit.c +++ b/src/pciinit.c @@ -22,6 +22,7 @@ enum pci_region_type { PCI_REGION_TYPE_IO, PCI_REGION_TYPE_MEM, PCI_REGION_TYPE_PREFMEM,
- PCI_REGION_TYPE_PREFMEM_64, PCI_REGION_TYPE_COUNT,
};
This doesn't seem right. A 64bit bar is not a new category - it's just a way of representing larger values within the existing categories. Tracking of 64bit prefmem sections separately from regular prefmem sections doesn't make sense, because both need to be allocated from the same pool when behind a bridge.
It's a way to account all memory sections on the root bus, as on the root bus we can have all 4 regions. I don't like this part as well, it causes confusions.
The root bus can have five regions - 64bit non-prefmem is also possible.
Given that the allocation for devices on the root bus is distinct from devices behind bridges, I think one could separate out the root bus assignment pass into its own code. Indeed, much of the root bus allocation is already separate.
It makes sense to figure out how shall we account all memory sections on the root bus. Will it be separated structures for root bus and secondary buses? Do you have another idea?
As an idea - keep the current three buckets (io, mem, prefmem) in struct pci_bus, but expand them to track 64bit sizes. Add a new flag to each bucket to track if every device on the given bus is 64bit capable for that resource. When assigning the resources for a bridge, only use 64bit prefmem if all prefmem bars behind that bridge are 64bit capable.
-Kevin