* Question about using new request_threaded_irq
@ 2012-12-17 15:11 Marcos Lois Bermúdez
2012-12-17 15:37 ` Jonathan Corbet
0 siblings, 1 reply; 4+ messages in thread
From: Marcos Lois Bermúdez @ 2012-12-17 15:11 UTC (permalink / raw)
To: linux-kernel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about using new request_threaded_irq
2012-12-17 15:11 Question about using new request_threaded_irq Marcos Lois Bermúdez
@ 2012-12-17 15:37 ` Jonathan Corbet
2012-12-17 16:06 ` Marcos Lois Bermúdez
0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Corbet @ 2012-12-17 15:37 UTC (permalink / raw)
To: Marcos Lois Bermúdez; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about using new request_threaded_irq
2012-12-17 15:37 ` Jonathan Corbet
@ 2012-12-17 16:06 ` Marcos Lois Bermúdez
2012-12-17 17:14 ` Jonathan Corbet
0 siblings, 1 reply; 4+ messages in thread
From: Marcos Lois Bermúdez @ 2012-12-17 16:06 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-kernel
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
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Question about using new request_threaded_irq
2012-12-17 16:06 ` Marcos Lois Bermúdez
@ 2012-12-17 17:14 ` Jonathan Corbet
0 siblings, 0 replies; 4+ messages in thread
From: Jonathan Corbet @ 2012-12-17 17:14 UTC (permalink / raw)
To: Marcos Lois Bermúdez; +Cc: linux-kernel, Jake Edge
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-12-17 17:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-17 15:11 Question about using new request_threaded_irq Marcos Lois Bermúdez
2012-12-17 15:37 ` Jonathan Corbet
2012-12-17 16:06 ` Marcos Lois Bermúdez
2012-12-17 17:14 ` Jonathan Corbet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).