* [RFC] irq handling code consolidation, second try (ppc part)
@ 2003-01-04 11:59 Andrey Panin
2003-01-04 13:01 ` Benjamin Herrenschmidt
2003-01-05 0:50 ` Anton Blanchard
0 siblings, 2 replies; 8+ messages in thread
From: Andrey Panin @ 2003-01-04 11:59 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Hi all,
attached patch is a second try of IRQ handling code consolidation.
This is a ppc specific patch (compiled successfuly).
Beware, this patch removes some old(?) and crappy code:
- irq_kmalloc(), irq_kfree() removed. If ppc need to register
irqs early, it should use setup_irq() as all decent people do :))
- request_irq() with NULL handler argument == free_irq(), does
anyone use this kludge ?
Best regards.
--
Andrey Panin | Embedded systems software developer
pazke@orbita1.ru | PGP key: wwwkeys.pgp.net
[-- Attachment #2: patch-irq-ppc-2.5.53 --]
[-- Type: text/plain, Size: 11954 bytes --]
diff --minimal -urN -X /usr/share/dontdiff linux-2.5.53.vanilla/arch/ppc/Kconfig linux-2.5.53/arch/ppc/Kconfig
--- linux-2.5.53.vanilla/arch/ppc/Kconfig Fri Dec 27 19:44:57 2002
+++ linux-2.5.53/arch/ppc/Kconfig Fri Jan 3 14:28:03 2003
@@ -10,6 +10,10 @@
bool
default y
+config GENERIC_IRQ
+ bool
+ default y
+
config UID16
bool
diff --minimal -urN -X /usr/share/dontdiff linux-2.5.53.vanilla/arch/ppc/kernel/irq.c linux-2.5.53/arch/ppc/kernel/irq.c
--- linux-2.5.53.vanilla/arch/ppc/kernel/irq.c Fri Dec 27 19:44:57 2002
+++ linux-2.5.53/arch/ppc/kernel/irq.c Fri Jan 3 21:17:10 2003
@@ -10,12 +10,6 @@
* Adapted for Power Macintosh by Paul Mackerras
* Copyright (C) 1996 Paul Mackerras (paulus@cs.anu.edu.au)
* Amiga/APUS changes by Jesper Skov (jskov@cygnus.co.uk).
- *
- * This file contains the code used by various IRQ handling routines:
- * asking for different IRQ's should be done through these routines
- * instead of just grabbing them. Thus setups with different IRQ numbers
- * shouldn't result in any weird surprises, and installing new handlers
- * should be easier.
*
* The MPC8xx has an interrupt mask in the SIU. If a bit is set, the
* interrupt is _enabled_. As expected, IRQ0 is bit 0 in the 32-bit
@@ -59,289 +53,21 @@
extern atomic_t ipi_recv;
extern atomic_t ipi_sent;
-void enable_irq(unsigned int irq_nr);
-void disable_irq(unsigned int irq_nr);
static void register_irq_proc (unsigned int irq);
#define MAXCOUNT 10000000
-irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned =
- { [0 ... NR_IRQS-1] = { 0, NULL, NULL, 0, SPIN_LOCK_UNLOCKED}};
-
int ppc_spurious_interrupts = 0;
-struct irqaction *ppc_irq_action[NR_IRQS];
unsigned long ppc_cached_irq_mask[NR_MASK_WORDS];
unsigned long ppc_lost_interrupts[NR_MASK_WORDS];
atomic_t ppc_n_lost_interrupts;
-/* nasty hack for shared irq's since we need to do kmalloc calls but
- * can't very early in the boot when we need to do a request irq.
- * this needs to be removed.
- * -- Cort
- */
-#define IRQ_KMALLOC_ENTRIES 8
-static int cache_bitmask = 0;
-static struct irqaction malloc_cache[IRQ_KMALLOC_ENTRIES];
-extern int mem_init_done;
-
#if defined(CONFIG_TAU_INT)
extern int tau_interrupts(unsigned long cpu);
extern int tau_initialized;
#endif
-void *irq_kmalloc(size_t size, int pri)
-{
- unsigned int i;
- if ( mem_init_done )
- return kmalloc(size,pri);
- for ( i = 0; i < IRQ_KMALLOC_ENTRIES ; i++ )
- if ( ! ( cache_bitmask & (1<<i) ) )
- {
- cache_bitmask |= (1<<i);
- return (void *)(&malloc_cache[i]);
- }
- return 0;
-}
-
-void irq_kfree(void *ptr)
-{
- unsigned int i;
- for ( i = 0 ; i < IRQ_KMALLOC_ENTRIES ; i++ )
- if ( ptr == &malloc_cache[i] )
- {
- cache_bitmask &= ~(1<<i);
- return;
- }
- kfree(ptr);
-}
-
-int
-setup_irq(unsigned int irq, struct irqaction * new)
-{
- int shared = 0;
- unsigned long flags;
- struct irqaction *old, **p;
- irq_desc_t *desc = irq_desc + irq;
-
- /*
- * Some drivers like serial.c use request_irq() heavily,
- * so we have to be careful not to interfere with a
- * running system.
- */
- if (new->flags & SA_SAMPLE_RANDOM) {
- /*
- * This function might sleep, we want to call it first,
- * outside of the atomic block.
- * Yes, this might clear the entropy pool if the wrong
- * driver is attempted to be loaded, without actually
- * installing a new handler, but is this really a problem,
- * only the sysadmin is able to do this.
- */
- rand_initialize_irq(irq);
- }
-
- /*
- * The following block of code has to be executed atomically
- */
- spin_lock_irqsave(&desc->lock,flags);
- p = &desc->action;
- if ((old = *p) != NULL) {
- /* Can't share interrupts unless both agree to */
- if (!(old->flags & new->flags & SA_SHIRQ)) {
- spin_unlock_irqrestore(&desc->lock,flags);
- return -EBUSY;
- }
-
- /* add new interrupt at end of irq queue */
- do {
- p = &old->next;
- old = *p;
- } while (old);
- shared = 1;
- }
-
- *p = new;
-
- if (!shared) {
- desc->depth = 0;
- desc->status &= ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING);
- unmask_irq(irq);
- }
- spin_unlock_irqrestore(&desc->lock,flags);
-
- register_irq_proc(irq);
- return 0;
-}
-
-void free_irq(unsigned int irq, void* dev_id)
-{
- irq_desc_t *desc;
- struct irqaction **p;
- unsigned long flags;
-
- desc = irq_desc + irq;
- spin_lock_irqsave(&desc->lock,flags);
- p = &desc->action;
- for (;;) {
- struct irqaction * action = *p;
- if (action) {
- struct irqaction **pp = p;
- p = &action->next;
- if (action->dev_id != dev_id)
- continue;
-
- /* Found it - now remove it from the list of entries */
- *pp = action->next;
- if (!desc->action) {
- desc->status |= IRQ_DISABLED;
- mask_irq(irq);
- }
- spin_unlock_irqrestore(&desc->lock,flags);
-
- synchronize_irq(irq);
- irq_kfree(action);
- return;
- }
- printk("Trying to free free IRQ%d\n",irq);
- spin_unlock_irqrestore(&desc->lock,flags);
- break;
- }
- return;
-}
-
-int request_irq(unsigned int irq, void (*handler)(int, void *, struct pt_regs *),
- unsigned long irqflags, const char * devname, void *dev_id)
-{
- struct irqaction *action;
- int retval;
-
- if (irq >= NR_IRQS)
- return -EINVAL;
- if (!handler)
- {
- /*
- * free_irq() used to be implemented as a call to
- * request_irq() with handler being NULL. Now we have
- * a real free_irq() but need to allow the old behavior
- * for old code that hasn't caught up yet.
- * -- Cort <cort@fsmlabs.com>
- */
- free_irq(irq, dev_id);
- return 0;
- }
-
- action = (struct irqaction *)
- irq_kmalloc(sizeof(struct irqaction), GFP_KERNEL);
- if (!action) {
- printk(KERN_ERR "irq_kmalloc() failed for irq %d !\n", irq);
- return -ENOMEM;
- }
-
- action->handler = handler;
- action->flags = irqflags;
- action->mask = 0;
- action->name = devname;
- action->dev_id = dev_id;
- action->next = NULL;
-
- retval = setup_irq(irq, action);
- if (retval)
- {
- kfree(action);
- return retval;
- }
-
- return 0;
-}
-
-/*
- * Generic enable/disable code: this just calls
- * down into the PIC-specific version for the actual
- * hardware disable after having gotten the irq
- * controller lock.
- */
-
-/**
- * disable_irq_nosync - disable an irq without waiting
- * @irq: Interrupt to disable
- *
- * Disable the selected interrupt line. Disables of an interrupt
- * stack. Unlike disable_irq(), this function does not ensure existing
- * instances of the IRQ handler have completed before returning.
- *
- * This function may be called from IRQ context.
- */
-
-void disable_irq_nosync(unsigned int irq)
-{
- irq_desc_t *desc = irq_desc + irq;
- unsigned long flags;
-
- spin_lock_irqsave(&desc->lock, flags);
- if (!desc->depth++) {
- if (!(desc->status & IRQ_PER_CPU))
- desc->status |= IRQ_DISABLED;
- mask_irq(irq);
- }
- spin_unlock_irqrestore(&desc->lock, flags);
-}
-
-/**
- * disable_irq - disable an irq and wait for completion
- * @irq: Interrupt to disable
- *
- * Disable the selected interrupt line. Disables of an interrupt
- * stack. That is for two disables you need two enables. This
- * function waits for any pending IRQ handlers for this interrupt
- * to complete before returning. If you use this function while
- * holding a resource the IRQ handler may need you will deadlock.
- *
- * This function may be called - with care - from IRQ context.
- */
-
-void disable_irq(unsigned int irq)
-{
- disable_irq_nosync(irq);
- synchronize_irq(irq);
-}
-
-/**
- * enable_irq - enable interrupt handling on an irq
- * @irq: Interrupt to enable
- *
- * Re-enables the processing of interrupts on this IRQ line
- * providing no disable_irq calls are now in effect.
- *
- * This function may be called from IRQ context.
- */
-
-void enable_irq(unsigned int irq)
-{
- irq_desc_t *desc = irq_desc + irq;
- unsigned long flags;
-
- spin_lock_irqsave(&desc->lock, flags);
- switch (desc->depth) {
- case 1: {
- unsigned int status = desc->status & ~IRQ_DISABLED;
- desc->status = status;
- if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) {
- desc->status = status | IRQ_REPLAY;
- hw_resend_irq(desc->handler,irq);
- }
- unmask_irq(irq);
- /* fall-through */
- }
- default:
- desc->depth--;
- break;
- case 0:
- printk("enable_irq(%u) unbalanced\n", irq);
- }
- spin_unlock_irqrestore(&desc->lock, flags);
-}
-
int show_interrupts(struct seq_file *p, void *v)
{
int i, j;
@@ -394,24 +120,6 @@
return 0;
}
-static inline void
-handle_irq_event(int irq, struct pt_regs *regs, struct irqaction *action)
-{
- int status = 0;
-
- if (!(action->flags & SA_INTERRUPT))
- local_irq_enable();
-
- do {
- status |= action->flags;
- action->handler(irq, action->dev_id, regs);
- action = action->next;
- } while (action);
- if (status & SA_SAMPLE_RANDOM)
- add_interrupt_randomness(irq);
- local_irq_disable();
-}
-
/*
* Eventually, this should take an array of interrupts and an array size
* so it can dispatch multiple interrupts.
@@ -480,7 +188,7 @@
*/
for (;;) {
spin_unlock(&desc->lock);
- handle_irq_event(irq, regs, action);
+ handle_IRQ_event(irq, regs, action);
spin_lock(&desc->lock);
if (likely(!(desc->status & IRQ_PENDING)))
@@ -554,14 +262,6 @@
ppc_md.init_IRQ();
}
-#ifdef CONFIG_SMP
-void synchronize_irq(unsigned int irq)
-{
- while (irq_desc[irq].status & IRQ_INPROGRESS)
- barrier();
-}
-#endif /* CONFIG_SMP */
-
static struct proc_dir_entry *root_irq_dir;
static struct proc_dir_entry *irq_dir[NR_IRQS];
static struct proc_dir_entry *smp_affinity_entry[NR_IRQS];
@@ -585,42 +285,8 @@
return sprintf (page, "%08x\n", irq_affinity[(int)data]);
}
-static unsigned int parse_hex_value (const char *buffer,
- unsigned long count, unsigned long *ret)
-{
- unsigned char hexnum [HEX_DIGITS];
- unsigned long value;
- int i;
-
- if (!count)
- return -EINVAL;
- if (count > HEX_DIGITS)
- count = HEX_DIGITS;
- if (copy_from_user(hexnum, buffer, count))
- return -EFAULT;
-
- /*
- * Parse the first 8 characters as a hex string, any non-hex char
- * is end-of-string. '00e1', 'e1', '00E1', 'E1' are all the same.
- */
- value = 0;
-
- for (i = 0; i < count; i++) {
- unsigned int c = hexnum[i];
-
- switch (c) {
- case '0' ... '9': c -= '0'; break;
- case 'a' ... 'f': c -= 'a'-10; break;
- case 'A' ... 'F': c -= 'A'-10; break;
- default:
- goto out;
- }
- value = (value << 4) | c;
- }
-out:
- *ret = value;
- return 0;
-}
+extern unsigned int parse_hex_value(const char *buffer, unsigned long count,
+ unsigned long *ret);
static int irq_affinity_write_proc (struct file *file, const char *buffer,
unsigned long count, void *data)
@@ -728,8 +394,4 @@
continue;
register_irq_proc(i);
}
-}
-
-void no_action(int irq, void *dev, struct pt_regs *regs)
-{
}
diff --minimal -urN -X /usr/share/dontdiff linux-2.5.53.vanilla/include/asm-ppc/hw_irq.h linux-2.5.53/include/asm-ppc/hw_irq.h
--- linux-2.5.53.vanilla/include/asm-ppc/hw_irq.h Fri Dec 27 19:47:10 2002
+++ linux-2.5.53/include/asm-ppc/hw_irq.h Sat Jan 4 00:24:07 2003
@@ -5,6 +5,8 @@
#ifndef _PPC_HW_IRQ_H
#define _PPC_HW_IRQ_H
+//#include <linux/irq.h>
+
extern void timer_interrupt(struct pt_regs *);
extern void ppc_irq_dispatch_handler(struct pt_regs *regs, int irq);
@@ -71,6 +73,23 @@
struct hw_interrupt_type;
static inline void hw_resend_irq(struct hw_interrupt_type *h, unsigned int i) {}
+//extern irq_desc_t irq_desc[NR_IRQS];
+
+#define arch_ack_bad_irq(irq) do { } while (0)
+
+/* Return a pointer to the irq descriptor for IRQ. */
+#define irq_desc(irq) (irq_desc + (irq))
+
+/* Check irq number */
+#define arch_check_irq(irq) ((irq) >= NR_IRQS)
+
+/* Arch specific hook for setup_irq() */
+#define arch_setup_irq(irq, desc, irqaction) do { } while (0)
+
+/* Used in setup_irq() */
+#define ARCH_NONSHARED_IRQ_MASK ~(IRQ_DISABLED | IRQ_AUTODETECT | IRQ_WAITING)
+
+#define HAVE_ARCH_IRQ_PROBE
#endif /* _PPC_HW_IRQ_H */
#endif /* __KERNEL__ */
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] irq handling code consolidation, second try (ppc part)
2003-01-04 11:59 [RFC] irq handling code consolidation, second try (ppc part) Andrey Panin
@ 2003-01-04 13:01 ` Benjamin Herrenschmidt
2003-01-04 17:41 ` Linus Torvalds
2003-01-05 0:25 ` Anton Blanchard
2003-01-05 0:50 ` Anton Blanchard
1 sibling, 2 replies; 8+ messages in thread
From: Benjamin Herrenschmidt @ 2003-01-04 13:01 UTC (permalink / raw)
To: Andrey Panin; +Cc: linux-kernel, Linus Torvalds
On Sat, 2003-01-04 at 12:59, Andrey Panin wrote:
> Hi all,
>
> attached patch is a second try of IRQ handling code consolidation.
> This is a ppc specific patch (compiled successfuly).
>
> Beware, this patch removes some old(?) and crappy code:
> - irq_kmalloc(), irq_kfree() removed. If ppc need to register
> irqs early, it should use setup_irq() as all decent people do :))
> - request_irq() with NULL handler argument == free_irq(), does
> anyone use this kludge ?
>
After a quick look, things look fine some of this old PPC crap should indeed
be killed now.
There's something else I would like to implement one of these days, and your
consolidation work makes it easier (except for archs that won't use it...).
Basically, I want some (few and rare enough though) drivers to be able
to define interrupt controllers and thus create their own IRQs.
The typical example for which I need that is cardbus. I need the cardbus
controller on PCI to be seen as a real cascaded controller, that is I want
devices below it (either PCI or PCMCIA) calls to request/free/enable/disable_irq
for their to be caught by the cardbus driver.
This is the only sane way to properly enable/disable bridging of the
interrupt upon request from the driver. Without that, I still can frequent
lockups with various pcmcia cards when inserted/removed due to IRQ line
beeing stuck down on slot shutdown or other crappy things happening
typically with legacy PCMCIA stuffs (ATA is a good example of crappy behaviour).
The "easy" way here to implement that is to make the irq_desc array larger than
NR_IRQs (or rather split NR_IRQs into NR_SYS_IRQS + NR_DYNAMIC_IRQS). The
additional "slots" could then easily be allocated/freed. Thus, keeping my
cardbus example, the cardbus driver can allocate a couple of slots (that is IRQ
numbers) dynamically, and use it's own startup/shutdown/enable/disable/...
hooks for them, dealing itself with the cascade from the PCI irq. (Of course,
this is not for systems using cardbus routed to legacy IRQs, but for systems
like PPC where the PCI irq is mux'ing both the device IRQs and the controller
own IRQ).
Ben.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] irq handling code consolidation, second try (ppc part)
2003-01-04 13:01 ` Benjamin Herrenschmidt
@ 2003-01-04 17:41 ` Linus Torvalds
2003-01-05 8:56 ` Benjamin Herrenschmidt
2003-01-05 0:25 ` Anton Blanchard
1 sibling, 1 reply; 8+ messages in thread
From: Linus Torvalds @ 2003-01-04 17:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrey Panin, linux-kernel
On 4 Jan 2003, Benjamin Herrenschmidt wrote:
>
> The "easy" way here to implement that is to make the irq_desc array larger than
> NR_IRQs (or rather split NR_IRQs into NR_SYS_IRQS + NR_DYNAMIC_IRQS). The
> additional "slots" could then easily be allocated/freed. Thus, keeping my
> cardbus example, the cardbus driver can allocate a couple of slots (that is IRQ
> numbers) dynamically, and use it's own startup/shutdown/enable/disable/...
> hooks for them, dealing itself with the cascade from the PCI irq.
Linearizing a space like this is always a bad idea, I think.
It would be entirely possible to just add the irq routing information to
the "struct device" tree, and have a "dev_request_irq(dev, ...)", along
with a few helper functions like "pci_request_irq(pci_dev, ...)".
And the old "request_irq()" would just use the system root device as the
device.
Linus
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] irq handling code consolidation, second try (ppc part)
2003-01-04 13:01 ` Benjamin Herrenschmidt
2003-01-04 17:41 ` Linus Torvalds
@ 2003-01-05 0:25 ` Anton Blanchard
1 sibling, 0 replies; 8+ messages in thread
From: Anton Blanchard @ 2003-01-05 0:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrey Panin, linux-kernel, Linus Torvalds
> The "easy" way here to implement that is to make the irq_desc array
> larger than NR_IRQs (or rather split NR_IRQs into NR_SYS_IRQS +
> NR_DYNAMIC_IRQS). The additional "slots" could then easily be
> allocated/freed.
On ppc64 irqs are sparse and can be very large (> 1000) so we have a
mapping between them and slots in irq_desc[NR_IRQS]. I wonder how
hard it would be to kill irq_desc and just dynamically allocate
irq_desc stuff. That would solve my problem.
Anton
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] irq handling code consolidation, second try (ppc part)
2003-01-04 11:59 [RFC] irq handling code consolidation, second try (ppc part) Andrey Panin
2003-01-04 13:01 ` Benjamin Herrenschmidt
@ 2003-01-05 0:50 ` Anton Blanchard
1 sibling, 0 replies; 8+ messages in thread
From: Anton Blanchard @ 2003-01-05 0:50 UTC (permalink / raw)
To: linux-kernel
> attached patch is a second try of IRQ handling code consolidation.
> This is a ppc specific patch (compiled successfuly).
>
> Beware, this patch removes some old(?) and crappy code:
> - irq_kmalloc(), irq_kfree() removed. If ppc need to register
> irqs early, it should use setup_irq() as all decent people do :))
> - request_irq() with NULL handler argument == free_irq(), does
> anyone use this kludge ?
Similar issues on ppc64 (since it started life as a copy of the ppc32 code :)
Im interested in moving to something generic.
Anton
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] irq handling code consolidation, second try (ppc part)
2003-01-04 17:41 ` Linus Torvalds
@ 2003-01-05 8:56 ` Benjamin Herrenschmidt
2003-01-05 19:05 ` Linus Torvalds
0 siblings, 1 reply; 8+ messages in thread
From: Benjamin Herrenschmidt @ 2003-01-05 8:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, pazke, anton
On Sat, 2003-01-04 at 18:41, Linus Torvalds wrote:
> On 4 Jan 2003, Benjamin Herrenschmidt wrote:
> >
> > The "easy" way here to implement that is to make the irq_desc array larger than
> > NR_IRQs (or rather split NR_IRQs into NR_SYS_IRQS + NR_DYNAMIC_IRQS). The
> > additional "slots" could then easily be allocated/freed. Thus, keeping my
> > cardbus example, the cardbus driver can allocate a couple of slots (that is IRQ
> > numbers) dynamically, and use it's own startup/shutdown/enable/disable/...
> > hooks for them, dealing itself with the cascade from the PCI irq.
>
> Linearizing a space like this is always a bad idea, I think.
I fully agree, I was just proposing a "simple" solution that would fit
in a feature-frozen kernel ;)
Note that if we go the full way abstracting interrupts, then the
interrupt "tree" should be separate from the device tree. The interrupt
"parent" of a device may not be (and is not in a whole lot of cases I
have to deal with on pmacs and embedded) the "bus" parent of a given
device.
I suppose there may be similar "issues" with x86 PCI chips routed to
legacy irqs, but then, I'm completely unfamiliar with the story of
interrupt routing on x86's...
on pmacs, all interrupts end up in a single interrupt controller located
in a "combo" ASIC along with other devices. This ASIC is a PCI device,
but is really the root of the interrupt tree just below the CPU itself,
regardless of the actual interrupt sources beeing located on other PCI
busses or not. On embedded, the design can be as funky as a HW designer
can imagine...
Do you think this is still 2.5 work ?
> It would be entirely possible to just add the irq routing information to
> the "struct device" tree, and have a "dev_request_irq(dev, ...)", along
> with a few helper functions like "pci_request_irq(pci_dev, ...)".
>
> And the old "request_irq()" would just use the system root device as the
> device.
>
> Linus
>
> -
> 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/
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] irq handling code consolidation, second try (ppc part)
2003-01-05 8:56 ` Benjamin Herrenschmidt
@ 2003-01-05 19:05 ` Linus Torvalds
2003-01-05 22:03 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 8+ messages in thread
From: Linus Torvalds @ 2003-01-05 19:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-kernel, pazke, anton
On 5 Jan 2003, Benjamin Herrenschmidt wrote:
>
> Note that if we go the full way abstracting interrupts, then the
> interrupt "tree" should be separate from the device tree. The interrupt
> "parent" of a device may not be (and is not in a whole lot of cases I
> have to deal with on pmacs and embedded) the "bus" parent of a given
> device.
I disagree. The pmac braindamage is a pmac problem, and not worth
uglifying the generic device layer over. Besides, as far as I know, it is
trivially solved by just making the pmac irq controller be a root
controller, and that's it. There are no other irq controllers there that
are worth worrying about.
> Do you think this is still 2.5 work ?
No.
Linus
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] irq handling code consolidation, second try (ppc part)
2003-01-05 19:05 ` Linus Torvalds
@ 2003-01-05 22:03 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 8+ messages in thread
From: Benjamin Herrenschmidt @ 2003-01-05 22:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, pazke, anton
On Sun, 2003-01-05 at 20:05, Linus Torvalds wrote:
> On 5 Jan 2003, Benjamin Herrenschmidt wrote:
> >
> > Note that if we go the full way abstracting interrupts, then the
> > interrupt "tree" should be separate from the device tree. The interrupt
> > "parent" of a device may not be (and is not in a whole lot of cases I
> > have to deal with on pmacs and embedded) the "bus" parent of a given
> > device.
>
> I disagree. The pmac braindamage is a pmac problem, and not worth
> uglifying the generic device layer over. Besides, as far as I know, it is
> trivially solved by just making the pmac irq controller be a root
> controller, and that's it. There are no other irq controllers there that
> are worth worrying about.
Right, though some other machines (CHRP for example) with cascaded
legacy 8259 on top or below OpenPIC may also want more flexibility
regarding interrupt routing.
It seems quite common (at least it is in embedded world) to actually
wire interrupt sources rather randomly to the closest device than can
act as an interrupt controller regardless of the actual bus layout ;)
But I agree this can be solved by defining the "main" PIC as root
controller regardless of it's actual bus location.
> > Do you think this is still 2.5 work ?
>
> No.
Makes sense. Though the simple tweak of allocating more irq_descs in the
existing array (by slightly extending the array) may be worth trying for
fixing some of the pcmcia problems now. I need to experient more, it
might actually be enough to just disable IRQ routing on the pcmcia
bridge when the slot is shut down.
Ben.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-01-05 21:51 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-04 11:59 [RFC] irq handling code consolidation, second try (ppc part) Andrey Panin
2003-01-04 13:01 ` Benjamin Herrenschmidt
2003-01-04 17:41 ` Linus Torvalds
2003-01-05 8:56 ` Benjamin Herrenschmidt
2003-01-05 19:05 ` Linus Torvalds
2003-01-05 22:03 ` Benjamin Herrenschmidt
2003-01-05 0:25 ` Anton Blanchard
2003-01-05 0:50 ` Anton Blanchard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox