lkml.org 
[lkml]   [2012]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectQuestion 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.


\
 
 \ /
  Last update: 2012-12-17 17:21    [W:0.044 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site