On Tue, Apr 15, 2014 at 10:16 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > 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. We don't need to "decide" the resource flags. The hardware tells us what it can support, and *that* should be reflected in the flags. We do need to decide what addresses to assign and whether to put a prefetchable BAR in a prefetchable or non-prefetchable window. Putting decision results in the resource flags obfuscates the whole process. -- 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
