[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1170114003.26655.291.camel@localhost.localdomain>
Date: Tue, 30 Jan 2007 10:40:03 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Paul Mackerras <paulus@...ba.org>
Cc: michael@...erman.id.au, tony.luck@...el.com,
grundler@...isc-linux.org, jeff@...zik.org,
David Miller <davem@...emloft.net>, greg@...ah.com,
linux-kernel@...r.kernel.org, kyle@...isc-linux.org,
linuxppc-dev@...abs.org,
"Eric W. Biederman" <ebiederm@...ssion.com>, shaohua.li@...el.com,
linux-pci@...ey.karlin.mff.cuni.cz, mingo@...e.hu, brice@...i.com
Subject: Re: [PATCH 0/6] MSI portability cleanups
> It's possible that the device can do MSI(X), but that using MSI(X)
> requires other platform resources (e.g. interrupt source numbers) and
> there are none free. I believe the platform guarantees a minimum
> number of MSI(X) interrupts per function, but a pci_enable_msix() call
> may not be able to give the driver as many MSI-X interrupts as it is
> requesting even if the function can handle that many.
However, the ibm,req#msi(-x) properties contain the number as requested
by the device, and thus I expect them to be identical to the config
space value. So if you are confident enough that our HV won't play any
tricks there in the future, reading the config space is as good as
hooking that check() callback, though it might not be vs. some other HV
for some other platform that might be more strict.
We cannot know in advance how much max the HV will give us without
actually trying ibm,change-msi and see the result code for it
unfortunately.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists