Messages in this thread | | | Date | Tue, 4 Jul 2006 21:48:29 -0600 | From | Grant Grundler <> | Subject | Re: [patch 3/7] Check root chipset no_msi flag instead of all parent busses flags |
| |
On Tue, Jul 04, 2006 at 07:12:25PM -0400, Brice Goglin wrote: > Grant Grundler wrote: > > If the "root chipset" is not a PCI device and the architecture doesn't > > fake it, the root chipset (aka "PCI Host bus controller") is not visible > > to PCI subsystem. Some of the arch code (e.g. drivers/parisc/dino.c) > > uses "bus->self == NULL" to differentiate between PCI-PCI secondary busses > > and PCI bus below a "root chipset". ISTR alpha and sparc doing the same. > > > > Can you confirm I'm remembering/understanding this bit correctly? > > > > I am not familiar enough with these architectures, but I guess somebody > else is.
I've looked at alpha PCI code in the past (never changed it) and wrote nearly all of the parisc PCI support.
> Are MSI working on these architectures?
Not yet. But MSI support on parisc will be a summer project for me. Alpha and SPARC also use transaction based interrupts to get the attention of the CPU. So I expect MSI is possible on them.
> The MSI code in Linux seems to > be very specific so far. And CONFIG_PCI_MSI currently depends on > (X86_LOCAL_APIC && X86_IO_APIC) || IA64
I believe PPC folks are also working on support.
> > I don't see how this could work for alpha/parisc/sparc (IIRC) or any other > > architecture that doesn't create "fake" PCI Root busses. > > I think your previous patch was correct in this regard. > > I don't think it was better. I had the same loop to find the root > chipset. Only the check afterwards has been changed: instead of checking > the subordinate bus flags on the root chipset, I checks its no_msi. Both > patches applied to these architectures would fail to find the root > chipset in the while loop. They will find a bridge right under the root > chipset (or the device itself). The flags are then checked on the bridge > bus, not on the bus that is right under the root chipset.
Right - the "bridge bus" check is different than a "PCI Host bus controller" device check.
> Anyway, assuming that Linux supports MSI on any of these architectures > and that we find a root chipset that does not support MSI, how would we > blacklist it? There's no way to add a quirk if there is no pci_dev > associated to this root chipset, right?
Right. parisc/ia64/et al don't need a generic black list. It's x86 or x86-64 specific. At least until the various "x86-like" architectures use the same chipsets.
The arch support _could_ mark a flag in the "root" struct pci_bus. We wouldn't (yet) need a quirk on those arches. I think I might have a better idea below to implement parisc support that works with the MSI flag in struct pci_dev like you want it.
> Assuming we find a place to add some code to disable MSI > (pcibios_fixup_foo?),
Yes, pcibios_fixup_bus is normally the first chance for the arch specific code to mangle the struct pci_bus allocated by generic PCI code.
> we would have to set a no_msi flag somewhere. > It might be good to revive the bus flags for this case. But, that's a lot > of "assuming", I'd rather know whether all this is possible first :)
MSI is certainly possible on parisc. I'm pretty sure it's possible on ppc, alpha and sparc though I don't know details. This has been discussed before...but I can't find the references.
Maybe the right "somewhere" is for pcibios_fixup_bus() to enable (or disable) MSI on each real PCI device if/when the arch can determine MSI in fact works. I didn't think of this option last night.
I still don't want the generic PCI code to assume a "root" PCI Host bus controller was found after that loop.
thanks, grant - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |