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
_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai
