Alex Williamson wrote: > On Mon, 2009-11-30 at 15:32 -0800, Yinghai Lu wrote: >> Alex Williamson wrote: >>> On Mon, 2009-11-30 at 14:12 -0800, Yinghai Lu wrote: >>>> Alex Williamson wrote: >>>>> I don't believe the PCI spec dictates whether the upper 32bit base >>>>> should be 0 or -1, so it's purely a BIOS initialization choice and Linux >>>>> should properly handle both. If the hardware only supports 32bit >>>>> prefetchable windows, the hardware will drop the write, just as it did >>>>> for every 2.6 kernel before 1f82de10. Thanks, >>>> current code: >>>> >>>> #define PCI_PREF_RANGE_TYPE_MASK 0x0fUL >>>> #define PCI_PREF_RANGE_TYPE_32 0x00 >>>> #define PCI_PREF_RANGE_TYPE_64 0x01 >>>> #define PCI_PREF_RANGE_MASK (~0x0fUL) >>>> >>>> if the HW state the pref mmio is 64bit, we will touch upper 32bit. otherwise we will not touch it. >>> Really, where? Please paste the code that writes to >>> PCI_PREF_BASE_UPPER32 in the case of hardware supporting a 64bit >>> prefetchable window. I only see this happening if we are assigning it >>> to an IORESOURCE_MEM_64 resources. >> IORESOURCE_MEM_64 get set when PCI_PREF_RANGE_TYPE_64 is set. >> >> in probe.c::pci_read_bridge_bases() > > Ah, I think I see where you're going. We only set IORESOURCE_MEM_64 if > base <= limit, ie. the BIOS has programmed the prefetchable range. This > is not a requirement by the PCI spec. In my case the BIOS has left base >> limit, just as Linux would do if it disabled the range, so we never > set this flag. > >> setup-bus.c::pci_bridge_check_ranges() > > This is only checking that the upper 32bits is actually implemented, > should we have already set the IORESOURCE_MEM_64 from the function > above, which we haven't. > > So, in my case I have a 64bit capable prefetchable range, that the BIOS > has not programmed and is not required to program. We assign it to a > 32bit window, and never touch the UPPER32 registers. are you using 32bit kernel? YH -- 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
