Question about using new request_threaded_irq

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.

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 / [email protected]

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.

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