Regarding threaded irq and normal irq

[Peter Teoh]

On Tue, Sep 6, 2011 at 8:17 AM, sandeep kumar <coolsandyforyou at 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 at gmail.com> wrote:
>>
>> On Thu, Sep 1, 2011 at 5:48 PM, sandeep kumar <coolsandyforyou at 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 at kernelnewbies.org
>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> >
>>
>>
>>
>> --
>> Regards,
>> Peter Teoh
>
>
>
> --
> With regards,
> Sandeep Kumar Anantapalli,
>
>



-- 
Regards,
Peter Teoh