On Sun, Nov 08, 2015 at 09:36:16AM -0800, Mathieu Rondonneau wrote:
> On 15-11-08 09:26 AM, Gilles Chanteperdrix wrote:
> > On Sun, Nov 08, 2015 at 09:20:47AM -0800, Mathieu Rondonneau wrote:
> >> On 15-11-08 09:10 AM, Gilles Chanteperdrix wrote:
> >>> On Sun, Nov 08, 2015 at 09:04:38AM -0800, Mathieu Rondonneau wrote:
> >>>> On 15-11-08 12:42 AM, Gilles Chanteperdrix wrote:
> >>>>> 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, thanks again for you response,
> >>>> the code (and execution path observed) does not seem to match with what
> >>>> you are saying (please don't take this the wrong way :)), please help
> >>>> clarifying. See explanation below:
> >>>>
> >>>> From the doc:
> >>>> "the irq_mask handler should call ipipe_lock_irq before accessing the
> >>>> interrupt controller registers"
> >>>> So I did put a ipipe_lock_irq in the irq_mask.
> >>>
> >>> The documentation also says:
> >>> "If the flow handler is “handle_fasteoi_irq” the implementation of
> >>> the “struct irq_chip” members should be modified:"
> >>> and
> >>> an irq_hold handler should be added (when CONFIG_IPIPE is enabled)
> >>> having the same effect as the irq_mask handler (but without the
> >>> call to ipipe_lock_irq), and the irq_eoi handler.
> >>>
> >>> In which case the irq_hold handler is called upon handling the
> >>> interrupt.
> >>>
> >>> You can not just apply half of what the documentation says and hope
> >>> to have a working system.
> >>>
> >>
> >> But I don't use handle_fasteoi_irq, I use handle_level_irq.
> >
> > Exactly my point.
> >
>
> ok so you are saying, that for handle_level_irq, do not add the
> ipipe_lock_irq in the irq_mask?
> Can you confirm this?
> Does it mean for handle_level_irq, the irq_hold and irq_release are not
> needed as well.
> Ok this is the part I did not understood from the doc then. I think this
> could be clarified in the doc. (more clarification does not hurt).
The doc looks clear enough to me. It says:
if condition, then
do 1
do 2
do 3
if condition is not true, there is no reason to do 1, 2, or 3.
perhaps you want me to add
else
do nothing
?
As a C programmer, do you put,
else
;
To all your ifs with no else ?
>
> Just to confirm, you were saying "it should not call irqchip->mask, but
> irqchip->ipipe_ack".
> But for handle_level_irq the mask and the ack are called.
> Is that correct?
The answer is in the implementation of ipipe_ack for level
interrupts. It calls mask_ack_irq.
>
> I think understand what my mistake was.
> I have not tested it yet but without the irq_lock, it should call the
> handler.
> Thank you Gilles again!
You are welcome. I suggest however to take the time to read the
documentation completely from beginning to end, before jumping
head-on in the port, only reading parts of it, and wasting time
stupidly because you only read part of a sentence.
--
Gilles.
https://click-hack.org
_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai
