On Sat, Nov 07, 2015 at 09:55:48PM -0800, Mathieu Rondonneau wrote: > On 15-11-04 10:08 PM, Mathieu Rondonneau wrote: > > On 15-11-04 04:51 PM, Mathieu Rondonneau wrote: > >> On 15-11-03 11:04 PM, Gilles Chanteperdrix wrote: > >>> 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 > >>> > >> > >> Thanks Gilles for the pointers, > >> MULTI_IRQ_HANDLER is not enabled for RPI2 (so I did not look at the > >> multi_irq_handler section), is it a requirement for the ipipe patch to > >> work? > >> > >> For GPIO I got it to work, but it is easier to me because they have > >> their own irqchip. > >> It is the arch irq handler that cause me trouble. > >> > >> Maybe I just have to enable MULTI_IRQ_HANDLER. > >> I will play around with it. > >> > >> Thanks again for your feedback, it helps, > >> Regards, > >> -Mathieu > >> > >> > > Also confirming that the ipipe_handler_multi_irq and > > ipipe_handler_multi_ipi are called properly. > > so it looks like the arch irq handler is working as expected. > > > > it is the handle_level_irq that is not called properly when I use the > > request_irq in the driver. > > the desc->irq_data.chip->irq_ack is called properly but not the > > irqaction->handler (that is the handler of my driver) that should have > > been triggered by handle_level_irq. > > > > So I think my problem is that handle_level_irq() is not called. > > if I register my driver handler with irq_set_chained_handler then > > ipipe_handler_multi_irq is still called, but the > > desc->irq_data.chip->irq_ack does not get called and my driver handle > > gets called properly. > > In this case, the ipipe is bypassed it seems since if I understand > > correctly, the irq_ack is still expected to trigger. > > > > Maybe I am missing a ipipe_handle_demuxed_irq call in an interrupt > > handler that gets called before my driver interrupt handler gets a > > chance to get called. > > > > I have to look at what interrupt happens before mine. > > > > -Mathieu > > more info: > 1) interrupt (lets say #I) triggers, the ipipe_dispatch_irq calls the > irqchip->mask() which calls ipipe_lock_irq (IPIPE_LOCK_FLAG is now > set).
it should not call irqchip->mask, but irqchip->ipipe_ack, which should not call ipipe_lock_irq. See for instance the documentation about fasteoi irq: http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/#flow_handler -- Gilles. https://click-hack.org _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
