On Mon, 2008-09-22 at 11:23 -0700, Jesse Barnes wrote: > On Wednesday, July 23, 2008 11:18 am TJ wrote: > > On Wed, 2008-07-23 at 11:02 -0700, Alok Kataria wrote: > > > Yeah i agree that this should be the approach. > > > I went through TJ's wiki and in the solutions section the first point > > > talks about > > > "keeping a list of all available PCI iomem regions which will be derived > > > from the e820 map (and the CRS object of the root PCI device). > > > > > > TJ/Jesse, do we have any patches/work-in-progress which actually does > > > this ? > > > I can then add the CRS object stuff to that then. > > > > Alok, my existing PCI-DRAM code fully implements tracking of the > > available IOMEM regions gathered from e820/EFI and ACPI in a tree of > > struct resource objects. It is the basis of everything else the code > > does in providing policy-controlled optimum resource allocation. > > > > I'd suggest holding fire on fiddling with this aspect until I've > > published the PCI-DRAM code next week. I suspect you'll find it helps > > solves your issue and provides mechanisms to hook into it for your own > > purposes too. From the outset I always intended it to have a defined API > > that drivers can call to manipulate the IOMEM map in a uniform manner > > and which allows the code to move resources around if the policy allows > > and the drivers are capable of 'pausing'. > > Any update here, TJ? It would be great if we could start pushing the > additional gap code, preferably incrementally. If you don't have time, maybe > you could point me at your code (couldn't find it on your wiki) and I can > extract bits and start merging them? Hi Jesse/TJ, Were there any updates on this that I missed ? I still see that 2.6.27 has this problem, pci_hole conflicting with the memory hotpluggable range. Thanks, Alok > > Thanks, > Jesse -- 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
