Re: Clarification on enable_interrupts

[Linu Cherian <linucherian%gmail.com@localhost>]

On Thu Mar 29, 2012 at 10:31:53AM +0530, Linu Cherian wrote:
> Hi,
> While trying to understand the arm interrupt controller driver code, 
> got into some confusions.
> 
> Older interrupt controller drivers which didnt use the pic
> interface(arch/arm/pic), calls "enable_interrupts" in their attach functions.
> eg. arm/arm/omap/omap_intr.c. 
> 
> This looks very straightforward since interrupts are expected to be enabled,
> when the autoconf gets completed and also after the interrupt
> controller is initialized.
> 
> But at the same time, the newer interrupt controller drivers which
> uses the pic interface doesnt call enable_interrupts in their attach
> function.
> 
> Couldnt really figure out how and where the processor interrupt is
> getting enabled(by clearing the I bit in CPSR). 
> 

Made some more effort to clear the confusion, but still in same state.

Sharing a more specific example,  which i had taken from NetBSD current.

Compared two ARM Cotex-A8 boards Beagle and NetWalker.

In case of Beagle, 
the interrupt controller driver omap2_icu.c, doesnt call
enable_interrupts  in the attach function, omap2icu_attach

In case of Netwalker,
the interrupt controller driver imx51_tzic.c, calls 
enable_interrupts in the attach function, tzic_attach


I am not trying to prove that the above scneario is wrong, but i just
need some help in understanding just one thing

1. Where does the processor interrupt get enabled in case of beagle
   board ? ie. clearing I bit in CPSR. 
   Somehow i couldnt figure this out.
   
   IIUC, the processor after power on reset has interrupts disabled.


Even if the questions are baseless, atleast I would like to get some
directions for further reading or make corrections.

Thanks.


-- 
Linu cherian