microbit@xxxxxxxxxxxxxxxxxxxxxx wrote:
On Wed, 29 Jul 2009 04:24:05 +1000, <microbit@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
On Tue, 28 Jul 2009 22:24:42 +0530, H M Thalib <hmthalib@xxxxxxxxx>
wrote:
Hi,
Is it possible to trigger any interrupt in Linux without actually it is
happening. I want to test whether my modules interrupt handler is
working properly - without the hardware interrupt occurring.
Hi,
The only way to have an interrupt vectored when the HW is masked off -
Linux or without - is to somehow
force vectoring. This would either be by a poll on the interrupt flag and
then branching, or by directly branching
to the handler.
But perhaps you first need to clarify what exactly you are trying to
achieve. I presume you mean you want to *execute*
interrupt handler code for testing without actually triggering the HW
interrupt ?
If so, then it will heavily depend on the architecture of CPU you're on.
By the same token, an interrupt handler in principle is just a function
call but before doing so the PC is pushed (and perhaps some CPU status
register). So you're free to call your ISR/handler manually to test your
code, as long as you adhere to the calling convention of the arch.
For example, on ARM it can be as simple as just calling the handler from
where ever you want.
Unless you use pure HW vectoring in the VIC/AIC, the handler will
typically
be called from the actual interrupt exception anyway.
If pure HW vectoring, it could be as simple as using the handler as
__naked__ attribute for the actual HW call, while you omit the __naked__
attribute when you want to 'manually' call the handler for testing.
All __naked__ does is ignore the stackframe for pushing and popping the
used registers in the ISR.
HTH ?
B rgds
Kris
Oops, I should have worded this better :
By the same token, an interrupt handler in principle is just a function
call but before doing so the PC is pushed (and perhaps some CPU status
register). So you're free to call your ISR/handler manually to test your
code, as long as you adhere to the calling convention of the arch.
Before doing the call most CPUs explicitly *disable* global interrupts and
save the CPU status.
Nesting of IRQs requires explicit re-enable of IRQs inside the ISR handler.
IOW, on many CPUs (in principle) an IRET is the same as popping the stack
and executing a RET
(as if it were a "normal" function call).
Is this what you wanted ?
B rgds
Kris
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
Hi,
Thanks, The above information was very useful, What I need to know is
whether my interrupt handler is registered properly to particular IRQ
Number properly. so that when the hardware interrupt comes it will be called
--
Thanks & Regards,
H M Thalib.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
