[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Clarification on enable_interrupts
On Thu Mar 29, 2012 at 10:31:53AM +0530, Linu Cherian wrote:
> 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
> 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.
Main Index |
Thread Index |