[Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Mathieu Rondonneau]

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

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Gilles Chanteperdrix]

On Sat, Oct 31, 2015 at 08:58:27PM -0700, 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?

Maybe have a look here:
http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Mathieu Rondonneau]

On 15-11-02 08:27 AM, Gilles Chanteperdrix wrote:
> On Sat, Oct 31, 2015 at 08:58:27PM -0700, 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?
>
> Maybe have a look here:
> http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/
>
Hi Gilles,

I read this guide a couple of time already in the past but it did not help.
But I think the section "flow handler" is where my problem resides since 
I get the callback to trigger properly.
I will continue staring at the code. I just don't have the big picture 
just yet.

Thanks,
-Mathieu

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Mathieu Rondonneau]

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

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Mathieu Rondonneau]

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

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Mathieu Rondonneau]

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).
-Mathieu

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Philippe Gerum]

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.

-- 
Philippe.

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Mathieu Rondonneau]

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.

Thanks,
-Mathieu

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Gilles Chanteperdrix]

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

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Mathieu Rondonneau]

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

Re: [Xenomai] Support for Raspberry PI 2 B (devm_request_threaded_irq)

[Philippe Gerum]

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.