| Message ID | CAE9FiQXgvaqErd1oiHmt6G8GwbW92C490+0sYyLUMcMFMMNRAg@mail.gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Thu, Nov 21, 2013 at 12:18 PM, Yinghai Lu <yinghai@kernel.org> wrote: > > 3. or more generic, treat all pci BAR 32bit prefetechable as normal > MMIO32 during allocation. aka mmio prefectechable will be used for pci > bridge that support 64bit mmio pref and leave bridge's 32bit only pref > bar register blank. > > Bjorn, Linus, > Are you happy with No 3? I don't think I understand your #3. If there's a 32-bit device behind the bridge, it will need to be in the low 4G, so you can't use the 64-bit window because it will be out of range. So that wouldn't work. So you'd need to have a bridge window in the low 32-bit area too if there are any 32-bit devices behind the bridge. Also, haven't we tried the "try to allocate 64-bit devices in high memory" and it has always failed because there are broken devices? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 21, 2013 at 1:05 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Nov 21, 2013 at 12:18 PM, Yinghai Lu <yinghai@kernel.org> wrote: >> >> 3. or more generic, treat all pci BAR 32bit prefetechable as normal >> MMIO32 during allocation. aka mmio prefectechable will be used for pci >> bridge that support 64bit mmio pref and leave bridge's 32bit only pref >> bar register blank. >> >> Bjorn, Linus, >> Are you happy with No 3? > > I don't think I understand your #3. If there's a 32-bit device behind > the bridge, it will need to be in the low 4G, so you can't use the > 64-bit window because it will be out of range. So that wouldn't work. > So you'd need to have a bridge window in the low 32-bit area too if > there are any 32-bit devices behind the bridge. bridge should have two mmio, mmio nonpref: it only can be 32bit mmio pref: it could be 32bit only or 64bit. and we are ok to put child pref range under nonpref range from bridge. Here are suggestion is: assume mmio pref: will be use for 64bit pref only, and if the mmio pref does not support 64bit, we just ignore it. If devices under that bridge need pref, we will just use range from bridge's nonpref mmio. > > Also, haven't we tried the "try to allocate 64-bit devices in high > memory" and it has always failed because there are broken devices? In my test setups, it is always working. --- only with Intel network devices and Mellanox Infiniband cards and storage cards from Qlogic and Emulex. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 21, 2013 at 1:34 PM, Yinghai Lu <yinghai@kernel.org> wrote: > > Here are suggestion is: > assume mmio pref: will be use for 64bit pref only, and if the mmio pref > does not support 64bit, we just ignore it. > If devices under that bridge need pref, we will just use range from bridge's > nonpref mmio. Since we always scan devices behind the bus, why don't we take that into account? If we find devices with 32-bit mmio, we try to make the prefetchable one be in the 32-bit range. > In my test setups, it is always working. > --- only with Intel network devices and Mellanox Infiniband cards and storage > cards from Qlogic and Emulex. Right. And remember how many times your testing did *not* show problems that others saw? "Works for me" doesn't work for PCI resource management. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Subject: [PATCH] PCI: Treat ROM resource as optional during assigning. So will try to allocate them together with requested ones, if can not assign them, could go with requested one only, and just skip ROM resource. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/setup-bus.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -303,18 +303,10 @@ static void assign_requested_resources_s idx = pci_dev_resource_idx(dev_res->dev, res); if (resource_size(res) && pci_assign_resource_fit(dev_res->dev, idx, fit)) { - if (fail_head) { - /* - * if the failed res is for ROM BAR, and it will - * be enabled later, don't add it to the list - */ - if (!((idx == PCI_ROM_RESOURCE) && - (!(res->flags & IORESOURCE_ROM_ENABLE)))) - add_to_list(fail_head, - dev_res->dev, res, - 0 /* don't care */, - 0 /* don't care */); - } + if (fail_head) + add_to_list(fail_head, dev_res->dev, res, + 0 /* don't care */, + 0 /* don't care */); reset_resource(res); } } @@ -903,8 +895,9 @@ static int pbus_size_mem(struct pci_bus continue; r_size = resource_size(r); - /* put SRIOV requested res to the optional list */ - if (realloc_head && is_pci_iov_resource_idx(i)) { + /* put SRIOV/ROM requested res to the optional list */ + if (realloc_head && (is_pci_iov_resource_idx(i) || + is_pci_rom_resource_idx(i))) { r->end = r->start - 1; add_to_list(realloc_head, dev, r, r_size, 0/* dont' care */); children_add_size += r_size;