x86, pci: Handle fallout pci devices with peer root bus
in [Kernel]
|
Prev: vmscan: simplify shrink_inactive_list()
Next: vmscan: Remove unnecessary temporary vars in do_try_to_free_pages
From: Jesse Barnes on 14 Jun 2010 14:20 On Mon, 14 Jun 2010 10:47:59 -0700 Yinghai Lu <yinghai.lu(a)oracle.com> wrote: > > Graham bisected > | commit 3e3da00c01d050307e753fb7b3e84aefc16da0d0 > | x86/pci: AMD one chain system to use pci read out res > > cause the SND_HDA_INTEL doesn't work anymore. > > https://bugzilla.kernel.org/show_bug.cgi?id=16007 > > It turns out that his system with via chipset only have one hypertransport > chain, but does have one extra orphan device 80:01.0 > > PCI: Probing PCI hardware (bus 00) > PCI: Discovered primary peer bus 80 [IRQ] > > node 0 link 0: io port [1000, ffffff] > TOM: 0000000080000000 aka 2048M > node 0 link 0: mmio [e0000000, efffffff] > node 0 link 0: mmio [a0000, bffff] > node 0 link 0: mmio [80000000, ffffffff] > bus: [00, ff] on node 0 link 0 > > Try to make peer root buses to share same mmio/io resources if those peer root > buses fall into the same bus range. > > Also need to update insert_resource to avoid insert same resource two times. So 3e3da00c01d050307e753fb7b3e84aefc16da0d0 was supposed to address the case where some laptop RAM ranges ended up incorrect. Would using _CRS on those machines also address that problem? If so, we should consider dropping amd_bus.c like we did with intel_bus.c. Yinghai, do you still have people from the RAM bug that could test using _CRS data? -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 14 Jun 2010 14:30 On 06/14/2010 11:14 AM, Jesse Barnes wrote: > On Mon, 14 Jun 2010 10:47:59 -0700 > Yinghai Lu <yinghai.lu(a)oracle.com> wrote: > >> >> Graham bisected >> | commit 3e3da00c01d050307e753fb7b3e84aefc16da0d0 >> | x86/pci: AMD one chain system to use pci read out res >> >> cause the SND_HDA_INTEL doesn't work anymore. >> >> https://bugzilla.kernel.org/show_bug.cgi?id=16007 >> >> It turns out that his system with via chipset only have one hypertransport >> chain, but does have one extra orphan device 80:01.0 >> >> PCI: Probing PCI hardware (bus 00) >> PCI: Discovered primary peer bus 80 [IRQ] >> >> node 0 link 0: io port [1000, ffffff] >> TOM: 0000000080000000 aka 2048M >> node 0 link 0: mmio [e0000000, efffffff] >> node 0 link 0: mmio [a0000, bffff] >> node 0 link 0: mmio [80000000, ffffffff] >> bus: [00, ff] on node 0 link 0 >> >> Try to make peer root buses to share same mmio/io resources if those peer root >> buses fall into the same bus range. >> >> Also need to update insert_resource to avoid insert same resource two times. > > So 3e3da00c01d050307e753fb7b3e84aefc16da0d0 was supposed to address the > case where some laptop RAM ranges ended up incorrect. Would using _CRS > on those machines also address that problem? If so, we should consider > dropping amd_bus.c like we did with intel_bus.c. > > Yinghai, do you still have people from the RAM bug that could test > using _CRS data? I can not find the mail anymore. looks like someone is using one AMD k8 Aruma laptop for firewire development. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 14 Jun 2010 14:50 On 06/14/2010 11:34 AM, Bjorn Helgaas wrote: > > I made the point there that an HT chain may contain multiple HT/PCI > host bridges, but you are stuck on the idea that "one HT chain == one > PCI root bus." > > I have not found the "one PCI host bridge per HT chain" requirement > in the HT spec (if you find it, please point me to it). > > If an HT chain may contain multiple HT/PCI host bridges, then it's > obvious that the HT host bridge registers read by amd_bus.c don't > contain enough information to correctly assign address space to the > PCI root buses. > A HT-to-PCI bridge appears as a PCI-to-PCI bridge (i.e. a Header Type 1 device), not as a host bridge (a Header Type 0 device). That is at least the software model as defined. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 14 Jun 2010 15:00 On 06/14/2010 11:39 AM, H. Peter Anvin wrote: > On 06/14/2010 11:34 AM, Bjorn Helgaas wrote: >> >> I made the point there that an HT chain may contain multiple HT/PCI >> host bridges, but you are stuck on the idea that "one HT chain == one >> PCI root bus." should be. >> >> I have not found the "one PCI host bridge per HT chain" requirement >> in the HT spec (if you find it, please point me to it). according to my experience with LinuxBIOS. AMD chipset, nvidia and serverworks (broadcom) >> >> If an HT chain may contain multiple HT/PCI host bridges, then it's >> obvious that the HT host bridge registers read by amd_bus.c don't >> contain enough information to correctly assign address space to the >> PCI root buses. the host bridges is on AMD CPUs, >> > > A HT-to-PCI bridge appears as a PCI-to-PCI bridge (i.e. a Header Type 1 > device), not as a host bridge (a Header Type 0 device). > > That is at least the software model as defined. one HT chain could have some HT devices, HT devices could be HT tunnel or HT bridge. If it is HT tunnel, the next device will use same primary pci bus number with some addon device number. It it is HT bridge, will like some kind pci-to-pci bridge. link between KT890 and vt32551? is some kind va-link? it is not HT between them somehow the southbridge vt32551 respond the sound_intel from 80:01.0... and it is supposed to be under some pci bridge. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 14 Jun 2010 16:10
On 06/14/2010 01:00 PM, Bjorn Helgaas wrote: >> >> the host bridges is on AMD CPUs, > > Don't confuse the HT host bridge with the PCI host bridge. The HT I/O spec > is quite clear that it uses "host bridge" to refer to the HT host bridge, > i.e., the interface between CPUs and a HyperTransport link. > > I agree that the *HT host bridge* is indeed on the AMD CPU. But that is > certainly not the same as the PCI host bridge that bridges between an HT > link and a PCI bus. > > See sections 4.9.4 (HT host bridge) and 7.4 (HT/PCI host bridge), for > example. > From a software point of view the latter is [largely] a PCI-to-PCI bridge, though; it's not a root-level host bridge in the classical sense (as noted in section 7.4). Incidentally, in my copy of HT 3.10b, section 7.4 is marked "HyperTransport Bridge Headers", and does not use the term "host bridge" to refer to a secondary PCI bus. Section 4.9.4 is simply marked "Host Bridge". As such, I think the HT spec is pretty consistent about unambiguously referring to the HT host bridge when using the term "host bridge". -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |