Re: Question about using new request_threaded_irq
On Mon, 17 Dec 2012 17:06:43 +0100 Marcos Lois Bermúdez 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about using new request_threaded_irq
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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about using new request_threaded_irq
On Mon, 17 Dec 2012 16:11:22 +0100 Marcos Lois Bermúdez 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about using new request_threaded_irq
On Mon, 17 Dec 2012 17:06:43 +0100 Marcos Lois Bermúdez marcos.disca...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about using new request_threaded_irq
On Mon, 17 Dec 2012 16:11:22 +0100 Marcos Lois Bermúdez marcos.disca...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about using new request_threaded_irq
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.disca...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
