On Tue, Apr 15, 2014 at 5:09 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: >> It first >> tried to find a 32-bit prefetchable window, but we only supply a 64-bit one. >> So it fall back to (32-bit) non-prefetchable window, but there is no enough >> room there. At last it went into complicated steps (not show here) of >> allocating requested resource first, then try best for the optional ones, etc.. >> >> Why is BAR 15 (prefetchable) 32 bit instead of 64? Because PCI core favours >> 32-bit prefetchable BARs and we have some. This is one of them: >> >> | pci 0003:05:00.0: reg 0x30: [mem 0x00000000-0x000fffff pref] >> >> PCI core decides to let them enjoy the benefition of prefetch. They can't >> bear the risk of getting 4G-above address, so its parent, its parent's parent, >> its parent's parent's parent, finally the root bridge (00:00.0) must have their >> MEM_64 flag of prefetchable resource (BAR 15) clear. > > It sounds like we're tracking the resource requirements > (prefetchability and BAR width) by using the flags on bridge windows. > If that's the case, I think it's wrong. We should preserve the bridge > window flags, because those express the bridge hardware capabilities, > and we should explicitly keep track of what's required by devices > below the bridge in some other way. if the BAR support 64bit, then resource could be 64bit. if the BAR does not support 64bit, then resource should be 32bit. That should be best guess to decide resource flag. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
