Question about using new request_threaded_irq

Question about using new request_threaded_irq

[Marcos Lois Bermúdez]

Hi,

I'm downloaded kernel sources 3.2.27, and now I'm writing a device 
driver for a SPI device, i make some kernel drivers in the past, so now 
I'm surfing the source tree to see the new mode to make things.

My driver need handle hardware interrupts, in the past i use 
request_irq, but now there is a request_threaded_irq that makes more 
easy to have a top / bottom processing. But I'm confuse, after read the 
inner implementation of request_threaded_irq and see some drivers that 
use it. For my understand if i call for example:

request_threaded_irq(irqmum, NULL, irq_handle, IRQF_TRIGGER_FALLING, 
DEVICE_NAME, priv);

This seem to make a old Hard IRQ handler, and inside of this handler 
sleep APIs can't be used, but i see some SPI drivers that seem to 
register a IRQ of this form and make API calls that can sleep in the 
handler. Ex: drivers/input/touchscreen/ad7877.c it register the IRQ as:

err = request_threaded_irq(spi->irq, NULL, ad7877_irq,
                    IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
                    spi->dev.driver->name, ts);

And inside of ad7877_irq make a block call:

static irqreturn_t ad7877_irq(int irq, void *handle)
{
..
error = spi_sync(ts->spi, &ts->msg);
..
}

Is this ok?
With the new interface 'request_threaded_irq' all the IRQ are 
implemented on a thread?
Do i need to create a handler for thread and pass it to 
'request_threaded_irq', and if yes, why a lot of drivers, only pass 
quick_check_handler and make hard processing on it?

Excuse my poor English.

Regards.

Re: Question about using new request_threaded_irq

[Jonathan Corbet]

On Mon, 17 Dec 2012 16:11:22 +0100
Marcos Lois Bermúdez <marcos.discalis@gmail.com> wrote:

> For my understand if i call for example:
> 
> request_threaded_irq(irqmum, NULL, irq_handle, IRQF_TRIGGER_FALLING, 
> DEVICE_NAME, priv);
> 
> This seem to make a old Hard IRQ handler, and inside of this handler 
> sleep APIs can't be used, but i see some SPI drivers that seem to 
> register a IRQ of this form and make API calls that can sleep in the 
> handler.

Not quite.  The prototype for request_threaded_irq() is:

int request_threaded_irq(unsigned int irq, irq_handler_t handler,
			 irq_handler_t thread_fn, unsigned long irqflags,
			 const char *devname, void *dev_id)

Note the presents of *two* handlers, called "handler" and "thread_fn".
The first, "handler", is called in interrupt context; it's job is usually
to quiet the device and return; it cannot sleep.  If it's return value is
IRQ_WAKE_THREAD, the thread_fn() will be called in process context; it
*can* sleep.  In the example you cite, there is no immediate handler, only
the thread_fn(); the call to a blocking function from within the
thread_fn() is correct.

Hope that helps,

jon

Jonathan Corbet / LWN.net / corbet@lwn.net

Re: Question about using new request_threaded_irq

[Marcos Lois Bermúdez]

Hi,

I lot of thanks for you fast reply. It seem that i swap the mean of 
handler parameters, so i now see it correct. :).

Excuse for my newbie question.

handler is the primary handler, and if NULL a default primary handler is 
installed, and thread_fn is the thread handler.

I'm a bit confusing because i see a outdated page that talks about this 
new IRQ API, but now i see that it's very outdated:

http://lwn.net/Articles/302043/

Regards.


El 17/12/2012 16:37, Jonathan Corbet escribió:
> On Mon, 17 Dec 2012 16:11:22 +0100
> Marcos Lois Bermúdez <marcos.discalis@gmail.com> wrote:
>
>> For my understand if i call for example:
>>
>> request_threaded_irq(irqmum, NULL, irq_handle, IRQF_TRIGGER_FALLING,
>> DEVICE_NAME, priv);
>>
>> This seem to make a old Hard IRQ handler, and inside of this handler
>> sleep APIs can't be used, but i see some SPI drivers that seem to
>> register a IRQ of this form and make API calls that can sleep in the
>> handler.
>
> Not quite.  The prototype for request_threaded_irq() is:
>
> int request_threaded_irq(unsigned int irq, irq_handler_t handler,
> 			 irq_handler_t thread_fn, unsigned long irqflags,
> 			 const char *devname, void *dev_id)
>
> Note the presents of *two* handlers, called "handler" and "thread_fn".
> The first, "handler", is called in interrupt context; it's job is usually
> to quiet the device and return; it cannot sleep.  If it's return value is
> IRQ_WAKE_THREAD, the thread_fn() will be called in process context; it
> *can* sleep.  In the example you cite, there is no immediate handler, only
> the thread_fn(); the call to a blocking function from within the
> thread_fn() is correct.
>
> Hope that helps,
>
> jon
>
> Jonathan Corbet / LWN.net / corbet@lwn.net
>

Re: Question about using new request_threaded_irq

[Jonathan Corbet]

On Mon, 17 Dec 2012 17:06:43 +0100
Marcos Lois Bermúdez <marcos.discalis@gmail.com> wrote:

> I'm a bit confusing because i see a outdated page that talks about this 
> new IRQ API, but now i see that it's very outdated:
> 
> http://lwn.net/Articles/302043/

I normally encourage people to rely on LWN for everything, of course -
even the articles that Jake writes :)  But that *was* four years ago; a
lot of things change in the kernel in that much time. 

Out of curiosity, I looked back at the old thread and the article did,
indeed, accurately match the API proposed at that time. The order of those
arguments got switched at some later point.

The moral of the story: when in doubt, check the source.

jon