30 Jun, 2009
1 commit
-
These names are too long! Drop _OFFSET to save some bytes/lines.
Reviewed-by: Matthew Wilcox
Signed-off-by: Hidetoshi Seto
Signed-off-by: Jesse Barnes
12 Jun, 2009
2 commits
-
Impact: cleanup, improve readability
Define PCI_MSI_MASK_32/64 for 32/64bit devices, instead of using
implicit offset (-4), "PCI_MSI_MASK_BIT - 4" and "PCI_MSI_MASK_BIT".Signed-off-by: Hidetoshi Seto
Reviewed-by: Matthew Wilcox
Signed-off-by: Jesse Barnes -
Impact: cleanup, spec compliance
This patch does:
- Remove unused msi/msix_enable/disable macros.
User should use msi/msix_set_enable() functions instead.- Remove unused msix_mask/unmask/pending macros.
These macros are useless because they are not based on any of
the PCI Local Bus Specifications properly.
It seems that they were written based on a draft of PCI spec,
and that the draft was the MSI-X ECN that underwent membership
review in September 2002.
(* In the draft, the size of a entry in MSI-X table was 64bit,
containing 32bit message data and DWORD aligned lower address
plus a pending bit and a mask bit.(30+1+1bit) The higher
address was placed in MSI-X capability structure and shared
by all entries.)- Remove PCI_MSIX_FLAGS_BITMASK.
This definition also come from the draft ECN.Signed-off-by: Hidetoshi Seto
Reviewed-by: Matthew Wilcox
Signed-off-by: Jesse Barnes
21 Mar, 2009
1 commit
-
Add the new API pci_enable_msi_block() to allow drivers to
request multiple MSI and reimplement pci_enable_msi in terms of
pci_enable_msi_block. Ensure that the architecture back ends don't
have to know about multiple MSI.Signed-off-by: Matthew Wilcox
Signed-off-by: Jesse Barnes
02 Dec, 2006
1 commit
-
Move some MSI-X #defines into pci_regs.h so they can be used
outside of drivers/pci.Signed-off-by: Michael Ellerman
Signed-off-by: Greg Kroah-Hartman
04 Oct, 2006
7 commits
-
It turns out msi_ops was simply not enough to abstract the architecture
specific details of msi. So I have moved the resposibility of constructing
the struct irq_chip to the architectures, and have two architecture specific
functions arch_setup_msi_irq, and arch_teardown_msi_irq.For simple architectures those functions can do all of the work. For
architectures with platform dependencies they can call into the appropriate
platform code.With this msi.c is finally free of assuming you have an apic, and this
actually takes less code.The helpers for the architecture specific code are declared in the linux/msi.h
to keep them separate from the msi functions used by drivers in linux/pci.hSigned-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Tony Luck
Cc: Andi Kleen
Cc: Thomas Gleixner
Cc: Greg KH
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Currently msi.c is doing sanity checks that make certain before an irq is
destroyed it has no more users.By adding irq_has_action I can perform the test is a generic way, instead of
relying on a msi specific data structure.By performing the core check in dynamic_irq_cleanup I ensure every user of
dynamic irqs has a test present and we don't free resources that are in use.In msi.c this allows me to kill the attrib.state member of msi_desc and all of
the assciated code to maintain it.To keep from freeing data structures when irq cleanup code is called to soon
changing dyanamic_irq_cleanup is insufficient because there are msi specific
data structures that are also not safe to free.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Tony Luck
Cc: Andi Kleen
Cc: Thomas Gleixner
Cc: Greg KH
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The msi currently allocates irqs backwards. First it allocates a platform
dependent routing value for an interrupt the ``vector'' and then it figures
out from the vector which irq you are on.For ia64 this is fine. For x86 and x86_64 this is complete nonsense and makes
an enourmous mess of the irq handling code and prevents some pretty
significant cleanups in the code for handling large numbers of irqs.This patch refactors msi.c to work in terms of irqs and create_irq/destroy_irq
for dynamically managing irqs.Hopefully this is finally a version of msi.c that is useful on more than just
x86 derivatives.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Rajesh Shah
Cc: Andi Kleen
Cc: "Protasevich, Natalie"
Cc: "Luck, Tony"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Currently we attempt to predict how many irqs we will be able to allocate with
msi using pci_vector_resources and some complicated accounting, and then we
only allow each device as many irqs as we think are available on average.Only the s2io driver even takes advantage of this feature all other drivers
have a fixed number of irqs they need and bail if they can't get them.pci_vector_resources is inaccurate if anyone ever frees an irq. The whole
implmentation is racy. The current irq limit policy does not appear to make
sense with current drivers. So I have simplified things. We can revisit this
we we need a more sophisticated policy.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Rajesh Shah
Cc: Andi Kleen
Cc: "Protasevich, Natalie"
Cc: "Luck, Tony"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The current msi_ops are short sighted in a number of ways, this patch attempts
to fix the glaring deficiences.- Report in msi_ops if a 64bit address is needed in the msi message, so we
can fail 32bit only msi structures.- Send and receive a full struct msi_msg in both setup and target. This is
a little cleaner and allows for architectures that need to modify the data
to retarget the msi interrupt to a different cpu.- In target pass in the full cpu mask instead of just the first cpu in case
we can make use of the full cpu mask.- Operate in terms of irqs and not vectors, currently there is still a 1-1
relationship but on architectures other than ia64 I expect this will change.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Rajesh Shah
Cc: Andi Kleen
Cc: "Protasevich, Natalie"
Cc: "Luck, Tony"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
In support of this I also add a struct msi_msg that captures the the two
address and one data field ina typical msi message, and I remember the pos and
if the address is 64bit in struct msi_desc.This makes the code a little more readable and easier to maintain, and paves
the way to further simplfications.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Rajesh Shah
Cc: Andi Kleen
Cc: "Protasevich, Natalie"
Cc: "Luck, Tony"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This allows the output of the msi tests to be stored directly in a bit field.
If you don't do this a value greater than one will be truncated and become 0.
Changing true to false with bizare consequences.Signed-off-by: Eric W. Biederman
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Rajesh Shah
Cc: Andi Kleen
Cc: "Protasevich, Natalie"
Cc: "Luck, Tony"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 Jun, 2006
1 commit
-
Abstract portions of the MSI core for platforms that do not use standard
APIC interrupt controllers. This is implemented through a new arch-specific
msi setup routine, and a set of msi ops which can be set on a per platform
basis.Signed-off-by: Mark Maule
Signed-off-by: Greg Kroah-Hartman
01 Feb, 2006
1 commit
-
I missed this usage in drivers/pci/msi.h:
#ifdef CONFIG_SMP
#define set_msi_irq_affinity set_msi_affinity
#else
#define set_msi_irq_affinity NULL
#endifset_msi_affinity() is declared and exclusively used in msi.c.
Here's a better way so (hopefully) history doesn't repeat itself.Signed-off-by: Grant Grundler
Signed-off-by: Greg Kroah-Hartman
08 Sep, 2005
1 commit
-
When handling writes to /proc/irq, current code is re-programming rte
entries directly. This is not recommended and could potentially cause
chipset's to lockup, or cause missing interrupts.CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the
interrupt is pending. The same needs to be done for /proc/irq handling as well.
Otherwise user space irq balancers are really not doing the right thing.- Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for
lack of a generic name.
- added move_irq out of IRQ_BALANCE, and added this same to X86_64
- Added new proc handler for write, so we can do deferred write at irq
handling time.
- Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead
it now shows only active cpu masks, or exactly what was set.
- Provided a common move_irq implementation, instead of duplicating
when using generic irq framework.Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off.
Tested UP builds as well.MSI testing: tbd: I have cards, need to look for a x-over cable, although I
did test an earlier version of this patch. Will test in a couple days.Signed-off-by: Ashok Raj
Acked-by: Zwane Mwaikambo
Grudgingly-acked-by: Andi Kleen
Signed-off-by: Coywolf Qi Hunt
Signed-off-by: Ashok Raj
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
28 Jun, 2005
1 commit
-
Mostly just cleans up the irq handling logic to be smaller and a bit more
descriptive as to what it really does.Signed-off-by: Greg Kroah-Hartman
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
