On Tue, Nov 03, 2015 at 07:18:37PM -0800, Mathieu Rondonneau wrote: > On 15-11-02 07:15 AM, Philippe Gerum wrote: > > On 11/02/2015 06:23 AM, Mathieu Rondonneau wrote: > >> On 15-11-01 07:21 PM, 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. > >>> > >>> It strangely looks like ipipe_request_irq's idea is similar to what > >>> request_threaded_irq is already doing (delaying IRQ process later). > >>> > >>> -Mathieu > >> Looks like my bigger problem is that the handler_level_irq is not > >> called. Only the timer handler is called (handler_percpu_devid_irq). > > > > Which may mean that the regular IRQ top half for that interrupt source > > is not connected to the pipeline. You may want to check whether the > > irqchip handling that device's IRQs has been made aware of the interrupt > > pipeline. > > > > Thanks for replying Philippe, > This is the think, I did change the arch_irq_default_handler to call the > __ipipe_grab_irq and __ipipe_grab_ipi. > Is that what you are referring to when you say "interrupt source is not > connected to the pipile", that's what __ipipe_grab_xxx does isn't it? > > Obviously I am still missing something. > If I use irq_set_chained_handler in the driver then the handler gets > called but it's just replacing the handler_irq by the driver one. > When I use request_irq then it does not call my handler (the > action.handler one). > I will keep looking.
This is explained here: http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/#GPIOs_as_interrupt_sources and here: http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/#CONFIG_MULTI_IRQ_HANDLER Chained handlers have to call ipipe_handle_demuxed_irq instead of generic_handle_irq. And the arch irq handler has to call ipipe_handle_multi_irq or ipipe_handle_multi_ipi instead of handle_IRQ -- Gilles. https://click-hack.org _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
