Change Details

Existing qpi.c makes too many assumptions about the uncore configuration buses location and about slots occupied. On the 2600 v2 (Ivy) machine I have access to, the buses have numbers 31 (BSP socket) and 63 (second socket), and there is no functions pci0.31.0.0 or pci0.63. According to EDS, all devices on the uncore bus occupy slot >= 8. Scan all buses, not stopping on the first failed match. Scan all slots for function 0 on the found bus, for instance on Ivy there the slot 0 is not decoded at all. Since the scan is quite unsafe, and access to the buses is mostly useful for developers, enable the csr buses scan with the tunable. Practically, the attach to config buses is required for the intel-pcm pcm-memory.x tool to work, for instance. I wonder whether qpi attach should have lower priority to ensure that other bus drivers already attached, so that we do not force some innocent normal PCI bus under qpi.

Existing qpi.c makes too many assumptions about the uncore configuration buses location and about slots occupied. Also it restricts itself only to Nehalem CPUs. It should be useful on all Core-based Xeons. On the 2600 v2 (Ivy) machine I have access to, the buses have numbers 31 (BSP socket) and 63 (second socket), and there is no functions pci0.31.0.0 or pci0.63. According to EDS, all devices on the uncore bus occupy slot >= 8. Scan all buses, not stopping on the first failed match. Scan all slots for function 0 on the found bus, for instance on Ivy there the slot 0 is not decoded at all. Since the scan is quite unsafe, and access to the buses is mostly useful for developers, enable the csr buses scan with the tunable. Practically, the attach to config buses is required for the intel-pcm pcm-memory.x tool to work, for instance. I wonder whether qpi attach should have lower priority to ensure that other bus drivers already attached, so that we do not force some innocent normal PCI bus under qpi.

Existing qpi.c makes too many assumptions about the uncore configuration buses location and about slots occupied. Also it restricts itself only to Nehalem CPUs. It should be useful on all Core-based Xeons. On the 2600 v2 (Ivy) machine I have access to, the buses have numbers 31 (BSP socket) and 63 (second socket), and there is no functions pci0.31.0.0 or pci0.63. According to EDS, all devices on the uncore bus occupy slot >= 8. Scan all buses, not stopping on the first failed match. Scan all slots for function 0 on the found bus, for instance on Ivy there the slot 0 is not decoded at all. Since the scan is quite unsafe, and access to the buses is mostly useful for developers, enable the csr buses scan with the tunable. Practically, the attach to config buses is required for the intel-pcm pcm-memory.x tool to work, for instance. I wonder whether qpi attach should have lower priority to ensure that other bus drivers already attached, so that we do not force some innocent normal PCI bus under qpi.