On Fri, Dec 19, 2014 at 02:58:13PM +0100, Mark Kettenis wrote: > > Date: Fri, 19 Dec 2014 23:41:56 +1000 > > From: Jonathan Matthew <[email protected]> > > > > On Thu, Dec 18, 2014 at 11:14:54PM +0100, Frederic Nowak wrote: > > > Hi! > > > > > > The diff for extracting memory ranges from ACPI was obviously not tested > > > with ACPI disabled...so we definitely have to check if the values in > > > pcimem_range make some sense. The diff below now uses the old values in > > > case ACPI is disabled or does not return valid values. > > > > > > I hope this is somewhat interesting for someone else as well :) > > > Please let me know if this is just noise or if there is anything else I > > > am missing. > > > > This looks like the right direction, except I think we only really want to > > use > > the ACPI range information to add new ranges to the existing one that covers > > the 36-bit address space, rather than relying on it for everything. No > > point > > relying on the ACPI stuff being correct if we don't need to. > > > > I hacked this around a bit today and ended up with the diff below. This > > only > > deals with ranges outside the 36-bit space, so it makes no difference on > > most > > machines, and on the r630 that needs it, it adds two ranges, > > 0x0000030000000000 to 0x0000033FFFFFFFFF and 0x0000034000000000 to > > 0x0000037FFFFFFFFF. > > This is going in the right direction. The way I designed things > though was that the acpi code would build up the complete extent > purely from information provided by _CRS, and set pcimem_ex before > pci_init_extents() gets called.
Ah, OK, I'll make it do that instead. I probably won't be able to work on this for the next week or so, but I'll pick it up again after that.
