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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jonathan Corbet]

On Mon, 17 Dec 2012 16:11:22 +0100
Marcos Lois Bermúdez <marcos....@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 / cor...@lwn.net

[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.

[Jonathan Corbet]

On Mon, 17 Dec 2012 17:06:43 +0100
Marcos Lois Bermúdez <marcos....@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