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
