On Tue, Sep 6, 2011 at 8:17 AM, sandeep kumar <coolsandyforyou@gmail.com> wrote:
Hi peter,
we can immediately deduced that threaded IRQ handler is sleepable/blocking-allowed, and therefore process context.
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 <htmldeveloper@gmail.com> wrote:
On Thu, Sep 1, 2011 at 5:48 PM, sandeep kumar <coolsandyforyou@gmail.com> wrote:
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?
-- With regards, Sandeep Kumar Anantapalli,
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Peter Teoh
-- With regards, Sandeep Kumar Anantapalli,
-- Regards, Peter Teoh