On Tue, Sep 6, 2011 at 8:17 AM, sandeep kumar [off-list ref] wrote:

Hi peter,

quoted

quoted

we can immediately deduced that threaded IRQ handler is
sleepable/blocking-allowed, and therefore process context.

quoted

quoted

Correct?

Hmm..But when i tried to take a mutex lock in threaded_irq, it is throwing a
warning message
"BUG: sleeping function called from invalid context"... So i was wondering
which way it is..

Were you attempting to convert your normal IRQ handler to threaded IRQ
handler?   If yes then there is a special sequence of operation needed
to code (eg):

http://lwn.net/Articles/324980/

perhaps error arising from violation of these implementation?

Being "threaded" means that the IRQ handler is executing at the thread
context, or process context.

Thank you,
Sandeep
On Tue, Sep 6, 2011 at 1:22 AM, Peter Teoh [off-list ref] wrote:

quoted

On Thu, Sep 1, 2011 at 5:48 PM, sandeep kumar [off-list ref]
wrote:

quoted

HI all,

I want to know whether threaded_irq will be in interrupt context or
process context.
I heard they replace workqueues. But i dont know which context they will
be running in.

Any furthur references where i get more info..

Frankly I am not sure, but after reading Documentation/gpio.txt - where it
says:

Accessing such GPIOs requires a context which may sleep, ?for example
a threaded IRQ handler, and those accessors must be used instead of
spinlock-safe accessors without the cansleep() name suffix.

we can immediately deduced that threaded IRQ handler is
sleepable/blocking-allowed, and therefore process context.

Correct?

quoted

--
With regards,
Sandeep Kumar Anantapalli,


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

--
Regards,
Peter Teoh

--
With regards,
Sandeep Kumar Anantapalli,

-- 
Regards,
Peter Teoh