Possible to software trigger an interrupt?
Hi,
Having produced a proof of concept for using gpio chips to handle the triggers in IIO I am looking at converting over our sysfs trigger. This trigger is used to initialize capture on devices in a similar way to dataready interrupts. The key point is we want to handle this in the same way within drivers as the hardware event triggers.
It is a very useful tool. So the upshot is, what is the best way to handle causing an interrupt to occur from userspace?
Any pointers on how to do this would be most welcome.
Thanks,
Jonathan
Quoted 9 lines · Jonathan Cameron
Hi,
Having produced a proof of concept for using gpio chips to handle the triggers in IIO I am looking at converting over our sysfs trigger. This trigger is used to initialize capture on devices in a similar way to dataready interrupts. The key point is we want to handle this in the same way within drivers as the hardware event triggers.
Quoted 4 lines
It is a very useful tool. So the upshot is, what is the best way to handle causing an interrupt to occur from userspace?
Any pointers on how to do this would be most welcome.
For what it is worth, the incredibly dumb approach of just
calling handle_nested_irq seems to 'work'. I dread to think
what that might be quietly breaking though...
My understanding of some of this code is still rather limited I'm afraid!
Jonathan
Quoted 10 lines · Jonathan Cameron
Quoted 9 lines · Jonathan Cameron
Hi,
Having produced a proof of concept for using gpio chips to handle the triggers in IIO I am looking at converting over our sysfs trigger. This trigger is used to initialize capture on devices in a similar way to dataready interrupts. The key point is we want to handle this in the same way within drivers as the hardware event triggers.
Quoted 8 lines
Quoted 4 lines
It is a very useful tool. So the upshot is, what is the best way to handle causing an interrupt to occur from userspace?
Any pointers on how to do this would be most welcome.
For what it is worth, the incredibly dumb approach of just
callinghandle_nested_irqseems to 'work'. I dread to think
what that might be quietly breaking though...
I think you are fine in calling that. It's made to be called from a threaded context. But if you are testing code that will someday be called in an interrupt context, it may not catch everything you need.
For example, a mutex is allowed to be called from a threaded context, but not from a hard irq one. There may be other subtle locking issues as well. These could be caught with lockdep, but only when the code is really been executed from hard irq context.
-- Steve
Quoted 3 lines
My understanding of some of this code is still rather limited I'm afraid!
Quoted 16 lines · Steven Rostedt
Quoted 15 lines · Jonathan Cameron
Quoted 13 lines · Jonathan Cameron
Hi,
Having produced a proof of concept for using gpio chips to handle the triggers in IIO I am looking at converting over our sysfs trigger. This trigger is used to initialize capture on devices in a similar way to dataready interrupts. The key point is we want to handle this in the same way within drivers as the hardware event triggers.
It is a very useful tool. So the upshot is, what is the best way to handle causing an interrupt to occur from userspace?
Any pointers on how to do this would be most welcome.
Quoted 7 lines
Quoted 3 lines
For what it is worth, the incredibly dumb approach of just
callinghandle_nested_irqseems to 'work'. I dread to think
what that might be quietly breaking though...I think you are fine in calling that. It's made to be called from a threaded context. But if you are testing code that will someday be called in an interrupt context, it may not catch everything you need.
That's not the primary aim. Some of these triggers really are only called from userspace and there are devices that some users will only ever trigger that way. It's also step one in allowing a bridge to input for polled devices (via uinput).
Quoted 5 lines
For example, a mutex is allowed to be called from a threaded context, but not from a hard irq one. There may be other subtle locking issues as well. These could be caught with lockdep, but only when the code is really been executed from hard irq context.
Cool. We have plenty of real irq triggers as well. I'll just pester people to make sure they have tested with both if at all possible!
Thanks for the reassurance that isn't all that likely to blow up in my face ;)
Jonathan