Re: [PATCH] pci: enable MSI on 8132

[Robert Hancock]

Yinghai Lu wrote:
> Eric W. Biederman wrote:
> > 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.
> for mcp55
> 00:00.0 is HT device
> 00:0b.0 00:0c.0, 00:0d.0, 00:0e.0, 00:0f.0 are pcie bridge.
> current quirks will check 00:00.0 HT MSI is set, it will not set that in those bridges any more.
>
> > > 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.
> it seems there is one quirks to disable MSI for 8131.
> /* Disable MSI on chipsets that are known to not support it */
> static void __devinit quirk_disable_msi(struct pci_dev *dev)
> {
>         if (dev->subordinate) {
>                 dev_warn(&dev->dev, "MSI quirk detected; "
>                         "subordinate MSI disabled\n");
>                 dev->subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
>         }
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_disable_msi);
>
>
> > 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.
>
> looks some aggressive.

Not really.. we don't really "mark devices as supporting MSI" right now, 
we generally mark them as not supporting it in certain cases and by 
default assume they do. So if a quirk doesn't hit on a particular 
chipset, then we go ahead and enable it. If there's some reason it 
doesn't work or we don't do something that's needed to make it work, and 
the driver requests it, we'll use it and it just won't work properly. So 
it's not really any more aggressive than what we have now..

It seems like we have kind of a random mix of MSI quirks related to MSI 
mappings:

Serverworks HT2000: check if PCIE bridge has MSI mapping enabled, if not 
disable MSI on PCIE bridge subordinate bus

NVIDIA CK804: check if HT MSI mapping enabled either on root bridge or 
on the PCIE bridge device, if not, disable MSI on PCIE bridge 
subordinate bus

Serverworks HT1000 (and proposed AMD 8132): just switch on HT MSI 
mapping on bridge device

All NVIDIA and ALi (which does appear to overlap with the CK804 one): If 
bus 0 device 0 function 0 is an HT slave, enable its MSI mapping, 
otherwise disable it

It seems like these could be combined into something like:

-For all buses, check if any device on the bus is an HT slave, if so, 
enable its HT MSI mapping. If not, disable it. (Should we also disable 
MSI on the bus if we disable it or there's no mapping capability? I 
would guess we likely should..)

-For all PCI bridges other than device 0 function 0 that have HT MSI 
Mapping capability, check if our bus (or an upstream one?) has a device 
marked as an HT slave with enabled MSI mapping. If so, then enable the 
capability, if not then disable it and disable MSI on subordinate bus.

Essentially it should make sure that the mappings are enabled all the 
way up the chain, and if they can't be then we disable MSI. This could 
be totally wrong though, I don't know HT that well, hopefully someone 
else does :-)

There's the issue that Eric pointed out about the MSI mapping address 
possibly not being set up on some platforms. However, right now we'll 
just blindly try and use MSI on such setups anyway, so I don't see it's 
really worsening the situation.

We would also still need the 8131 quirk, since presumably it doesn't 
have HT MSI Mapping capability so we wouldn't know to disable MSI on it 
from the above.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/