On 11/02/2015 04:21 AM, Mathieu Rondonneau wrote: > On 15-11-01 06:58 PM, Mathieu Rondonneau wrote: >> On 15-10-31 08:58 PM, Mathieu Rondonneau wrote: >>> Hi, >>> >>> irq handlers registered with devm_request_threaded_irq does not get >>> triggered when interrupt fires. >>> >>> The mmc driver uses this (can not load the rootfs). >>> Only the IPIPE patch is enabled. >>> the armctrl chipirq is triggering the .ack handler instead so the >>> interrupt is happening. >>> >>> Any suggestion on where I should look? how is this supported by the >>> ipipe layer? >>> >>> Thanks, >>> -Mathieu >> >> I think I might have answered my own question. >> Looks like I need to use ipipe_request_irq() instead. >> >> Regards, >> -Mathieu > mmmm it is not true, it seems we still need a > ipipe_request_threaded_irq() to call the ackfn, put the handler in the > queue and wake up the thread once handler is executed. Or user will have > to move this functionality into their driver's IRQ handler.
The interrupt pipeline does not have to care about the thread level, it delays the top halves, which in consequence also delays the (threaded) bottom halves without any code change. > > It strangely looks like ipipe_request_irq's idea is similar to what > request_threaded_irq is already doing (delaying IRQ process later). > Except that it virtualizes interrupt masking. Disabling IRQs for the regular kernel won't prevent real-time IRQs hooked by ipipe_request_irq() from being handled. That is a significant difference. Besides, the pipeline does not implement a threaded IRQ model for such virtualization. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
