On Tue, 2014-12-09 at 09:56 +1100, Benjamin Herrenschmidt wrote: > On Mon, 2014-12-08 at 13:52 -0800, Yinghai Lu wrote: > > 2. or scan the children resource other than ROM to clear bridge MEM_64 > > for mmio pref. > > > > The patch is using second way so will keep child mmio pref into bridge > > mmio pref range. > > That means that having a single ROM BAR that is 32-bit and prefetchable > will downgrade the entire window to 32-bit ? That's not going to work > either. > > I have GPUs with 16G BARs for example... suddenly they don't fit > anaymore because we downgraded the window to 32 bit because somewhere > there's a 32-bit pref resource ? > > That will break more than it fixes... I think an option would be to keep track of whether the PCI host bridge can do 64-bit pref above 4G. If it can't then we know 64-bit pref is always fair game for 32-bit resources and we can thus downgrade all the bridges 64-pref to 32-perf. If it can, then we probably do need to leave it there do real 64-bit pref, and shoot anything that is 32-bit only down the non-pref windows. We *could* try to be smart and scan first to check if anything under the bridge actually has large/64-bit BARs but that's going to be a heuristic at best and isn't going to do any good with hotplug. I tend to think that treating anything 32-bit pref as non-pref is in fact the best solution unless we know that the platform doesn't do >32-bit pref anyway in which case we leave them alone. Ben. -- 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
