LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Possible to software trigger an interrupt?
@ 2011-04-03 16:04 Jonathan Cameron
  2011-04-03 16:34 ` Jonathan Cameron
  0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Cameron @ 2011-04-03 16:04 UTC (permalink / raw)
  To: LKML, Thomas Gleixner

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Possible to software trigger an interrupt?
  2011-04-03 16:04 Possible to software trigger an interrupt? Jonathan Cameron
@ 2011-04-03 16:34 ` Jonathan Cameron
  2011-04-07 13:20   ` Steven Rostedt
  0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Cameron @ 2011-04-03 16:34 UTC (permalink / raw)
  To: LKML, Thomas Gleixner

On 04/03/11 17:04, Jonathan Cameron wrote:
> 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.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Possible to software trigger an interrupt?
  2011-04-03 16:34 ` Jonathan Cameron
@ 2011-04-07 13:20   ` Steven Rostedt
  2011-04-07 13:30     ` Jonathan Cameron
  0 siblings, 1 reply; 4+ messages in thread
From: Steven Rostedt @ 2011-04-07 13:20 UTC (permalink / raw)
  To: Jonathan Cameron; +Cc: LKML, Thomas Gleixner

On Sun, Apr 03, 2011 at 05:34:13PM +0100, Jonathan Cameron wrote:
> On 04/03/11 17:04, Jonathan Cameron wrote:
> > 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.
> 
> 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...

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


> 
> My understanding of some of this code is still rather limited
> I'm afraid!

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Possible to software trigger an interrupt?
  2011-04-07 13:20   ` Steven Rostedt
@ 2011-04-07 13:30     ` Jonathan Cameron
  0 siblings, 0 replies; 4+ messages in thread
From: Jonathan Cameron @ 2011-04-07 13:30 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: LKML, Thomas Gleixner

On 04/07/11 14:20, Steven Rostedt wrote:
> On Sun, Apr 03, 2011 at 05:34:13PM +0100, Jonathan Cameron wrote:
>> On 04/03/11 17:04, Jonathan Cameron wrote:
>>> 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.
>>
>> 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...
> 
> 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).
> 
> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-04-07 13:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-04-03 16:04 Possible to software trigger an interrupt? Jonathan Cameron
2011-04-03 16:34 ` Jonathan Cameron
2011-04-07 13:20   ` Steven Rostedt
2011-04-07 13:30     ` Jonathan Cameron

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).