Re: [patch 09/12] xtensa: allow platform and variant to initializeown irq chips

From: Daniel GlÃckner
Date: Thu Apr 23 2009 - 12:17:12 EST


Hi,

On 04/23/2009 09:19 AM, Chris Zankel wrote:
>> -#ifdef CONFIG_VARIANT_IRQ_SWITCH
>> #include <variant/irq.h>
>> -#else
>> +#ifndef CONFIG_VARIANT_IRQ_SWITCH
>> static inline void variant_irq_enable(unsigned int irq) { }
>> static inline void variant_irq_disable(unsigned int irq) { }
>> #endif
>
> What was the reason for this change? We shouldn't require all processor
> variants to provide an irq.h header file, unless required (and we
> wouldn't need to add the following files)

Let me quote a few more lines of that hunk:

>>
>> +#ifndef VARIANT_NR_IRQS
>> +# define VARIANT_NR_IRQS 0
>> +#endif

Where can a variant define VARIANT_NR_IRQS if not inside a new header?
Do you prefer it being defined in core.h, tie.h, or tie-asm.h?

I think this boils down to the restructuring necessary in arch/xtensa that will
draw a line between the Xtensa core and a SoC featuring that core (as it was
described by Marc on March 31 on the linux-xtensa list). Of course a "core" will
never need any IRQs beyond XTENSA_NR_IRQS.

Another possibility would be to select VARIANT_IRQ_SWITCH (or a dedicated new
Kconfig option) in all SoCs that need additional IRQs.

Daniel

--
Dipl.-Math. Daniel GlÃckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 GÃttingen, Germany
GeschÃftsfÃhrung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055
Sitz der Gesellschaft: GÃttingen, Amtsgericht GÃttingen HR B 3160

emlix - your embedded linux partner
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/