summaryrefslogtreecommitdiffstats
path: root/arch/sparc64/kernel/irq.c
Commit message (Collapse)AuthorAgeFilesLines
* sparc64: Always allocate the send mondo blocks, even on non-sun4v.David S. Miller2008-08-041-3/+16
| | | | | | | The idea is that we'll use this cpu list array and mondo block even for non-hypervisor platforms. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Fix lockdep issues in LDC protocol layer.David S. Miller2008-07-221-1/+9
| | | | | | | | | | | | | | | | | | | | We're calling request_irq() with a IRQs disabled. No straightforward fix exists because we want to enable these IRQs and setup state atomically before getting into the IRQ handler the first time. What happens now is that we mark the VIRQ to not be automatically enabled by request_irq(). Then we make explicit enable_irq() calls when we grab the LDC channel. This way we don't need to call request_irq() illegally under the LDC channel lock any more. Bump LDC version and release date. Signed-off-by: David S. Miller <davem@davemloft.net>
* sparc64: Fix wedged irq regression.David S. Miller2008-04-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kernel bugzilla 10273 As reported by Jos van der Ende, ever since commit 5a606b72a4309a656cd1a19ad137dc5557c4b8ea ("[SPARC64]: Do not ACK an INO if it is disabled or inprogress.") sun4u interrupts can get stuck. What this changset did was add the following conditional to the various IRQ chip ->enable() handlers on sparc64: if (unlikely(desc->status & (IRQ_DISABLED|IRQ_INPROGRESS))) return; which is correct, however it means that special care is needed in the ->enable() method. Specifically we must put the interrupt into IDLE state during an enable, or else it might never be sent out again. Setting the INO interrupt state to IDLE resets the state machine, the interrupt input to the INO is retested by the hardware, and if an interrupt is being signalled by the device, the INO moves back into TRANSMIT state, and an interrupt vector is sent to the cpu. The two sun4v IRQ chip handlers were already doing this properly, only sun4u got it wrong. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Fix sparse warnings in arch/sparc64/kernel/irq.cDavid S. Miller2008-03-261-19/+2
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* misc: removal of final callers using fastcallHarvey Harrison2008-02-081-1/+1
| | | | | | Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [SPARC64]: Stop using __do_IRQ().David S. Miller2007-10-221-47/+38
| | | | | | | | | Invoke the desc->handle_irq directly in the top-level dispatch, just like other sophisticated ports. This will allow us to decrease the cost of the MSI queue dispatch. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Fix boot failures due to bootmem.David S. Miller2007-10-171-4/+4
| | | | | | | | Do not use *alloc_bootmem_low*(), because ARCH_LOW_ADDRESS_LIMIT is 4GB and this results in boot failures if all of the physical memory in the machine is above 4GB. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: virt_to_real_irq_table --> virt_irq_tableDavid S. Miller2007-10-131-20/+20
| | | | | | | It no longer translates to "real irqs" (aka. INO buckets) so reflect that by using a simpler name for it. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: virt_irq --> bucket mapping no longer necessaryDavid S. Miller2007-10-131-11/+8
| | | | | | | We used to need this to compute virt_irq --> ino, but that is no longer necessary. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill ugly __bucket() macro.David S. Miller2007-10-131-146/+92
| | | | | | | | | | | All the users go through virt_irq_to_bucket() and essentially want to go from a virt_irq to an INO, but we have a way to do that already via virt_to_real_irq_table[].dev_ino. This also allows us to kill both virt_to_real_irq() and virt_irq_to_bucket(). Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill ugly __irq_ino() macro.David S. Miller2007-10-131-11/+11
| | | | | | | | We have a place to stick INO information in the virt_to_real_irq_table[], which is currently only used for VIRQs. And that is readily accessible from the one __irq_ino() call site. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Only use bypass accesses to INO buckets.David S. Miller2007-10-131-31/+91
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Use sun4v VIRQ interfaces as intended.David S. Miller2007-10-131-11/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | We were simply concatenating the devhandle and devino and using that as the cookie, which defeats the entire purpose of the VIRQ hypervisor interfaces. Now that we use physical addresses for the INO buckets, we can allocate them dynamically for VIRQs and encode the cookies as ~__pa(bucket). This allows us to test for and decode the cookie with a simple: brlz $reg1, 1f xnor $reg1, %g0, $reg2 sequence. This works because bit 64 is never set in traditional INO vectors, and it is also never set in a physical address. So xnor'ing the physical address of the bucket always gives us a negative number, and thus a unique condition we can test cheaply. Inspired by ideas from Greg Onufer. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Allocate ivector_table dynamically.David S. Miller2007-10-131-11/+11
| | | | | | | Shrinks kernel by 16K compared to before the IVEC physical address changes. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Access ivector_table[] using physical addresses.David S. Miller2007-10-131-22/+34
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Make IVEC pointers 64-bit.David S. Miller2007-10-131-17/+24
| | | | | | | | | | | | | | | Currently we chain IVEC entries using 32-bit "pointers" because we know that the ivector_table is in the main kernel image, thus below 4GB. This uses proper 64-bit pointers instead. Whilst this bloats up the kernel image size, this sets the infrastructure necessary to significantly shrink the kernel size by using physical addresses and dynamically allocating the ivector table. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Consolidate MSI support code.David S. Miller2007-10-131-207/+23
| | | | | | | | | | | | | | | | This also makes us use the MSI queues correctly. Each MSI queue is serviced by a normal sun4u/sun4v INO interrupt handler. This handler runs the MSI queue and dispatches the virtual interrupts indicated by arriving MSIs in that MSI queue. All of the common logic is placed in pci_msi.c, with callbacks to handle the PCI controller specific aspects of the operations. This common infrastructure will make it much easier to add MSG support. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Enable MSI on sun4u Fire PCI-E controllers.David S. Miller2007-10-131-0/+71
| | | | | | | | The support code is identical to the hypervisor sun4v stuff, just replacing the hypervisor calls with register reads and writes in the Fire controller. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Fix several bugs in MSI handling.David S. Miller2007-08-301-3/+22
| | | | | | | | | | | | | | | | | | | | | 1) sun4{u,v}_build_msi() have improper return value handling. We should always return negative error codes, instead of using the magic value "0" which could in fact be a valid MSI number. 2) sun4{u,v}_build_msi() should return -ENOMEM instead of calling prom_prom() halt with kzalloc() of the interrupt data fails. 3) We 'remembered' the MSI number using a singleton in the struct device archdata area, this doesn't work for MSI-X which can cause multiple MSIs assosciated with one device. Delete that archdata member, and instead store the MSI number in the IRQ chip data area. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Fix type and constant sizes wrt. sun4u IMAP/ICLR handling.David S. Miller2007-08-301-1/+1
| | | | | | | | Sometimes we were using 32-bit values and the top bits were getting inadvertantly chopped off. This will matter for the forthcoming Fire controller MSI support. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Fix memory leak when cpu hotplugging.David S. Miller2007-08-081-50/+24
| | | | | | | | | | | Every time a cpu is added via hotplug, we allocate the per-cpu MONDO queues but we never free them up. Freeing isn't easy since the first cpu gets this memory from bootmem. Therefore, the simplest thing to do to fix this bug is to allocate the queues for all possible cpus at boot time. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Fix virq decomposition.David S. Miller2007-07-201-19/+25
| | | | | | | | | The dev_handle and dev_ino fields don't match up exactly to the traditional IMAP_IGN and IMAP_INO masks. So store them away in a table and look them up directly. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Use KERN_ERR in IRQ manipulation error printks.David S. Miller2007-07-201-14/+14
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Tweak assertions in sun4v_build_virq().David S. Miller2007-07-191-2/+2
| | | | | | They are too strict. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: dr-cpu unconfigure support.David S. Miller2007-07-161-0/+20
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Add ->set_affinity IRQ handlers.David S. Miller2007-07-161-0/+52
| | | | | | | | dr-cpu unconfigure requests will walk throught he enabled IRQs and trigger ->set_affinity so that the going-down cpu no longer has INOs targetted to it. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Do not ACK an INO if it is disabled or inprogress.David S. Miller2007-07-161-0/+12
| | | | | | | | | | | | | | | | | | | This is also a partial workaround for a bug in the LDOM firmware which double-transmits RX inos during high load. Without this, such an event causes the kernel to loop forever in the interrupt call chain ACK'ing but never actually running the IRQ handler (and thus clearing the interrupt condition in the device). There is still a bad potential effect when double INOs occur, not covered by this changeset. Namely, if the INO is already on the per-cpu INO vector list, we still blindly re-insert it and thus we can end up losing interrupts already linked in after it. We could deal with that by traversing the list before insertion, but that's too expensive for this edge case. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Need to set state to IDLE during sun4v IRQ enable.David S. Miller2007-06-261-0/+4
| | | | | | This fixes hypervisor console interrupts on LDOM guests. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Fix VIRQ enabling.David S. Miller2007-06-261-1/+7
| | | | | | | We were doing the wrong call to turn them on, and also when enabling we need to forcefully set the state to IDLE. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Wire up cookie based sun4v interrupt registry.David S. Miller2007-06-131-9/+122
| | | | | | This will be used for logical domain channel interrupts. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Use machine description and OBP properly for cpu probing.David S. Miller2007-05-291-30/+53
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: SUN4U PCI-E controller support.David S. Miller2007-05-061-6/+10
| | | | | | | | | | | | | | | | | | | | | Some minor refactoring in the generic code was necessary for this: 1) This controller requires 8-byte access to the interrupt map and clear register. They are 64-bits on all the other SBUS and PCI controllers anyways, so this was easy to cure. 2) The IMAP register has a different layout and some bits that we need to preserve, so use a read/modify/write when making changes to the IMAP register in generic code. 3) Flushing the entire IOMMU TLB is best done with a single write to a register on this PCI controller, add a iommu->iommu_flushinv for this. Still lacks MSI support, that will come later. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: constify of_get_property return: arch/sparc64Stephen Rothwell2007-04-261-1/+1
| | | | | Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Unify timer interrupt handler.David S. Miller2007-04-261-26/+0
| | | | | | | | | Things were scattered all over the place, split between SMP and non-SMP. Unify it all so that dyntick support is easier to add. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: virt_irq_free only needed when CONFIG_PCI_MSIDavid S. Miller2007-02-261-0/+2
| | | | | | Noticed by Meelis Roos. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Add PCI MSI support on Niagara.David S. Miller2007-02-101-9/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is kind of hokey, we could use the hardware provided facilities much better. MSIs are assosciated with MSI Queues. MSI Queues generate interrupts when any MSI assosciated with it is signalled. This suggests a two-tiered IRQ dispatch scheme: MSI Queue interrupt --> queue interrupt handler MSI dispatch --> driver interrupt handler But we just get one-level under Linux currently. What I'd like to do is possibly stick the IRQ actions into a per-MSI-Queue data structure, and dispatch them form there, but the generic IRQ layer doesn't provide a way to do that right now. So, the current kludge is to "ACK" the interrupt by processing the MSI Queue data structures and ACK'ing them, then we run the actual handler like normal. We are wasting a lot of useful information, for example the MSI data and address are provided with ever MSI, as well as a system tick if available. If we could pass this into the IRQ handler it could help with certain things, in particular for PCI-Express error messages. The MSI entries on sparc64 also tell you exactly which bus/device/fn sent the MSI, which would be great for error handling when no registered IRQ handler can service the interrupt. We override the disable/enable IRQ chip methods in sun4v_msi, so we have to call {mask,unmask}_msi_irq() directly from there. This is another ugly wart. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64] IRQ: Use irq_desc->chip_data instead of irq_desc->handler_dataDavid S. Miller2007-02-101-24/+20
| | | | | | | | | Otherwise we can't use the generic MSI code. Furthermore, properly use the {get,set}_irq_foo() abstracted interfaces instead of direct accesses to irq_desc[]->foo. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Minor irq handling cleanups.David S. Miller2006-12-171-20/+4
| | | | | | | | Use struct irq_chip instead of hw_interrupt_type. Delete hw_resend_irq(), totally unused. Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] sparc64 irq pt_regs falloutAl Viro2006-10-091-2/+5
| | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] sparc64 pt_regs fixesAl Viro2006-10-081-1/+4
| | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Remove obsolete #include <linux/config.h>Jörn Engel2006-06-301-1/+0
| | | | | Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* [SPARC64]: Let irq_install_pre_handler() get called multiple times.David S. Miller2006-06-291-0/+4
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] genirq: cleanup: merge irq_affinity[] into irq_desc[]Ingo Molnar2006-06-291-1/+1
| | | | | | | | | | | Consolidation: remove the irq_affinity[NR_IRQS] array and move it into the irq_desc[NR_IRQS].affinity field. [akpm@osdl.org: sparc64 build fix] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] genirq: rename desc->handler to desc->chipIngo Molnar2006-06-291-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch-queue improves the generic IRQ layer to be truly generic, by adding various abstractions and features to it, without impacting existing functionality. While the queue can be best described as "fix and improve everything in the generic IRQ layer that we could think of", and thus it consists of many smaller features and lots of cleanups, the one feature that stands out most is the new 'irq chip' abstraction. The irq-chip abstraction is about describing and coding and IRQ controller driver by mapping its raw hardware capabilities [and quirks, if needed] in a straightforward way, without having to think about "IRQ flow" (level/edge/etc.) type of details. This stands in contrast with the current 'irq-type' model of genirq architectures, which 'mixes' raw hardware capabilities with 'flow' details. The patchset supports both types of irq controller designs at once, and converts i386 and x86_64 to the new irq-chip design. As a bonus side-effect of the irq-chip approach, chained interrupt controllers (master/slave PIC constructs, etc.) are now supported by design as well. The end result of this patchset intends to be simpler architecture-level code and more consolidation between architectures. We reused many bits of code and many concepts from Russell King's ARM IRQ layer, the merging of which was one of the motivations for this patchset. This patch: rename desc->handler to desc->chip. Originally i did not want to do this, because it's a big patch. But having both "desc->handler", "desc->handle_irq" and "action->handler" caused a large degree of confusion and made the code appear alot less clean than it truly is. I have also attempted a dual approach as well by introducing a desc->chip alias - but that just wasnt robust enough and broke frequently. So lets get over with this quickly. The conversion was done automatically via scripts and converts all the code in the kernel. This renaming patch is the first one amongst the patches, so that the remaining patches can stay flexible and can be merged and split up without having some big monolithic patch act as a merge barrier. [akpm@osdl.org: build fix] [akpm@osdl.org: another build fix] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [SPARC64]: Allow floppy driver to build modular.David S. Miller2006-06-251-61/+0
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill unused local vars in map_prom_timers().David S. Miller2006-06-231-1/+0
| | | | Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill off some more prom_getproperty() remnants.David S. Miller2006-06-231-5/+13
| | | | | | | The remaining ones occur before we have imported the device tree. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Move over to GENERIC_HARDIRQS.David S. Miller2006-06-201-673/+284
| | | | | | | | | | | | | | | | | | | | | | | | | | This is the long overdue conversion of sparc64 over to the generic IRQ layer. The kernel image is slightly larger, but the BSS is ~60K smaller due to the reduced size of struct ino_bucket. A lot of IRQ implementation details, including ino_bucket, were moved out of asm-sparc64/irq.h and are now private to arch/sparc64/kernel/irq.c, and most of the code in irq.c totally disappeared. One thing that's different at the moment is IRQ distribution, we do it at enable_irq() time. If the cpu mask is ALL then we round-robin using a global rotating cpu counter, else we pick the first cpu in the mask to support single cpu targetting. This is similar to what powerpc's XICS IRQ support code does. This works fine on my UP SB1000, and the SMP build goes fine and runs on that machine, but lots of testing on different setups is needed. Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Virtualize IRQ numbers.David S. Miller2006-06-201-84/+179
| | | | | | | | | | | | | | | | | | | | | | | | | Inspired by PowerPC XICS interrupt support code. All IRQs are virtualized in order to keep NR_IRQS from needing to be too large. Interrupts on sparc64 are arbitrary 11-bit values, but we don't need to define NR_IRQS to 2048 if we virtualize the IRQs. As PCI and SBUS controller drivers build device IRQs, we divy out virtual IRQ numbers incrementally starting at 1. Zero is a special virtual IRQ used for the timer interrupt. So device drivers all see virtual IRQs, and all the normal interfaces such as request_irq(), enable_irq(), etc. translate that into a real IRQ number in order to configure the IRQ. At this point knowledge of the struct ino_bucket is almost entirely contained within arch/sparc64/kernel/irq.c There are a few small bits in the PCI controller drivers that need to be swept away before we can remove ino_bucket's definition out of asm-sparc64/irq.h and privately into kernel/irq.c Signed-off-by: David S. Miller <davem@davemloft.net>
* [SPARC64]: Kill ino_bucket->pilDavid S. Miller2006-06-201-44/+26
| | | | | | | | | | | And reuse that struct member for virt_irq, which will be used in future changesets for the implementation of mapping between real and virtual IRQ numbers. This nicely kills off a ton of SBUS and PCI controller PIL assignment code which is no longer necessary. Signed-off-by: David S. Miller <davem@davemloft.net>
OpenPOWER on IntegriCloud