Yinghai Lu <yinghai@xxxxxxxxxx> writes: > On Fri, Feb 20, 2009 at 11:50 PM, Eric W. Biederman > <ebiederm@xxxxxxxxxxxx> wrote: >> Robert Hancock <hancockrwd@xxxxxxxxx> writes: >>> >>> Is there a reason why we can't just enable the HT MSI mapping for any bridge >>> device that has that PCI capability and is underneath an HT bridge? >> >> The code should be under CONFIG_X86 because the rules for enabling HT MSI > mappings >> are different for other architectures. But otherwise I can't think of a > reason. > > move to arch/x86/pci/fixup.c? > > it seems some other arch do support HT ... powerpc, mips? The difference is that there is a magic address on x86 that all MSI cycles are sent to. I think it is 0xfffe0000. In an msi to HT mapping capability it is necessary to program in the address to listen for msi packets. That is very much an arch dependent thing. >>> Essentially >>> the code for nv_msi_ht_cap_quirk could potentially be applied to all bridges > as >>> it is currently for NVIDIA and ALi bridges.. >> >> Sounds like it would save a fair amount of grief. > > it seems there is some difference. > 8132 is some kind of HT tunnel, and the bridge is acctually pci-x bridge. > > mcp55 and ck804: is HT end device with several pcie bridges. Not really they are all hypertransport to pci bridges (of some flavor). But any hypertransport device is allowed to have a mapping capability. In which case they can implement normal MSI interrupts instead of the weird hypertransport ones. > also 8131 has problem with HT MSI? The 8131 does not implement the msi to hypertransport mapping capability so it can not support MSI interrupts. In general on x86, if a device has a MSI to hypertransport mapping capability then we can enable it and mark that devices and all downstream devices as supporting MSI. Eric -- 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
