On Friday 10 October 2008, Pandita, Vikram wrote:
> --- a/arch/arm/mach-omap2/irq.c
> +++ b/arch/arm/mach-omap2/irq.c
> @@ -159,7 +159,7 @@ void __init omap_init_irq(void)
> printk(KERN_INFO "Total of %ld interrupts on %d active controller%s\n",
> nr_irqs, nr_banks, nr_banks > 1 ? "s" : "");
>
> - for (i = 0; i < nr_irqs; i++) {
> + for (i = 0; i < NR_IRQS; /*nr_irqs;*/ i++) {
> set_irq_chip(i, &omap_irq_chip);
> set_irq_handler(i, handle_level_irq);
> set_irq_flags(i, IRQF_VALID);
>
This could explain a problem appearing on every OMAP3 board.
But not one appearing only on Overo ... especially when the
same binary works on Beagle.
However, that's also very incorrect. Most of those NR_IRQS
interrupts are managed by some chip other than the toplevel
OMAP IRQ controller(s)...
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
