Re: [patch 3/7] Check root chipset no_msi flag instead of all parent busses flags

[Grant Grundler <grundler@parisc-linux.org>]

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/